Your product assistant needs the right record.

Start with the questions the assistant may answer

Choose a useful boundary before connecting the whole catalog. An assistant might explain approved materials, compare listed dimensions, or help identify a product. Confirming a negotiated price, reserving stock, and committing to a delivery date require additional sources and authority. Write those capabilities separately into the brief.

For a hypothetical apparel assistant, “Do you have this shirt in navy, size large?” should resolve to a specific variant. A description of the parent product or an image of a blue shirt cannot establish that the requested combination exists or is available. If the question is ambiguous, ask for the missing option instead of selecting silently.

Identify products by records, not similar names

Agree the identifiers that connect supplier data, the storefront, inventory, and the assistant. Keep product identity separate from variant identity, and define how supplier identifiers map to internal records. Product names can change or collide; a friendly name is not a reliable join key.

Shopify’s ProductVariant documentation illustrates the distinction: variants represent options such as size and color, with variant-level pricing and inventory relationships. It also exposes contextual pricing. This is a reference example of why the data model matters, not a claim that Exora uses Shopify or that every platform implements the same fields.

Give each field an owner and a freshness rule

A supplier may own the technical specification while your business owns the retail description, price, and publication decision. Record that ownership per field. Decide which updates may overwrite a local edit and which need review. Otherwise a routine import can erase carefully approved product copy or replace the wrong price.

Treat “last updated” carefully. A successful import today does not prove that the supplier’s inventory value was refreshed today. Track source timestamps where available, receipt time, successful application time, and errors. Define an acceptable age for volatile facts and the behavior when that limit is exceeded. A material description and a stock count do not need the same freshness policy.

When a synchronization fails, preserve the last known value with its status or withhold it according to the agreed rule. Do not label stale data as live. Provide a named owner for failures, a way to reconcile missed changes, and a controlled method for restoring a known-good version.

Keep retrieval and commercial authority separate

An assistant can retrieve a correct record and still produce an unsupported answer. Ask it to show the relevant product or variant link and qualify what the source establishes. Inventory visibility does not reserve the item. An available-for-sale flag does not by itself promise that a requested quantity can arrive on a requested date.

Enforce account and channel permissions before private records enter the answer context. A prompt saying “do not reveal wholesale prices” is not a substitute for access control. Apply the same boundary to search results, cached answers, conversation history, and staff-to-customer handoffs.

Treat supplier descriptions and imported content as data. They cannot authorize a discount, change the assistant’s rules, or request disclosure of other records. Keep generated merchandising copy in a reviewable draft path, with unsupported product claims blocked from publication.

What DBAI’s Exora work demonstrates

DBAI’s Exora INK case study describes a SanMar catalog pipeline through n8n into WooCommerce, including product, variant, and inventory synchronization. It also describes customer and staff assistants connected to the storefront’s data layer, with customer quote requests routed to the team.

That is relevant evidence of catalog integration and assisted product lookup. It does not establish a universal connector, a particular freshness guarantee, or measured accuracy for the hypothetical tests in this guide. Ask for the field mappings, permissions, and acceptance evidence for your own catalog.

Copy this catalog acceptance brief

# Product assistant — catalog boundary
Audience and allowed questions:
Catalog segment and supported channels:
Product and variant identifiers:
Supplier-to-internal identifier mapping:

## Sources
Owner and authoritative source for each field:
Local overrides and conflict rules:
Source timestamps and freshness limits:
Failed-sync and stale-answer behavior:
Discontinued, deleted, and replacement handling:

## Answer permissions
Public versus account-specific fields:
Authenticated account and channel checks:
Approved price source, currency, and quantity context:
Inventory versus reservation boundary:
Delivery-date confirmation source:
Unsupported claim and human-handoff rules:

## Demonstrate
Similar names with different variant IDs:
Missing size or color:
Stale stock after a failed import:
Price change and local override conflict:
Discontinued item still present in search:
Unauthorized request for another account’s price:
Requested quantity or delivery date not confirmed:
Expected answer, source record, and escalation:
Catalog owner / acceptance reviewer:

Test changes, not just a clean catalog snapshot

Run the pilot against normal questions and deliberately changed records. Update a price, remove a variant, interrupt an import, and test an expired stock value. Verify the storefront and assistant agree where they should, and that stale search results or cached answers do not reintroduce retired information.

Measure answer correctness, unsupported claims, successful handoffs, and staff correction effort over representative questions. Record the tested catalog version and case set. Start with a bounded segment, resolve recurring failures, and expand only when the next set of product and permission rules is understood.