Three numbers, one screw
Duplicate part numbers are not untidiness. Three numbers for one screw means three approved manufacturer lists to maintain, three qualifications, and three chances to miss the same end-of-life notice.
What it is, and what it is not
Detection of parts that describe the same physical thing under different numbers, surfaced as candidates with the evidence that produced them.
It is not deduplication. Nothing merges automatically, at any permission tier, because a wrong merge is close to unpickable: two genuinely different parts become one, every structure that referenced either now references the survivor, and the record of which was which is gone.
It is also not a data quality score. A count of probable duplicates is a number people look at once. A list of three specific parts, with what they have in common and what it would cost to consolidate them, is work somebody can actually do.
Three signals, and why a candidate needs two
Classification and attribute equality. Same class path, same values on the attributes the class declares. Exact, cheap, and it finds the easy cases — which are far more common than anyone expects, because most duplicates are created by somebody who searched badly rather than by somebody who disagreed about specification.
Semantic similarity. SCREW M3X8 SS CAPTIVE, M3 x 8 captive screw, SS and Screw, captive, M3x8, stainless are one part described by three people who were not talking to each other. Embeddings carry the object revision, so a match is against a description that currently exists rather than one superseded two years ago.
A shared AML manufacturer part. The strongest signal available. If two internal numbers both approve the same manufacturer part number, they are almost certainly the same thing, and no amount of naming disagreement changes that.
A candidate needs more than one signal before it interrupts anybody. Similarity alone produces plausible nonsense, and a reuse feature that cries wolf gets switched off in a fortnight.
The failure it prevents
The duplicate gets created at the worst possible moment: an engineer needs a part, search fails them, and creating a new number takes twenty minutes while finding the existing one would have taken longer. Nobody behaved badly.
Three years later the manufacturer discontinues that screw. The end-of-life notice matches one of the three internal numbers, because only one of the three approved manufacturer lists happened to name that exact MPN. Two products get flagged; the third does not, and ships with an unobtainable part for another five months.
The cheapest intervention is the twenty minutes before the fourth number exists — which is why detection runs in the create-part flow and not only as a periodic report. A report finds duplicates; the create flow prevents them.
How it meets the rest of the product
Consolidation, once a person accepts it, is a mass change through change control: the impact set is computed deterministically, reviewed, approved and released as one atomic transaction. Substitutions land as ordinary BOM changes with effectivity, so nothing silently reroutes on a released structure.
Every candidate cites the parts, their AML entries, their attribute values and the products each is used in. A reviewer sees exactly what the system was comparing rather than being asked to trust a similarity percentage.
Component risk ranks candidates usefully: a duplicate pair where one carries an end-of-life exposure is worth consolidating before one where neither does, because the merge removes a way to miss the notice.
Classification is what makes the first signal work at all, which is the practical argument for maintaining a taxonomy — it converts reuse detection from fuzzy matching into attribute comparison.
Search sits underneath all of it. The three engines are what an engineer reaches for before creating a part, and the reason duplicates exist is that search failed somebody at that exact moment — so detection running in the create flow is the safety net for a search that did not quite land.
How it meets your ERP
Consolidation has consequences your ERP owns, and they are shown before anyone agrees to anything. Retiring an internal number means the ERP holds an item with stock, open purchase orders and transaction history against it, and none of that disappears because engineering decided the number was redundant.
So each candidate carries on-hand quantity, committed stock, open orders and recent transaction activity read back from your ERP. A duplicate with four years of history and stock on the shelf is retired very differently from one created and never used.
Manufacturing PLM will not deactivate an ERP item. Item status is ERP-mastered under the system-of-record matrix, so the engineering change is proposed here and somebody with purchasing responsibility handles the item lifecycle on their side.
Where the boundary is
It does not decide that two parts are interchangeable. Form, fit and function are engineering judgements resting on things recorded nowhere — a tolerance that mattered on one product, a qualification that took nine months, a customer who named a manufacturer in a contract.
It also cannot see parts it has no data for. A part with no classification, no attributes, no AML entry and a description reading BRACKET is invisible to all three signals, and the honest output is that nothing was found rather than that nothing exists.
Facts
| Signals | Class + attributes · semantic similarity · shared AML part |
| Threshold | More than one signal before anybody is interrupted |
| Merging | Never automatic, at any tier — a wrong merge is unpickable |
| Runs in | The create-part flow, not only a periodic report |
| Consolidation | A mass change through change control, with rollback |
| Evidence | Parts, AML entries, attribute values and products, cited |
| ERP context | Stock, open orders and history per candidate |
| Never | Judges interchangeability, or deactivates an ERP item |
Frequently asked
Will it merge duplicates for us?
No, at any permission tier. A wrong merge is close to unpickable — two genuinely different parts become one, every structure referencing either now references the survivor, and the record of which was which is gone. It proposes; a person decides.
Why does a candidate need two signals?
Because similarity on its own produces plausible nonsense, and a reuse feature that cries wolf gets switched off within a fortnight of being turned on. Requiring agreement between attribute equality, semantic similarity or a shared manufacturer part keeps the list short enough for somebody to actually act on.
When does detection run?
In the create-part flow, not only as a periodic report. A report finds duplicates after they exist; the create flow prevents them, and the twenty minutes before a fourth number gets issued is by far the cheapest moment to intervene.
What actually goes wrong with duplicates?
Three numbers means three approved manufacturer lists, three qualifications and three chances to miss an end-of-life notice. The usual outcome is that a notice matches one internal number, two products get flagged, and the third ships an unobtainable part for months.
What happens to stock if we retire a number?
Each candidate shows on-hand, committed, open purchase orders and recent transaction history from your ERP before anyone agrees. A duplicate with four years of history and stock on the shelf is retired very differently from one created and never used.
Can it deactivate the item in our ERP?
No. Item status is ERP-mastered under the system-of-record matrix, so the engineering change is proposed here and somebody with purchasing responsibility handles the item lifecycle on their own side. Reaching across that line would mean overwriting another system's master record.
Will it find duplicates in badly described parts?
No. A part with no classification, no attributes, no AML entry and a description reading BRACKET is invisible to all three signals. The honest output is that nothing was found rather than that nothing exists, which is an argument for the classification work.