A serial number looks like the opposite of ambiguity. It is specific, easy to store and often printed on the item a service engineer is trying to identify. That appearance made it an attractive basis for a rule I approved in 2018. We would connect service history to equipment using the serial value alone. The rule simplified the application and seemed to remove unnecessary human comparison. It also assumed that the value was unique across the full manufacturer and model population our enterprise handled. That was the part of the decision we had not established.
The population behind an identifier
An identifier belongs to a context. A value can distinguish items within one catalogue or production system without distinguishing every item in a mixed estate. The problem is not that the value becomes imprecise when copied into a database. It is that the receiving system may assign it a broader meaning than the source ever supplied. My rule treated serial equality as equipment identity. Once that relationship appeared in the application, colleagues could reasonably expect the attached service history to refer to the physical item in front of them. The system was not merely storing a label; it was expressing a conclusion.
We reviewed 640 equipment records. Five hundred and eighty-eight had identities supported by the available evidence, while fifty-two needed investigation. I retain those numbers because the response was selective. We did not decide that every record was unreliable or that every item needed a new visit. The fifty-two were the set for which the existing evidence did not support the confident match. Documentary checks and physical verification, where necessary, were the means of resolving those questions. The work required engineering and field knowledge that a database comparison could not manufacture simply by adding another automatic rule.
The project sponsor proposed prefixing the disputed values with the most likely manufacturer and proceeding. That idea had a rational purpose: it would preserve the conversion schedule and avoid the cost of reaching equipment at customer locations. I did not reject it because automation is inherently untrustworthy. I rejected the word likely being used where the resulting record would look confirmed. If a source relationship had been established, the system could carry it. Where it had not, an automatic prefix would create the appearance of specificity while leaving the underlying inference untouched. The output would be more detailed without necessarily being more defensible.
What the exceptions required
I authorised ₹38 lakh for verification and the data correction. Forty-four of the fifty-two disputed records were resolved, leaving 632 supported identities and eight held exceptions in the examined cohort. The unresolved eight did not receive a convenient substitute just to complete the field. They remained visible for further work. That was an operating decision with a cost: colleagues could not treat every record as immediately usable, and the project had to retain a route for handling the exceptions. The alternative was not free. It would transfer the uncertainty to whoever later relied on the service history, perhaps without knowing there had been a question at all.
The revised account preserved the manufacturer and model relationship alongside the serial value and the evidence used to confirm the physical item. That does not mean a composite key is a universal solution to identity. Components can be replaced, labels can be damaged and records can describe different levels of an assembly. The appropriate identification model depends on the equipment and service use. The lesson I draw is about establishing that model with the people who understand the physical context, then making the remaining uncertainty visible. It is not a recommendation to add fields until an identifier looks impressively complicated.
I also needed to avoid exaggerating the consequence of the original error. The fictional review does not establish that 640 devices were defective or that each ambiguous record had caused an incorrect repair. It establishes that the identity evidence was insufficient for fifty-two records and describes what happened next. A leader can explain a consequential control weakness without inventing a dramatic incident to prove it mattered. That restraint helps a reviewer judge the decision on its actual basis: the relationship the system asserted, the evidence available at the time and the cost of obtaining a more reliable account.
Because I had approved the rule, the correction could not be presented solely as improved data discipline by other people. The application encouraged a broad inference, and field colleagues had worked within that design. Asking them to be more careful without changing the model would leave the same assumption in place. My responsibility was to revisit the rule, fund the evidence work and explain why the remaining eight exceptions should not be hidden. The owned error belongs in the biography as well as the case study because it changed how I approach a seemingly simple information requirement.
A match should explain its authority
For later programmes, I ask what evidence entitles the system to represent two records as the same thing. The answer may be straightforward in a tightly defined population and much more demanding across acquired or mixed estates. The relevant team should know which conditions make the match valid and what happens when those conditions are absent. A useful interface can distinguish confirmed identity from a candidate relationship without overwhelming the user. It should not force the business to decide prematurely merely because the technical design expects a single completed value. That pressure is a design choice, not an unavoidable fact of computing.
The same question applies to how results are communicated upward. A report of 632 supported identities and eight exceptions is more useful than a declaration that the asset-data project is complete if completion conceals the unresolved set. It also avoids overstating what supported identity means. The correct service history does not itself certify the equipment for a measurement, establish compatibility of a proposed part or authorise remote access. Those are separate decisions with their own evidence and owners. Keeping identity accurate is necessary for many later actions, but it should not be used as a substitute for them.
The record I want technology to provide is therefore both specific and modest. It should identify the item sufficiently for the service decision, preserve the evidence behind the relationship and admit where the relationship is not yet established. That is more demanding than storing a precise value and less grand than claiming perfect enterprise data. In this case it required me to withdraw confidence from a rule I had supported and accept the cost of eight unfinished questions. The resulting system was useful because its certainty had become better aligned with the evidence, not because every field had acquired an answer.