Here is a data problem with no error message.
Two engineers, in different offices, need the same connector. One searches for "header" and finds nothing. The other searches for "connector" and finds nothing. Both create an item. Both records are accurate, well-formed, correctly classified and completely valid.
The company now has two identities for one physical thing, and it will keep them for years.
Why this is worse than a wrong record
A wrong record gets challenged. Somebody notices a tolerance that cannot be right, or a description that contradicts a drawing, and it gets fixed.
Duplicate identity produces no symptom at the record level at all. What it produces is a quiet, permanent degradation of every structural query in the system. Where-used returns half the answer. An obsolescence check covers half the products. A spend analysis sees two moderate volumes instead of one large one, and the buyer negotiates accordingly.
None of those look broken. They look like answers.
A wrong answer gets argued with. A confidently incomplete one gets acted on.
How it actually surfaces
Usually like this. A connector goes end-of-life. Somebody runs a where-used, gets two products back, and scopes a redesign. Five weeks of work, executed properly, released.
Nine months later a third product fails certification with the same obsolete connector in it. That product's BOM referenced the duplicate — same connector, different number, created eighteen months earlier by the engineer who searched for "header".
The obsolescence check was correct. It was also incomplete, and nothing about it indicated that. The cost is not the second redesign; it is that the organisation now has a reason to distrust every structural query it runs, without knowing which ones to distrust.
Why cleanup projects do not fix it
The standard response is a data cleanup: export the item master, sort it, find the duplicates, merge them.
This works once and does not hold, for a structural reason. The rate at which duplicates are created is a function of how people search, and a cleanup does not change how people search. So the population is reduced and immediately begins refilling, and the second cleanup is harder than the first because there are now structures referencing both copies.
Merging is also genuinely expensive once things reference the duplicates. A merge is a structural edit across every product that used either copy, and it needs an impact analysis, a review and an approval. At creation time it costs nothing — nothing has been built on top of either record yet.
Which points at where the check belongs.
The check belongs at creation
Before an item is created, search for what the person is about to create and show them what already exists.
That is obvious enough that most systems claim to do it. The reason it usually does not work is that the search runs on description text, and description text is exactly the thing the two engineers disagreed about. "Header, 2x5, 2.54mm" and "Connector, IDC, 10-way, 0.1in" describe the same part with no shared words.
The search has to run on classification attributes instead — pitch, ways, gender, mounting, current rating — because those are typed, comparable, and not a matter of vocabulary. An engineer who has filled in a classification form has already told you what the part is, in a form a machine can compare.
Present differences, not scores
The second half of getting this right is how the candidate is shown.
A similarity score is not evidence. "87% match" tells a person nothing they can check, and it is confidently wrong in exactly the cases that matter — where one attribute carries the whole meaning. Two resistors identical in every respect but tolerance are 97% similar and are different parts. Two capacitors differing only in a packaging suffix are 94% similar and are the same part in a different reel.
So the useful presentation is a statement: this candidate matches on eleven of thirteen attributes and differs on tolerance and package. That is checkable in three seconds by the person best placed to check it, and it produces a decision rather than a guess.
The inverse problem
There is a second failure that gets far less attention: one item covering two things.
It happens when a part is changed in a way that should have created a new item and was recorded as a revision instead. The new version is not backward compatible in some application nobody was thinking about, and now a single item number means two physically different things depending on when you ask.
The test that prevents it is simple to state and takes discipline to apply: is the change backward compatible in every application? Not in the application that prompted it — in every one. If a unit built with the old version can accept the new one without qualification, it is a revision. If not, it is a new item, and the fact that it looks almost the same is irrelevant.
What to do about the ones you already have
Two things, in order.
First, put the check at creation so the population stops growing. This matters more than fixing history, because a cleanup against a growing population is a treadmill.
Second, if you are migrating between systems, do the merge during migration. That is the one moment when it is cheap again: nothing downstream has been built yet, so a merge is a decision rather than a structural change. Reviewing two hundred proposed matches before go-live is the highest-return fortnight in most PLM implementations, and it is almost always the first thing cut for schedule.
Which is a shame, because it is the only part of the project that gets harder every day you postpone it.