The short version
In a manufacturer with decades of history and multiple merged systems, the link between a part in the ERP and its engineering drawing is often broken — the identifier that should connect them is blank, outdated, or points to a record no current system tracks. Simple name-matching can't fix this. The techniques that can: matching on structure rather than identifiers, requiring evidence in both directions before trusting a match, and using AI to do the sifting at a scale no manual effort could — with human experts validating every result that matters.
The data problem, up close
Every long-lived manufacturer eventually faces the same quiet crisis in its product data. On paper, each part in the ERP should point cleanly to its controlled engineering drawing. In practice, after decades of product evolution, acquisitions that merged incompatible systems, plant transfers, and migrations between multiple ERPs and CAD/PLM tools, that link is frequently broken.
The specifics vary but the pattern is consistent. The field that is supposed to connect a part record to its drawing is blank, or it holds an old drawing revision, or a number that no current system tracks anymore, or a value that was mangled in a long-ago data migration. Sometimes it points back at the part itself in a circular, useless reference. Multiply that across hundreds of thousands of part records and thousands of drawings, and you have a foundation that no downstream process can fully trust — not planning, not quality, not a system migration, not a configuration effort.
Here is why this is genuinely hard, and not just tedious: the obvious fix doesn't work. You cannot simply match a part to a drawing by their numbers or names, because the numbers are exactly what's broken. The identifiers you'd match on are the corrupted data. So the problem looks unsolvable by brute force — which is why it usually gets left alone until something forces the issue.
Technique one: match on structure, not identifiers
The key insight is that when the direct identifier is broken, you can still recover the right match by looking at structure — the relationships between parts rather than their names.
Even when a parent part's own reference is unusable, its components are often intact and already correctly matched. So instead of asking "what drawing does this part's broken number point to," you ask "what assembly do this part's known-good components roll up to." You work from the pieces you trust to identify the whole you don't. If a part's components consistently belong to a particular assembly in the engineering system, that assembly becomes a strong candidate match for the part — recovered entirely from structure, without ever relying on the corrupted identifier.
This is a fundamentally different and more robust approach than name-matching, because it leans on the relationships in the data, which tend to survive migrations, rather than on the identifier fields, which tend not to.
Technique two: require evidence in both directions
A candidate match is not a confirmed match, and this is where a lot of automated data work goes wrong — it accepts a plausible-looking match and moves on, quietly introducing errors.
The discipline that prevents this is bidirectional coverage. Before trusting a structural match, you check it from both sides: do most of the part's components appear under that candidate assembly, and are most of that assembly's components accounted for by the part? Coverage in only one direction is a warning sign — it usually means the candidate is broader or narrower than the part actually is, and the match is wrong or incomplete. Requiring strong agreement in both directions turns a plausible guess into a defensible match.
It's a simple principle with an outsized effect on quality: a match you can verify from both ends is one you can build a production system on. A match you've only checked from one side is a future error waiting to surface.
Technique three: AI to sift, experts to confirm
Structural matching and bidirectional verification are the right methods, but applied by hand across a full product catalog they'd take years. This is where AI changes the economics — and where it has to be governed carefully.
AI does the sifting. It can read across hundreds of thousands of records, reconcile part structures against engineering data, propose the structural matches, compute the coverage in both directions, and flag the cases that pass the threshold from the cases that don't — at a speed and scale no manual effort could approach. It can also read the source documents themselves — drawings, specifications, legacy documentation — and extract the structured data that's missing, turning unstructured history into usable records.
But automated coverage is a filter, not a confirmation. The results that matter are validated by people who know the products: an engineer confirms the match against the real drawing before it becomes authoritative. And critically, the process is honest about the shapes the data actually takes — for example, recognizing when a single drawing legitimately documents many parts (a family or range) rather than forcing a false one-to-one match just because the automation wants a tidy pairing. The AI proposes and prioritizes; human expertise decides the truth.
That division of labor is the whole game. AI makes an impossible-by-hand effort achievable; engineering judgment keeps it correct. Neither alone would work — automation without validation produces confident errors, and validation without automation never finishes.
Why this matters
Reconciling broken product data is the unglamorous foundation the rest of a remediation program stands on. You cannot rebuild configuration rules, close CAD gaps, or migrate to a new system on top of part data you don't trust. And because the problem resists brute force, it tends to be treated as permanent — the immovable cost of being an established, complex manufacturer.
It isn't immovable. The combination of structural matching, bidirectional verification, and AI-scale sifting under human validation makes it tractable. The identifiers may be broken, but the truth is still recoverable from the structure and the source documents — and modern AI, used with the right discipline, is what finally makes recovering it affordable.
It is also the same principle that governs data foundations generally: get the data right once, in one trusted place, and the applications built on top become tractable. We make that argument for planning and pricing in one foundation, many applications.
This is part of a series on how we approach product-data remediation for complex manufacturers. See the series overview for the full phased program, and the companion pieces on rebuilding configuration rules and converting legacy 2D drawings into 3D models.