A stable-looking identifier can conceal a changing relationship. Telephone numbers are familiar enough that a continuous sequence of records may appear to describe one continuing customer. Yet a number can be disconnected and assigned again. When the analytical join ignores that interval, the convenience of the field can become an unsupported claim about whose history is being described. I believe a customer account should earn continuity from assignment evidence instead of assuming it from an unchanged string of digits.
The fictional 2015 review at Navirelan covered eighty-four thousand number disconnections, with fifty-one thousand numbers reassigned during the review year. The proposed history joined records through the telephone number alone. That could bring information from an earlier assignment into a later one. The source field was populated and easy to match, so ordinary checks for missing keys did not reveal the interpretative error. What was absent was an account of the period in which the relationship held.
An identifier has a period of meaning
I would begin by asking what the number identifies in the source at the time of the record. It may connect a service event to an assignment without establishing a permanent person identity. That is still useful information. The difficulty arises when a later application asks the field to do more than its source relationship supports. A long customer history can look especially persuasive because it contains many observations, although the connection between some of them may be precisely the thing that has not been established.
The analytical sponsor in our example preferred the continuous account. It made longer comparisons possible and avoided explaining why a history ended or restarted. I chose to preserve the assignment intervals, accepting that some views would become shorter or explicitly uncertain. The decision did not announce that every disconnection represented a new person. It recognised that continuity could not be assumed merely because the same number appeared again. Evidence of the relationship had to carry the conclusion, rather than the convenience of the join.
Time therefore belongs inside the relationship, not only in the event table. An event date can be correct while the associated customer interpretation is wrong. The source may need to show when an assignment began, when it ended and what is known about records near the boundary. Where the evidence is incomplete, I would retain the uncertainty. Filling the interval with the most convenient identity makes the output look complete by removing the very question the account should help a reader understand.
Preserve the break before extending the history
Our S$2.4 million response retained the dated assignment relationships and removed unsupported continuity from the analytical view. The result was a better account of what the reviewed records could be connected to. It did not establish a new legal permission, prove anonymisation or supply a conclusion about every customer’s identity. Those distinctions matter because an improvement in the technical representation can otherwise be presented as resolving questions that belong to different evidence and responsible owners.
I would keep the source explanation available when the history is shortened. A reader encountering a break should be able to understand whether it reflects a known reassignment, missing evidence or a deliberate scope limit. These are different conditions with different implications. Treating every break as a data-quality defect can create pressure to join across it, even when preserving the break is the accurate response. A well-designed account should make a supported discontinuity understandable rather than hide it as an embarrassment.
The timing of the intended analysis also matters. A report prepared for one period may have access to assignment information that was unavailable earlier. That can affect what a historical user could reasonably have known. I would avoid silently using later knowledge to imply that every earlier decision had the same evidence. The aim is not to make reconstruction impossible, but to describe which source state supports the reconstructed account and where its interpretation differs from what was available at the time.
There is a practical temptation to solve the problem by declaring another field the permanent customer identifier. That may be appropriate only if its meaning and relationship have actually been established. Moving the assumption into a different column does not remove it. I would examine how that field is created, changed and associated with services before relying on it. The strongest key for a particular task is the one whose relationship is supported, not necessarily the one with the most reassuring name.
Separate a supported relationship from permission to use it
Even a well-supported connection does not settle whether an intended use is permitted. Privacy, legal and other responsible owners need to assess the purpose and relevant conditions. A data function can explain what the records represent and how they connect without taking over those decisions. I prefer to state that boundary early, because a completed analytical join can otherwise acquire momentum: once the output exists, people may treat permission as an administrative detail rather than a separate question requiring consideration.
The fictional case contains no actual subscriber information. On a real leadership website, I would describe the decision and its limits without publishing identifiers or histories that were used internally. A credible example does not need to expose the underlying customers. It can explain the source of the error, the disagreement, the selected response and the resulting boundary. Any further evidence for a professional discussion would need an authorised process, not an assumption that a public narrative creates permission to circulate records.
The board-level issue is broader than one join. An institution can accumulate confident descriptions of customer tenure, behaviour or experience that depend on an untested identity assumption. I would ask management to identify the material relationships behind those claims and explain where continuity is supported. That question should remain proportionate to the decision. It is not a request for directors to design the data model, but a way of understanding whether a consequential interpretation rests on a relationship the enterprise can substantiate.
The organisational cost of the correction is also real. Some analyses become less complete, established series may change and users must learn why a shorter history can be the more faithful one. I would plan that explanation as part of delivery. Merely changing the join and hoping the new account speaks for itself leaves recipients to invent their own reasons for the difference. The data leader should make the meaning of the change accessible without claiming a commercial improvement that the correction has not measured.
My conclusion is that a number’s familiarity should never substitute for evidence about the period in which it identifies a service relationship. Preserving assignment intervals allows a history to remain useful while limiting what it says about a person over time. The institution may later establish additional connections or decide on a different permitted use. Until then, the responsible account retains both the supported relationship and the boundary beyond which the familiar identifier no longer answers the question being asked.