An AI parts lookup takes a plain-language description of a part — the way a mechanic or a counter salesperson would say it out loud — and tries to land it on a specific catalog entry: a part number, the illustration it sits on and, where the catalog records one, the serial-number range it applies to. It works by translating colloquial description into the vocabulary the manufacturer's catalog actually uses, then narrowing inside a single machine's catalog tree rather than searching a flat keyword index. When a description fits several variants, a well-built system asks a follow-up question — for a serial number, for a variant, for a position on the drawing — instead of picking one. The design principle underneath the whole thing is that part numbers are meant to come from retrieved catalog records rather than from the model, and that "not found" is a valid answer.
That principle is the whole engineering problem. Everything below explains why the translation step is hard, how it is done, and where it stops working.
The vocabulary gap
An EPC (Electronic Parts Catalog) is the manufacturer's structured parts database for a machine: model, then system or group, then an illustration — an exploded drawing — then a parts list keyed to numbered positions on that drawing. Each row carries a part number, a description, a quantity and, depending on the manufacturer and the vintage of the catalog, a serial-number range or arrangement code that says which builds of the model it applies to.
Those descriptions are written in a controlled internal style — most often in English, sometimes in the manufacturer's home language. In one manufacturer's catalog a part is a CABLE AS or a LINES GP; another uses a different set of abbreviations entirely. Nobody in a workshop says any of that.
A mechanic on the phone says the throttle cable. The linkage on the boom. The rubber under the engine. The little seal at the ram. He is describing a function and a location, in his own language, often a language other than the one the catalog is written in. The catalog describes a component and an assembly membership, in manufacturer shorthand.
The gap between those two vocabularies is the reason parts lookup is slow. Most of the time the data is not the problem: in our own audits of failed searches against the underlying catalogs, the part is usually present — it simply cannot be reached by typing what the customer said into a search box. Coverage gaps are real as well, and we come back to them below, but they are the smaller half of the problem.
Three specific failure modes make keyword search unreliable here:
- No lexical overlap. The words in the question and the words in the record share nothing. A functional description ("hand throttle") and a component name ("governor lever") have no token in common. String matching has nothing to match on.
- Generic names, positional meaning. A single illustration can hold many rows named
O-RINGorBOLT. They are distinguished only by position on the drawing. No amount of text refinement separates them; you need the picture. - Variant collapse. The same model, same part slot, different serial ranges and different arrangements produce several valid-looking numbers. A search that ignores serial number returns all of them, which is worse than returning none.
What the AI layer actually does
An AI parts lookup is not a chatbot pasted over a search box. The useful version does four distinct things, in order.
1. Interprets the request into catalog terms. The model rewrites a colloquial description into probable component vocabulary, in the catalog's language, and often into more than one candidate term. This is the step that closes the vocabulary gap, and it is the one a language model is genuinely good at: it has seen enough technical text to know that a functional description tends to map onto a component name.
2. Navigates the assembly tree instead of searching flat. Rather than throwing keywords at millions of rows, the system narrows first — machine model, then system, then the plausible illustrations within that system. In our own failure analysis, reaching the right illustration is the step that decides most searches. Once you are on the correct drawing, the answer is on the page.
Where a given assembly sits in that tree is itself manufacturer-specific, and getting it wrong sends the user to the wrong place. Engine parts are the clearest example. Komatsu publishes the engine as a catalog of its own, reached through the engine's own number, so an engine-internal part is looked up outside the machine's catalog. Caterpillar does it the other way round: engine internals live inside the machine catalog, in sections named for the engine assembly, such as ENGINE AR or CYLINDER HEAD GP. "Engine parts are found by engine number" is true for one convention and misleading for the other, so a lookup layer has to know which catalog it is standing in.
3. Scopes by serial number. Part numbers for the same slot diverge across builds. If a serial number is available, the system filters to the ranges recorded for it; if it is not, a well-behaved system asks for it rather than picking a variant and presenting it as certain. Where the catalog itself records no range for a row — which happens — the honest output is to say so, not to imply the row is universal.
4. Grounds the answer in retrieved rows. The part number, the description, the quantity, the illustration and, where the catalog carries one, the serial range are read out of records that were actually retrieved. The model's job is to select and explain — not to supply the digits.
Part numbers are format-heterogeneous across manufacturers — they look like 600-185-3100, 1R-0658 (also written 1R0658), VOE17533661 — which means a plausible-looking string is trivially easy for a language model to produce and hard for a user to spot as wrong without checking it against the catalog. That is why the number has to be constrained to retrieved records and checked against them, rather than left to instruction alone.
Categories of tooling, and what each still asks of you
| Category | What it is | Strong at | What it still asks of you |
|---|---|---|---|
| Official OEM EPC | The manufacturer's own catalog application | The authoritative source: the manufacturer's own data, drawings and variant logic | That you can already name the assembly you are looking for; each brand is its own catalog |
| Catalog aggregator | Multi-brand parts data in one place | Breadth across brands, cross-referencing | Search remains lexical, so it still depends on matching the catalog's own wording |
| Search layer | Better indexing over existing catalog data | Fast exact-number lookup, tolerant of formatting differences | The right words up front; a functional description still has nothing to match on |
| AI assistant | Language layer over catalog data | Colloquial input, cross-brand, narrowing by description | Catalog data underneath it, and the discipline of grounding every answer in that data |
The categories are complementary, not competing. A language layer is only as reliable as the catalog data underneath it — without one, there is nothing to ground an answer in. A catalog with no language layer is a filing cabinet you must already know how to open.
What it cannot do
Being explicit about limits is not a disclaimer, it is a specification.
- It is built not to produce a number that is not in the retrieved data. When the part is absent — genuinely missing, or absent from the catalog data available to the system — the intended output is "not found", with the section or drawing where it would live. Anything else is a fabricated number that a salesperson will quote and a customer will order.
- It cannot make incomplete catalog data complete. Manufacturer data has holes. In the data we work with, close to a tenth of the rows for one manufacturer carry no part number at all, and pulling another manufacturer's catalog again from source left us with roughly twice as many entries as we had held before. A lookup layer can be honest about a hole; it cannot fill one.
- It cannot resolve a purely positional part from text alone. When a drawing holds several identically named rows, the honest answer is to open the illustration and let the user click the position. Text refinement will not separate them.
- It cannot pick a variant without a serial number. For a model with multiple builds, the serial number is the discriminator. Without it, the system should present the variants with the ranges the catalog records and ask, not choose silently.
- It cannot fix supersessions it has not been told about. Part numbers are replaced over time. If the catalog snapshot predates a supersession, the returned number was correct once and may no longer be orderable.
- It has no view of your stock or price. Catalog lookup answers "which part", not "do we have it" or "what does it cost". Those are different systems.
Judging whether a system is grounded
Four questions separate a grounded lookup from a confident guesser:
- Does it show the source? A part number without the illustration and the section it came from is unverifiable.
- Does it tell you what it knows about variants? Where the catalog records a serial-number range, it should be shown. Where it records none, the system should say so. Silence means the variant question was skipped, not answered.
- Does it ever say "I don't know"? A system that always produces a number is producing numbers, not answers.
- Does the number survive a check in the OEM catalog? That is the only test that matters. Run it on parts you already know.
This is the shape of the tool we build. Mayster works from a colloquial description in Polish, English or German, searches catalog data for Komatsu, Caterpillar and Volvo machines, and shows the positions it found together with the section they sit on — with the drawing and the serial-number range where the catalog contains them. Where a description fits several variants, it asks instead of guessing, and it is designed to return nothing rather than a number the data does not support. Mayster is an independent tool and is not affiliated with, authorized or endorsed by Komatsu, Caterpillar or Volvo; manufacturer names and part numbers are used for identification purposes only.
The value is not that a language model knows about parts. It does not. The value is that it can carry a description across the vocabulary gap and land on the right drawing, where the number is already written down.
Frequently asked questions
What is an EPC and how is it structured?
An EPC, or Electronic Parts Catalog, is a manufacturer's structured parts database for a machine. It is organized as a tree: model, then system or group, then an illustration — an exploded drawing — then a parts list keyed to the numbered positions on that drawing. Each row in that list carries a part number, a description and a quantity, and depending on the manufacturer and the vintage of the catalog it may also carry a serial-number range or an arrangement code saying which builds of the model it applies to.
Why doesn't typing the customer's own words into a parts catalog search box work?
Because the two vocabularies do not meet. A mechanic describes a function and a location — the throttle cable, the rubber under the engine — while the catalog describes a component and its assembly membership in manufacturer shorthand such as CABLE AS or LINES GP. A functional description and a component name often share no word at all, so string matching has nothing to match on. On top of that, one illustration can hold many rows named O-RING or BOLT that are separated only by position on the drawing, and the same slot can carry different numbers across serial ranges.
Are engine parts listed in the machine's catalog or in a separate engine catalog?
It depends on the manufacturer, and this is one of the easiest ways to end up in the wrong place. Komatsu publishes the engine as a catalog of its own, reached through the engine's own number, so an engine-internal part is looked up outside the machine's catalog. Caterpillar does the opposite: engine internals sit inside the machine catalog, in sections named for the engine assembly, such as ENGINE AR or CYLINDER HEAD GP. A lookup layer has to know which convention applies to the catalog it is standing in.
Can a parts lookup return a reliable number without the machine's serial number?
Often not, because part numbers for the same slot diverge across builds of the same model. Where the catalog records serial ranges, the serial number is the discriminator that separates otherwise valid-looking numbers. A well-behaved system asks for it, or presents the variants together with the ranges the catalog records, rather than picking one silently and presenting it as certain. Where the catalog records no range for a row at all, the honest output is to say so instead of implying the row fits every build.
How can I check whether a part number an AI assistant gave me is real?
Look it up in the OEM catalog — that is the only test that settles it, and it is worth running first on parts you already know. Part numbers look very different from one manufacturer to the next, which makes a plausible but wrong string easy to produce and hard to spot by eye. Before that, check whether the system showed you where the number came from: a number without the illustration and section behind it is unverifiable, and a system that never says "I don't know" is producing numbers rather than answers.
Does a catalog lookup tell me whether the part is in stock or what it costs?
No. Catalog lookup answers the question "which part", not "do we have it" or "what does it cost" — availability and pricing live in different systems. It also cannot tell you about a supersession it has not been told about: if the catalog snapshot predates a replacement, the number it returns was correct once and may no longer be orderable.