When Should AI Treat Two Customer Records as One?

A support agent finds two customer records with the same name and address. An AI tool recommends merging them. One click combines purchases and correspondence; later, the team discovers that two different people share the address. The software recognized similarity, not identity.

This is an illustrative scenario, not a ZharfAI customer result. It frames a decision for data teams and product owners: what evidence permits two records to represent one customer? Answer that before deleting duplicates, changing sales reports, or exposing a combined history. A matching score is an input to that decision, not permission to perform the merge.

Define the entity before choosing the matcher

A person, household, legal company, and corporate group are different entities. Two branches may belong to one company while requiring separate delivery addresses and operational accounts. An employee is not the employer. No improvement in name matching can repair a pipeline that silently changes which entity it means.

Write the intended relationship in one sentence: “These links identify records belonging to the same individual, not members of the same household.” For companies, specify the legal level and relevant time period. Keep “belongs to this group” separate from “is the same entity.” Our guide to knowledge-graph reasoning explains why the meaning of an edge matters as much as its existence.

Also separate linking from physical merging. A link preserves source identifiers and records a relationship. A merge may delete a row or replace values in a master record. This guide recommends making the identity decision in a link layer first. Changing the authoritative customer record should remain a separate operation with an accountable owner.

Normalize comparison fields without erasing evidence

Unicode defines normalization forms for equivalence between text strings. Its guidance warns against blindly applying compatibility normalization where removed distinctions carry meaning. This concerns text representation and comparison, not proof that two people are identical. Unicode UAX #15.

For Persian data, make transformations of digits, spacing, and Arabic or Persian letter forms explicit, versioned rules. Preserve the original value beside the comparison value. Tests should show which differences the rule intentionally removes and which it preserves. Aggressively stripping a company suffix or address component can make distinct parties look alike.

Keep identifiers as identifiers rather than automatically converting them to numbers: a leading zero may matter. Record the identifier type, issuing authority, and validity period. A matching string from another namespace is not necessarily matching evidence. An address from five years ago should not be treated as a simultaneous contradiction of today's address. Apply the distinction between event time and recorded time described in our temporal-truth guide.

Candidate selection sets the ceiling on recall

Comparing every record with every other record becomes expensive quickly. Splink's blocking documentation describes combining multiple rules to select candidate pairs. Their union determines which pairs receive further comparison; an exact-name rule alone excludes true pairs with spelling differences. Splink blocking rules.

An illustrative design might use one route for a validated identifier, another for surname plus part of a birth date, and a third for address plus approximate name similarity. These are design examples, not universal settings. Choose fields according to their actual quality and permitted use; do not collect additional sensitive information merely to make matching convenient.

The operational consequence is straightforward: a downstream model cannot recover a pair it never receives. Measure how many comparisons each rule adds and how many additional known true links it discovers. A more permissive rule spends compute and reviewer attention; a restrictive rule can hide duplicates. Embedding retrieval or an LLM proposing candidates belongs inside the same evaluation, not outside it.

Track missing-field groups separately. A route requiring a telephone number offers no coverage to customers without one. A strong overall result can conceal complete exclusion of a small group. Candidate generation therefore deserves its own tests rather than being treated as a harmless performance optimization.

Understand what the score represents

In the Fellegi–Sunter model, evidence weights compare the probability of an observation among matching pairs with its probability among nonmatching pairs. Prior match probability also matters. The simple combination of feature weights relies on conditional-independence assumptions. Splink's theory guide.

Three green indicators are not necessarily three independent witnesses. Full address, postcode, and street name may all originate in one field. Counting that information repeatedly can inflate apparent confidence. Name frequency and source quality also affect the usefulness of agreement; a common name should not be interpreted like a distinctive identifier.

An LLM's self-reported confidence is not automatically a calibrated probability. That interpretation requires evidence that pairs receiving similar scores are correct at the corresponding rate in an evaluation population appropriate to the application. Reassess the relationship when data sources or customer populations change. Product branding and extra decimal places do not supply that evidence.

Choose thresholds around the consequences of error

Combining two different customers and failing to find a duplicate have different costs. The former might expose another person's correspondence; the latter might inflate a customer count. A recommendation list for an analyst and an automatic change to a master record should not inherit one acceptance threshold merely because they use the same model.

Consider a hypothetical calculation: if each of 10,000 proposed links genuinely has a 99% probability of being correct, the expected number of incorrect links is 100. This is arithmetic under stated assumptions, not a product benchmark or a forecast. It depends on those probabilities being valid for that cohort; a displayed score of 99 does not establish them.

Use three outcomes: accept the link, send it for review, or retain separate or unresolved records. Include reviewer capacity when setting the boundaries, but do not lower the evidence requirement simply to empty a queue. If demand exceeds capacity, narrow automatic processing or change response expectations. A case left waiting is not a successfully resolved identity.

A three-record example makes the decision concrete

Suppose record A comes from the shop, B from support, and C from an older import. A and B share a validated identifier from the same authority but spell the name differently. C shares B's name and address, yet has a different validated identifier. C has no telephone number.

Here, “validated” means that the issuing authority, identifier type, and relevant validity period have been checked. A string of digits alone does not qualify. A and B are candidates for an accepted link. The conflict between B and C requires investigation or blocks linking; name similarity should not wash it away. C's missing phone number supplies neither agreement nor disagreement.

This table is ZharfAI's proposed operating method, not a universally validated threshold policy. A copied identifier or one belonging to another namespace can still mislead. The point is to preserve the question and its evidence, rather than laundering uncertainty through a confident-looking number.

One bad link can contaminate a whole cluster

Connected-components clustering groups records reachable through accepted links. Splink provides this method for pairwise predictions. Consequently, linking A to B and B to C places all three in one cluster even without a direct A-to-C link. Splink clustering documentation.

In the example, B must not become a bridge around the contradictory identifiers of A and C. Check a proposed addition against the entire cluster. Some contradictions require investigation; others, when their evidence is validated, should prohibit the connection. Enforce such constraints as testable rules outside free-form model output.

A rule allowing at most one record from each source makes sense only if that source is genuinely duplicate-free for the chosen entity definition and time period. A customer's multi-year history may legitimately contain several rows. Unusual cluster size or a link joining two large groups is an investigation signal, not proof of an error.

Evaluate beyond the accepted matches

Link precision is the proportion of accepted links that are correct; recall is the proportion of true links found. Valid measurement requires reference labels. Splink's evaluation guide also cautions that pair-level evaluation is insufficient when the application delivers clusters. Splink edge evaluation.

Reviewing accepted links alone does not reveal missed links. Guidance published in the UK government's data-linking collection also explains that clerical reviewers are constrained by the available information; human judgment cannot recover absent evidence. Quality assessment in data linkage.

Build evaluation samples covering common names, incomplete records, Persian writing variations, new sources, and cases on both sides of each threshold. Independently search a sample of unlinked records. Do not turn unresolved cases into certain negative labels. For stratified sampling, explain population weights and uncertainty: a simple average of deliberately oversampled difficult cases does not describe all customers.

Separate training and testing at entity level where feasible, not merely at record-pair level. Versions of the same customer in both sets can make the test optimistic. Report mixed-identity clusters, review time, reversed decisions, and unresolved cases alongside precision and recall. Product owners need to know which errors remain and whom they affect, not just whether one headline percentage improved.

Keep the identity layer reversible

ZharfAI's proposed architecture has source records, versioned comparison fields, and a link ledger. For each decision, retain both source identifiers, the candidate-generation rule, supporting and conflicting evidence, model and rule versions, validity time, status, and decision owner. Apply access and retention limits to this evidence too; traceability is not permission to duplicate personal information indefinitely.

Downstream consumers should receive a link identifier and version with the result. If a connection is later rejected, the team needs to identify affected reports, caches, and customer views. Test reversal on an illustrative cluster: withdraw the link, rebuild derived views, and list effects requiring human correction. Reversing a link does not automatically retract a sent message or undo an executed decision.

Identity also does not confer authorization. Records held by two organizations might refer to one person, but their users' permissions must not be unioned because the records match. Preserve source-level access checks at read time, following the boundary discussed in our multi-tenant isolation guide.

Give the language model a bounded job

Assign tasks that remain inspectable: extracting an address component with its source passage, suggesting candidate pairs, or describing field disagreements. Until checked, extracted values are not equivalent to verified source data. The model must not invent a missing identifier or treat instructions embedded in correspondence as authority to merge records. Input content is potential evidence, not an executable order.

Show reviewers the original records and contradictions beside the recommendation. Allow “insufficient evidence.” The US Census Bureau's C4 standard emphasizes documented linkage rules, testing, reviewer training, and error measurement. It governs statistical linkage within that institution; here it is an engineering reference, not a legal obligation imposed on an Iranian business. Census Standard C4.

After release, monitor source-format changes, increasing missingness, review backlogs, sudden cluster growth, and link reversals. Significant changes to normalization rules or the model warrant reevaluating the difficult cases. The final question is not whether two names look alike. It is whether this application has enough evidence for this consequence—and a workable way to correct the decision.

Source notes — reviewed September 13, 2026

This is ZharfAI analysis and a proposed design guide. Examples are hypothetical; no deployed-system validation or customer performance result is claimed. Source versions and dates:

1. US Census Bureau, Statistical Quality Standard C4, page last revised October 8, 2021; statistical-linkage quality controls.
2. UK government collection, Quality assessment in data linkage, updated July 16, 2021; measurement and review limitations.
3. Unicode UAX #15, revision 57, July 30, 2025, Unicode 17; text equivalence.
4. Splink, Fellegi–Sunter theory, undated documentation, accessed on the article's review date.
5. Splink, blocking rules, undated documentation, accessed on the article's review date.
6. Splink, edge evaluation, undated documentation, accessed on the article's review date.
7. Splink, clustering, undated documentation, accessed on the article's review date. These four Splink pages belong to the UK Ministry of Justice project; they are not four independent organizational sources.