A cleaner customer list can contain a worse assertion

## Name the assertion hidden inside the merge

Data-cleaning proposals often begin with a count of apparent duplicates. The count suggests an obvious improvement: fewer records, less repeated administration and a more coherent view of the customer. Those benefits can be real. The difficult question is what makes two records duplicates rather than related records that should remain distinct. A shared office, telephone number or contact person may explain a relationship without establishing a single legal entity. If the system combines the records before that distinction is examined, the apparent improvement includes a business assertion that nobody may have explicitly agreed to make.

At the fictional Qorzuni, a project proposed 740 customer-record merges based on similarities across names and contact details. Commercial-insurance colleagues warned that several organisations could use the same office or intermediary contact. A person coordinating enquiries could act for more than one entity. A name could also be abbreviated differently in two places without the records necessarily describing the same contractual customer. The point was not that matching tools had no value. They had found a useful review population. The mistake would have been to treat that population as a completed identity decision merely because the software could produce a confidence score.

I asked the team to describe the consequence of a merge in business language. Which entity would the combined record represent? What documents would become associated with it? Who would be able to see or act on them? What would happen if the combination proved wrong? Those questions made the change more substantial than reducing a database count. Technology needed the answers from authorised business owners, with appropriate professional input where required. An engineering team could implement a merge accurately and still implement the wrong assertion. Correct execution cannot compensate for an unsupported conclusion about what the records mean.

There was a reasonable argument for proceeding quickly. Repeated records created administrative effort and made it harder for colleagues to understand the full relationship. The commercial sponsor did not invent those costs, and I did not want to use uncertainty as a reason to leave every inconsistency untouched. The review needed to produce decisions, including accepted merges where the evidence supported them. It also needed a way to retain distinct identities and unresolved matches without forcing them into the same outcome. A useful process can be cautious about a particular assertion while still making progress on the population it is capable of resolving.

## Keep a relationship without forcing a single identity

We allocated ₹62 lakh to business review, evidence handling and the revised workflow. Authorised colleagues examined the proposed relationships, while technology displayed candidate links and retained the basis for the resulting decision. A common contact could be represented as a relationship between records instead of as proof that the records belonged to one entity. That distinction helped preserve useful context without erasing the boundary that mattered. It also required the interface to show the relationship clearly enough that a user would not casually interpret linked records as interchangeable customer identities.

The 740 proposals divided into 196 accepted same-entity matches, 487 distinct entities and 57 unresolved cases. The categories added back to the original population. We followed the approved process for the 196, kept the 487 separate and held the 57 for further evidence. An unresolved match was not treated as a fraud finding, a negative credit assessment or a reason to change an insurance decision. Those would be different conclusions requiring their own evidence and authority. The identity review had a defined purpose, and the account was stronger when it stayed within that purpose rather than implying every related business question had also been settled.

Keeping unresolved records separate created continuing work. Colleagues sometimes had to examine more than one file, and some of the promised administrative simplification remained unavailable. I wanted that cost acknowledged rather than hidden behind a statement that review had made the data safer. The chosen approach was a tradeoff: retain inconvenience where the evidence did not yet support combination, while improving the relationships and accepted matches that could be represented responsibly. A board should be able to see why management considered that tradeoff preferable, what work remained and who would decide when further evidence changed the account.

The review also changed the conversation with the supplier. We needed the product to support an owned decision, not merely improve a similarity score. The relevant evidence had to remain available, and the process needed to distinguish an accepted merge, a rejected merge and a case still awaiting examination. Those states served different purposes. Calling all three processed would have been technically possible and operationally misleading. The company needed to know what the decision had been, not only that someone had opened the record. That requirement was as much about the business workflow as the matching method used to propose the original candidates.

## Measure the quality of the decision, not only the smaller count

A reduction of 196 accepted duplicate proposals is less dramatic than announcing that 740 records were cleaned. It is also more faithful to the work. The 487 distinct entities were an important result because keeping them apart preserved a meaningful boundary. The 57 unresolved cases were equally important because they showed where the process had reached its limit. A completion report should retain those categories rather than rank the project only by the amount of consolidation achieved. Otherwise, the measure rewards an action even when deciding against that action is the more responsible outcome.

We did not claim that the entire customer population had been verified. The work concerned the 740 proposals generated and reviewed in this project. Other records could still contain different issues, and later changes would need ongoing ownership. A correct relationship at one point does not remove the need to handle a new contact, a changed entity or a correction. The project therefore improved a defined population and the method used to decide future proposals. It did not provide a permanent certificate of data quality. That narrower claim helped keep operating responsibility visible after the project team had delivered its release.

For directors, the useful question is what consequential assertions management allows software to make. Customer identity is one example, but the principle applies whenever a technical operation changes the business interpretation of records. Does the system propose a relationship or conclude it? Which conclusions require an authorised owner? Is uncertainty preserved in a usable form, and does the reported benefit include the work still needed to resolve it? A board can ask those questions without becoming the design authority. The objective is to know whether a material decision has been made consciously and whether the evidence matches the consequence of that decision.

I have become careful with the word clean in technology papers. It can describe a useful improvement, but it can also conceal the complexity removed from view. In the Qorzuni case, a more responsible customer view contained accepted combinations, explicit relationships, separate entities and unresolved questions. It was not the smallest possible list. It was a list whose structure better reflected what the company knew. That is the outcome I would defend: administrative simplification where justified, preserved boundaries where they mattered and an honest account of the cases that still required someone to establish what the record represented.