RAG for Product Catalogs: Specifications, Compatibility and Availability

A product-catalog assistant is useful only when it can say where an answer came from, which catalog revision it used, for which market it is valid, and when it must stop. A fluent answer that invents compatibility or treats yesterday's stock snapshot as a purchase promise is worse than a deliberate no-answer.

This article describes CATALOG-EVIDENCE-9, a bounded RAG workflow for catalog lookup. It supports discovery and pre-sales work; it does not reserve stock, make a safety claim, set a price, or replace the transactional product system.

Start with the catalog process, not the chat window

Catalog questions look short: “Does this part fit?”, “What is included?”, “Is it available in Yerevan?” Behind each question are different source types and different consequences. A useful design first separates the job into routes.

• Specification lookup: dimensions, materials, supported features, certifications and included components.
• Compatibility check: a relationship between a product, variant, model, revision, region and sometimes installation condition.
• Availability explanation: a dated, location-scoped indication from an inventory system, never a reservation or delivery promise.
• Comparison: a cited difference between comparable current variants.
• Escalation: a route for missing data, conflicting sources, safety-critical use or a request to buy.

The broad engineering work belongs on the RAG systems service page. A catalog article is intentionally narrower: it turns one product question into an inspectable answer contract. Teams in Armenia choosing a broader AI delivery partner can evaluate scope, evidence and operating discipline on /ai-specialist-armenia.

The source contract: every catalog fact needs a home

Do not index an exported spreadsheet and call it a product truth. Before ingestion, give every item a durable identifier and record the fields that determine whether it can be retrieved.

The RAG index may contain descriptions and manuals, but the authoritative product system remains the source of operational facts. Inventory is particularly sensitive: retrieve a current indication for a store or warehouse, show its timestamp, and route a reservation or order to an authorised transactional workflow.

The underlying source lifecycle is the same operational concern covered in RAG Index Updates: Ingestion, Versions and Data Removal. For the answer itself, reuse the evidence-and-locator discipline from RAG Citations and Traceability, rather than presenting an uninspectable summary as product truth.

CATALOG-EVIDENCE-9: a practical workflow

The workflow begins with a structured request, not an unconstrained prompt. The system receives the product or SKU, the question type, trusted locale and channel, and any model or configuration needed for compatibility. It retrieves only eligible current records, then verifies that each material sentence has a matching locator.

request: “Is SKU A-42 compatible with device M-7 in Armenia?”
trusted context: locale=hy-AM, channel=web, market=AM

retrieve: active SKU A-42 / active device M-7 / approved compatibility relation
verify: relation revision / market scope / evidence locator / conflict state

answer: compatible under the cited configuration; show source revision
route: clarify if the device revision is missing; review if sources disagree

This is deliberately different from a model guessing from product names. Similar labels, legacy variants and bundled items cause real errors. Compatibility should be a record with left and right identifiers, conditions, effective revision, owner and status. If the request lacks the necessary model or configuration, the correct route is clarification.

Seven high-value use cases and their boundaries

1. Product-card explanation — cite active specifications and explain a field in the visitor’s language.
2. Variant selection — compare eligible current variants without fabricating a recommendation.
3. Compatibility lookup — return a source-backed relation with conditions and a missing-data route.
4. Accessory discovery — show approved attachments for a selected SKU and market.
5. Manual and installation lookup — retrieve the current document section and its locator.
6. Stock indication — show a dated location-scoped signal, never “guaranteed available”.
7. Sales or support handoff — package the evidence and unanswered fields for a named owner.

The assistant should not publish prices, approve substitutions, make safety-critical installation decisions, or commit inventory. Those are separate system actions with their own permissions, deterministic checks and read-back receipts.

Integrations are contracts, not connectors

Most pilots need three integration lanes. The catalog/PIM lane supplies product attributes, variants, lifecycle and owners. The relationship lane supplies compatibility graph records and conditions. The ERP, WMS or commerce lane supplies a dated inventory indication. Identity and channel policy decide what the visitor or employee can see.

For each lane, write down: source ID, allowed fields, refresh expectation, owner, deletion or retirement event, failure behaviour and response boundary. A delayed inventory feed must not silently become current; it should make the answer state that availability cannot be confirmed. A deleted SKU must become unretrievable rather than remain in a vector index.

Risks that need explicit routes

The common failure is not merely hallucination. It is a correct-looking answer attached to the wrong variant, market or time. Design test cases for:

• two products with a similar name but different variants;
• a compatibility relation that was superseded;
• a catalogue source allowed in one market but not another;
• a stock feed older than the agreed freshness window;
• conflicting manual and product-card claims;
• an unauthorised catalogue field;
• a question without enough device or configuration detail.

In each case the assistant should clarify, show uncertainty, route to a human, deny a private field, or decline to answer. “No evidence found” is an operating result, not a broken user experience.

A simple pilot ROI model without invented results

Estimate the pilot from local measurements rather than a universal percentage. For one question type, measure weekly volume, current handling minutes, number of handoffs, correction rate and the cost of source preparation. Compare a bounded assistant with the current baseline only after the team has logged enough representative requests.

For example, if a team handles 120 specification questions per week at 6 minutes each, the baseline is 720 minutes. A pilot may reduce repeat lookup time, but it also adds source stewardship, review and exception handling. Report a range with assumptions; do not treat an answer draft as an automated sale or saved time until it is observed.

Acceptance criteria before rollout

The smallest credible pilot has a named owner, a frozen acceptance set and an observable rollback route.

Run the system as a catalog capability

After launch, observe coverage of cited answers, stale inventory signals, clarification rate, source conflicts, missing compatibility records and review outcomes. These are diagnostics, not marketing metrics. They point to a product-data owner, a relation record or an integration event that needs work.

Begin with one product family, one market and one question category. Assign owners for catalog data, compatibility and inventory. Then decide whether the evidence, acceptance cases and operating path are strong enough to extend the pilot. For a controlled implementation discussion, start from the RAG systems service page or review the engineering evidence on /case-studies.