Which relationship does this connection actually establish?

In 2019 I supported a proposal to merge customer-reference pairs that shared a telephone number. The delivery case promised a simpler party register and fewer apparent duplicates for service colleagues to navigate. As director of information integration, I approved the matching premise before asking for a sufficiently varied review of the relationships behind the contact. That was my error, rather than a defect I could attribute only to the source data.

Rina Zeqvamni challenged the premise using 920 candidate pairs. The review supported a same-person relationship for 610, identified 230 as different people and left eighty unresolved. Common contacts included households and assisted arrangements. The exercise did not establish that every shared contact was unsuitable evidence; it established that this field could not carry the automatic identity conclusion I had attached to it.

The delivery sponsor wanted to retain the merge and repair exceptions later, arguing that a visibly smaller register would help staff immediately. I withdrew the proposed automatic merge before it entered the live customer account. A ₹62 lakh correction and six-week delay put the supported links through controlled stewardship, kept the different-party pairs separate and retained the unresolved group for additional evidence. Source records remained available for examination.

We accepted a less tidy account and continuing work for the eighty unresolved pairs. The 610 supported relationships were findings for the reviewed set, not a declaration that every other link in the insurer was correct. No premium or claim decision was changed through this exercise, and the case does not report an actual customer disclosure.

What changed in my practice was the question asked before a matching rule was approved. I now want an explanation of what a shared attribute could mean in the circumstances of the people using it. A convenient key may describe how to reach someone without establishing who owns the record. The data function must defend that distinction before a delivery commitment makes the shortcut difficult to withdraw.

A 2022 integration review examined 360 commercial-property policies. In seventy-two, a financing institution recorded in a loss-payee relationship had been translated into an owner category in a proposed reporting reference. The institutions were not invented, and the source links were not simply missing. The error concerned what the receiving category told its reader about the reason each party appeared.

The reporting lead preferred one general owner field because the receiving management view had little space and users wanted a single organisation beside each policy. Underwriting and servicing colleagues objected that different party roles could not be made equivalent by choosing one familiar label. A financing relationship did not, on its own, establish ownership of the insured property. Equally, a data team should not decide the effect of contract wording by selecting a different category in a reporting table.

I funded an ₹81 lakh reconstruction with the responsible policy and professional owners. Fifty-four of the seventy-two entries received a clarified role mapping supported by their source records. Eighteen remained held for further examination. The other 288 reviewed policies had not shown this particular translation problem; that finding did not certify every aspect of their information. The revised reference preserved the distinction between parties and the roles through which they were connected.

We delayed the reporting view by five weeks and gave up the convenience of one universal owner column. The work did not amend insurance contracts, change who was entitled to payment or settle the unresolved eighteen interpretations. Those responsibilities stayed with the authorised owners and any necessary professional advice. The delivered improvement was a more faithful reporting relationship, with its outstanding questions visible.

I learned that a label can be materially wrong even when every name and identifier has been copied accurately. In a future integration, I would require the receiving role definitions to be agreed before field mapping begins. The review needs to ask what a reader could reasonably infer from a category, rather than treat matching strings as sufficient evidence that meaning has survived the transfer.

In 2023 eight partners delivered 2,400 notice submissions into a defined ingestion review. Some repeated deliveries arose when a partner retried a transmission after failing to receive an acknowledgement. The proposed deduplication rule used customer and date as its main comparison. That would have removed obvious repeats, but it could also have collapsed separate notices from the same customer on the same day.

The operations sponsor wanted to clear the apparent duplication quickly because staff were spending time investigating repeated arrivals. I agreed that a retransmission should not quietly become another submission event. I did not agree that identical customer and date fields established retransmission. The record needed to preserve the partner reference, incident reference and relevant delivery evidence before a decision could be made about whether two arrivals represented the same submission.

A ₹54 lakh review confirmed 120 repeated deliveries using matching source identifiers and payload evidence. We retained 2,280 distinct submission events. Within that retained set, seventy shared a customer and date with another notice but carried different incident references, so they remained separate. The count of 2,280 did not represent unique policyholders, unique claims or unique underlying loss events. Operating colleagues retained the interpretation of the notices themselves.

We deferred the planned batch release by five weeks and preserved the original deliveries with their reconciliation links. The repeat deliveries could therefore be examined without contributing again to the defined submission count. This was an ingestion correction, not a statement that every retained notice was valid for insurance purposes or that the data team had resolved coverage. Nor did keeping two notices separate prevent later professional review from relating them to the same event.

The practical lesson was to name the object being counted before choosing the comparison rule. A delivery, submission, claim and person can legitimately have different totals. I would establish that vocabulary with the receiving team earlier next time, so that pressure to remove duplication does not erase real distinctions simply because two records happen to share convenient fields.

A 2024 matching evaluation used 1,000 reviewed record pairs: 660 were labelled as the same person and 340 as different people for the exercise. The looser proposed rule linked 700 pairs, comprising 630 correct same-person links and seventy incorrect links. It missed thirty same-person pairs. A stricter rule linked 610 pairs, comprising 600 correct links and ten incorrect ones, while missing sixty same-person pairs.

The presentation preferred the stricter rule's higher precision. The proportion of its links supported by the review was about 98.4%, compared with 90% for the looser rule. That was useful information, but the gain did not make the missed matches disappear. Recall moved from about 95.5% to 90.9%. These figures were calculated on the fixed reviewed set, not established production performance across every kind of customer record.

The commercial sponsor wanted the higher headline percentage to justify an unattended rollout. Rina and I proposed an assisted route instead, with a ₹1.3 crore pilot allocation for implementation and review. Under the stricter rule, the 390 pairs not linked automatically still needed the appropriate handling route; they could not simply be labelled as different people. The review labels used for evaluation did not become a substitute for the evidence required in a live case.

The authorised pilot accepted more reconciliation work in exchange for fewer false links in the exercise. It did not establish that the chosen threshold was suitable for every future population or that all incorrect links had been removed. No automatic claim, coverage or adverse customer decision was delegated to the matching result. Operating owners retained the use decision, and the pilot retained examination of both error types.

I would now ask for the two error accounts before seeing a preferred performance headline. A data recommendation should explain which mistake becomes less frequent, which becomes more frequent and who bears the resulting work or risk. The point is not to choose a universally cautious threshold. It is to make the actual tradeoff understandable enough for the responsible decision-makers to judge it.

A 2025 proposal would have used existing party links to help connect people to an assisted insurance-service portal. The identity work was useful: it could help locate the relevant person. The proposal went further by treating a relationship in the customer reference as sufficient evidence for the access role shown in the portal. That step needed separate examination, particularly where a contact acted for a household or a business.

We reviewed 240 proposed connections. In 196, the documented role supported the intended access for the reviewed purpose. Forty-four needed further examination. Subsequent clarification supported limited roles for twenty-nine of those, while fifteen were withheld. The original identity relationship did not disappear; what remained unestablished was the authority required for the proposed access. I wanted those questions recorded separately so that a sound match could not silently approve a different decision.

The delivery sponsor argued that existing service colleagues already used the contact relationships and that repeating the review would slow adoption. I recommended a narrower route with a ₹93 lakh allocation for role evidence, handling and review, accepting a six-week delay. Technology and access-control owners implemented the authorised specification, while the appropriate operating, legal and privacy owners retained their responsibilities. My data function supplied the relationship account and its evidence, rather than granting permissions itself.

The outcome was 225 reviewed connections with supported roles for the specified use and fifteen withheld. It was not a universal assurance about every portal user, every future action or every linked record. The twenty-nine clarified cases did not all receive unrestricted access, and the work did not establish that a prior disclosure or security breach had occurred. The fifteen outstanding cases retained an assisted service route rather than being treated as adverse insurance findings.

This case changed the question I ask when a data link is reused. Knowing that two records concern the same person does not explain what that person is entitled to do. A new purpose needs its own meaning and authority, even when the identity evidence beneath it has already been examined carefully.