Spare Parts AI: Why Aftermarket Catalogs Are the Hardest (and Most Valuable) RAG Problem

Most B2B product catalogs are hard. Spare parts catalogs are a different class of hard.

Ask a general-purpose AI "What's the replacement filter for a Komatsu PC200-8 hydraulic system?" and you'll get either a hallucinated part number, a confident-sounding non-answer, or a suggestion to "check the official documentation" — which is exactly where your customer started before they called you.

Spare parts distribution sits at the intersection of everything that makes product knowledge AI difficult: deeply hierarchical data, dense cross-reference networks, time-dependent supersession chains, OEM vs. aftermarket equivalences, compatibility matrices that span thousands of machine configurations, and customers who need the right part, not a plausible one. A wrong answer doesn't just waste a sale — it can ground a machine, void a warranty, or cause equipment failure.

This article is about building AI systems that actually work for aftermarket catalogs. It's technical, opinionated, and based on the patterns that distinguish systems that hold up under real-world aftermarket queries from those that fall apart on the first cross-reference question.

Why Standard RAG Fails Aftermarket Catalogs

The standard RAG approach — chunk your documents, embed them, retrieve by similarity, generate an answer — works reasonably well for product descriptions and spec sheets. Aftermarket catalogs break it in at least four specific ways.

1. Supersession Chains Are Not Static Documents

A supersession chain is the history of part replacements: Part A was superseded by Part B, which was itself superseded by Part C, which is now the current shipping part. This chain may have 3 links or 12. The current answer to "what's the replacement for part A?" is Part C — but your catalog documents, if they were exported 18 months ago, might only encode A→B.

Standard document chunking has no model for "this fact expires when the data refreshes." You need a data model that treats supersession as a time-indexed graph, not a static text relationship. When a query asks for a replacement part, your system must traverse the current chain to its end — not retrieve a chunk that was accurate at export time.

2. Cross-References Are Dense, Bidirectional, and Context-Dependent

An aftermarket part might be compatible with 40 OEM part numbers across 12 machine models from 6 manufacturers. Those relationships exist in cross-reference tables, not prose. Embedding a row in a cross-reference table produces a vector that is nearly meaningless in isolation — "Donaldson P550248 = Komatsu 207-60-71181 = Caterpillar 1R-0762 = Fleetguard HF28826" encodes relationships, not semantics.

The right architecture recognizes that cross-reference resolution is a lookup problem, not a retrieval problem. The AI layer should call into a structured cross-reference index rather than trying to retrieve the right cross-reference row through semantic similarity.

3. Compatibility Is a Structured Query, Not a Semantic Match

"Will filter P550248 fit a PC200-8 with a serial number above K35001?" is a structured query against a compatibility matrix — machine model × serial number range × component position → compatible parts. This is not a fuzzy semantic question. The answer is deterministic, and it should be computed from structured data, not inferred from document similarity.

AI systems that try to answer compatibility questions purely through retrieval and generation will hallucinate. The correct pattern is a hybrid approach: use the AI to parse and understand the query (extracting machine model, serial number, and component type), then execute the compatibility lookup as a structured query against your data.

4. Part Numbers Are the Primary Key, Not a Feature

In most product contexts, part numbers are one attribute among many. In aftermarket, the part number is the identity. Customers query by part number constantly, and they query with variations: spaces, hyphens, manufacturer prefixes, old part numbers that have been superseded, typos, and OCR artifacts from worn equipment labels.

Your system needs a part number normalization layer — a preprocessing step that standardizes part number formats before any lookup — plus exact-match retrieval as the first path before semantic search. Part number queries should never go through the embedding pipeline first.

The Right Architecture for Aftermarket Knowledge AI

A robust aftermarket RAG system has three retrieval paths that run in parallel and whose results are synthesized before generation.

User Query
    │
    ▼
┌─────────────────────────────────────────┐
│         Query Parser / Classifier        │
│  (extract part numbers, machine IDs,    │
│   serial ranges, component types)       │
└───────────┬─────────────────────────────┘
            │
    ┌───────┼────────────────┐
    ▼       ▼                ▼
[Path 1] [Path 2]         [Path 3]
Exact    Structured        Semantic
Lookup   Query             Search
    │       │                │
    │  Supersession      Tech docs,
    │  graph, compat.    installation
    │  matrix, x-refs    guides, notes
    │       │                │
    └───────┴────────────────┘
                │
                ▼
         Context Assembly
                │
                ▼
           LLM Generation

Path 1: Exact Part Number Lookup

Before anything else, extract and normalize part numbers from the query. Run them against your primary catalog index with exact and fuzzy matching (Levenshtein distance works well for part numbers).

function normalizePart(raw: string): string {
  // Remove spaces, hyphens, dots; uppercase; strip manufacturer prefixes
  return raw.replace(/[\s\-\.]/g, '').toUpperCase()
}
 
async function exactPartLookup(partNumber: string): Promise<PartRecord | null> {
  const normalized = normalizePart(partNumber)
  
  // Try exact match first
  let result = await db.parts.findOne({ normalizedPn: normalized })
  if (result) return result
  
  // Try fuzzy match (handles OCR artifacts, typos)
  return db.parts.findClosest(normalized, { maxDistance: 2 })
}

If the query resolves to a known part, you can immediately pull the full record — description, specs, stock status, cross-references, and the supersession chain.

Path 2: Structured Queries Against Relational Data

Compatibility questions and supersession lookups are structured queries. Parse them, then execute them.

The query intent classification step is critical here — you need to distinguish:

• "What is part X?" → catalog lookup
• "What replaces part X?" → supersession chain traversal
• "What fits machine Y model Z serial number range?" → compatibility matrix query
• "Is part X compatible with part Y?" → compatibility intersection query

For supersession, traverse the chain to its current endpoint:

async function resolveSupersession(partNumber: string): Promise<SupersessionResult> {
  const chain: string[] = [partNumber]
  let current = partNumber
  const visited = new Set<string>()
  
  while (true) {
    if (visited.has(current)) {
      // Circular supersession — data quality issue, surface it
      return { chain, current, circular: true }
    }
    visited.add(current)
    
    const record = await db.parts.findOne({ normalizedPn: normalizePart(current) })
    if (!record || !record.supersededBy) break
    
    chain.push(record.supersededBy)
    current = record.supersededBy
  }
  
  return { chain, current, circular: false }
}

The LLM sees the resolved result ("Part A has been superseded by Part C — chain: A → B → C"), not the raw chain traversal logic. Structured queries give you deterministic, auditable answers for the cases that matter most.

Path 3: Semantic Search for Technical Context

Once you know what the part is, buyers often want to know how to use it. Installation guides, technical service bulletins, torque specifications, compatibility notes, and troubleshooting information live in unstructured documents.

This is where standard document chunking and semantic search shine — but scoped to the relevant part family. After exact lookup resolves a part number, use it to filter your semantic search to relevant documents.

async function technicalContextSearch(
  query: string,
  resolvedParts: string[],
  machineModel: string | null
): Promise<Chunk[]> {
  const candidates = await vectorStore.search(query, {
    limit: 40,
    filter: {
      $or: [
        { partNumbers: { $in: resolvedParts } },
        { machineModels: { $contains: machineModel } },
      ]
    }
  })
  
  return rerank(query, candidates, 5)
}

Metadata filtering is essential here — without it, a query about a PC200-8 hydraulic filter will retrieve chunks about PC200-8 engine mounts, wheel loader filters, and unrelated equipment. Filter first, then search semantically within the filtered set.

The Cross-Reference Graph Problem

Cross-references in aftermarket catalogs are dense enough to warrant their own data structure. A single aftermarket part might cross-reference to:

• 3–12 OEM part numbers (original equipment manufacturers)
• 5–20 competitive aftermarket equivalents (Mahle, Fleetguard, Mann, etc.)
• Multiple internal catalog numbers from catalog reorganizations

Storing this as a flat table works for exact lookups but breaks down for graph traversal. When a customer asks "do you stock an alternative to Caterpillar 1R-0762?" you need to:

1. Look up CAT 1R-0762 in your cross-reference index
2. Find all equivalent aftermarket parts
3. Check stock availability for each
4. Return the stocked alternatives with confidence

This is a graph problem: OEM parts and aftermarket parts as nodes, compatibility/equivalence as edges. GraphRAG patterns apply directly — the ability to traverse relationships matters more than semantic similarity to the query text.

For most aftermarket distributors, a PostgreSQL schema with a part_crossrefs junction table and a graph traversal query works fine at catalog sizes up to a few million cross-references. Only at very large scale (auto parts mega-distributors) do you need a dedicated graph database.

Data Quality Is the Actual Bottleneck

Here's the inconvenient truth about aftermarket AI: the technology is the easy part. The data is the hard part.

Most aftermarket distributors have product data spread across:

• ERP systems (SAP, Epicor, Infor) with varying levels of cross-reference completeness
• Vendor-supplied data files (often in different formats: ACES, PIES, proprietary XML, flat files)
• Scanned PDFs of older equipment catalogs that were never digitized
• The heads of experienced parts specialists who know things that aren't written down anywhere

Your AI is only as good as your data. Before optimizing retrieval or prompt engineering, invest in:

1. Data consolidation. A single canonical record per part number, with all cross-references linked. Deduplication across vendor files and your ERP is unglamorous but foundational.

2. Supersession hygiene. Stale supersession chains are worse than no supersession data — they send customers to discontinued parts. Establish a data refresh process that updates supersession chains when vendor data changes.

3. Machine-part compatibility completeness. Compatibility matrices are often the most incomplete dataset. Prioritize coverage for your top 20% of machine models by sales volume. A partial, high-quality matrix is better than a complete, low-quality one.

4. Image association. If you have part images, associate them correctly. Multimodal search for parts — "find this part from a photo of the component" — is a real use case in field service and dramatically reduces wrong-part returns.

Confidence, Uncertainty, and the Cost of Being Wrong

In most product AI contexts, a slightly wrong answer is recoverable — the customer asks a follow-up, they look elsewhere. In aftermarket, a wrong answer has consequences: wrong parts ordered, shipping costs, machine downtime, technician time wasted on-site.

Your system should surface confidence alongside answers. When exact lookup resolves a query deterministically, that's high confidence. When semantic search surfaces a loosely related chunk, that should come with appropriate hedging.

A practical pattern: distinguish your answer sources in the system prompt.

You are a spare parts specialist AI. You have access to three types of information:
1. EXACT LOOKUP: Data resolved directly from the parts database. High confidence — state facts directly.
2. STRUCTURED QUERY: Data computed from compatibility/supersession records. High confidence — state facts directly.
3. RETRIEVED CONTEXT: Information retrieved from technical documents. Medium confidence — cite the source and recommend verification for critical applications.

When information comes from RETRIEVED CONTEXT only (no EXACT LOOKUP or STRUCTURED QUERY result), 
explicitly note that the customer should verify with a parts specialist for critical applications.

This transparency — built into how the AI presents its answers — is a feature, not a limitation. Experienced parts buyers trust a system that says "I'm 95% confident this is correct — here's the supersession chain — verify before ordering" more than one that states everything with equal, unfounded certainty. See our guide to building trust in AI responses for the broader pattern.

What Success Looks Like

A well-built aftermarket AI handles the following without hallucinating:

• "What's the oil filter for a Volvo EC220D excavator?" → Exact lookup, returns current part number with cross-references and stock status.
• "Is part 207-60-71181 still available or has it been superseded?" → Supersession chain traversal, returns current part, chain history, and availability.
• "What Donaldson filter replaces the Komatsu 600-181-9300?" → Cross-reference lookup, returns equivalent part(s) with availability.
• "What torque should I use when installing the hydraulic pump on a JD 200G?" → Semantic search with machine model filter, returns installation spec from technical documentation with source citation.
• "I have a photo of a worn part — can you identify it?" → Multimodal retrieval, returns likely part candidates with confidence scores.

None of these are solved by a chatbot wrapper around an LLM. They require the three-path architecture, structured data foundations, and deliberate confidence modeling described above.

The payoff is real. Aftermarket parts distributors who get this right see measurable reductions in wrong-part returns, faster quote turnaround for complex configurations, and the ability to handle technical queries at scale without scaling a team of parts specialists at the same rate.

Starting Where You Are

You don't need a perfect data foundation to start. A useful incremental approach:

1. Phase 1 — Exact lookup only. Stand up part number search with normalization and fuzzy matching. Handle the 40–60% of queries that are part number lookups. This alone delivers immediate value.

2. Phase 2 — Semantic search on technical docs. Ingest installation guides, service bulletins, and product descriptions. Handle "how to" and specification questions.

3. Phase 3 — Cross-reference and supersession. Build the structured lookup layer. Handle the highest-value queries — the ones your parts specialists currently spend the most time on.

4. Phase 4 — Compatibility matrix. Integrate machine-part compatibility. This is the hardest data to get right and delivers the highest defensibility once you have it.

Each phase is independently valuable. You don't need to finish Phase 4 before Phase 1 is delivering ROI.

Ready to Tackle Your Aftermarket Catalog?

Axoverna is built for the complexity of B2B product knowledge, including the structured-plus-semantic hybrid retrieval patterns that aftermarket catalogs demand. We handle part number normalization, cross-reference integration, and configurable confidence modeling out of the box.

Book a demo to walk through how Axoverna handles your specific catalog structure, or start a free trial and import a slice of your parts data to see the difference immediately.