Cross-referencing a part number is most of the job

A maintenance buyer walks up to a failed pump, reads the number off the bearing in their hand, and types it into whatever ordering screen is in front of them. That number belongs to whichever brand happened to get installed last, maybe by a contractor who is long gone. It is almost never your SKU. Your catalog is organized around your own part numbers, the way every distributor's catalog is. A plain text search for the number on the bearing returns nothing, and the buyer either picks up the phone or goes and orders it from someone else. That gap, between the number in the buyer's hand and the number in your system, is the whole job of a self-serve buyer portal. Everything else is easier than this part.

Why naive matching fails#

The instinct is to treat this as a lookup problem: build a table mapping other brands' numbers to yours, and match on it. That gets you partway there, and then the exceptions start piling up.

Different brands write the same physical part differently. Seal-type suffixes are the clearest example: 2RS, 2RS1, and DDU all mean "rubber seals on both sides" to a person who has ordered bearings for twenty years, and mean nothing to a string comparison. Leading zeros come and go depending on which system generated the number. Dashes and spaces are inconsistent within a single brand's own catalog, let alone across brands. And house numbers collide: a four-digit number that means one part at one manufacturer can be a completely different part at another, so a match has to be scoped to the right brand before it is scoped to anything else.

A resolver that only handles the clean cases handles a minority of real input.

What a resolver actually has to do#

The order of operations matters, and it has to be in this order, cheapest and most certain first:

1. Exact SKU match. The buyer already knows your number. Nothing to resolve.
2. Exact cross-reference match. A known mapping exists from a specific competitor number to a specific SKU.
3. Normalized comparison. Strip whitespace, dashes, and case; expand known seal-suffix families; retry the match.
4. Fuzzy matching with a confidence score. Edit distance and structural similarity, scored, not asserted.

Each step is a fallback for the step before it, not a replacement. Skipping straight to fuzzy matching on every query is slower and, worse, it is wrong more often than it needs to be on the cases that didn't need fuzziness at all.

Confidence has to be visible, not hidden#

The failure mode that matters here is not a UI annoyance, it's a wrong bearing on a truck. Get a part number wrong on a consumer order and the cost is a return label. Get a bearing wrong on an industrial line and the cost is a shutdown, and nobody notices until the line is already down. That asymmetry means an uncertain match cannot be silently substituted at the point of sale. It belongs in front of a human, with the confidence score attached, in a review queue, not auto-applied to a cart because the algorithm was "pretty sure."

This is also why auto-mapping should only apply at full confidence, and everything under that threshold should route to a person. Not because the fuzzy match is useless, but because the buyer trusts the number they get back, and that trust is the whole product.

The part most people miss#

Every part number a buyer typed that you couldn't match is not noise, it's demand data. If ten different buyers this month typed a number you don't carry a cross-reference for, that's not ten failed searches, it's a gap in your catalog with a dollar figure attached. Unknown numbers should land as rows in the same review queue as the low-confidence matches, so the gap becomes a work queue your team can act on instead of an order that quietly went to a competitor and left no trace.

One resolver, three surfaces#

The buyer portal, the quick-order form, and the AI concierge all need to answer the same question: what SKU is this. If each one has its own matching logic, you get three different answers to the same input, and the one that gets remembered is whichever one the concierge says out loud. A buyer who asks the assistant for a part and gets told something different than what search would have shown them stops trusting all three surfaces at once. The resolver has to be one piece of logic that every surface calls, not three approximations of the same idea.

Where this stands today#

Copiara is being built right now, and this is how we are building the resolver: exact match first, cross-reference second, normalization third, fuzzy matching last and only surfaced with its confidence attached. For the first pilots, auto-mapping only fires at full confidence. Everything else goes to a review queue until we have measured precision against real catalog data, not assumed it. That is also true of the four surfaces this resolver has to serve: portal, quick order, quotes, and the concierge all read from the same catalog, on purpose, so the answer a buyer gets is the same no matter which door they walked through.