Entity Resolution: When One Bad Link Joins Two People

An AI assistant can retrieve genuine records, cite them correctly and still describe the wrong person. The error may precede retrieval: a matching pipeline decided that several source records belonged to one identity. Once their histories share an entity identifier, the answering model sees an apparently coherent customer profile. Better prompting cannot reliably recover the boundary that the data pipeline removed.

The consequential decision is when a proposed record link may change membership of an operational identity cluster. It is more demanding than choosing which pairs deserve a closer look. One accepted edge can connect two large collections of records, including pairs that were never compared directly.

Our master-data operating guide covers ownership, correction and reversible merges. This technical companion examines the graph underneath those merges. Primary documentation establishes the matching mechanisms; the promotion policy and synthetic example below are AIEngine's engineering analysis, not results from an AIEngine deployment.

Define the identity before computing similarity

Write down what one cluster is supposed to represent. A person, household, account and company group are different entities. Two people may share an address and contact channel while holding separate accounts. Conversely, one person may legitimately have multiple accounts. A system cannot learn its way out of an undefined unit of identity.

Define the scope of identifiers too. An account number unique within one source is not necessarily unique across sources. A changed identifier may represent a migration, while a reused contact channel may represent a different owner. Record the issuing system and relevant dates alongside values used for matching.

Keep relationship types separate. “Same household”, “contact for” and “possible duplicate” should not silently become “same person”. For AI retrieval, an association can support discovery without authorising every associated document to appear in one person's profile. Access checks must remain attached to the underlying records, not inferred from cluster membership.

Before modelling, write two or three examples of legitimate disagreement and two of impossible membership. These are application requirements, not training hints. A valid change of address belongs in the former; two independently verified, mutually exclusive identities may belong in the latter, once the identifier's actual guarantees have been checked.

Understand what the pair score actually means

Splink's Fellegi–Sunter explanation distinguishes a prior probability of matching from the probability of an observed comparison among matches and among non-matches. Evidence depends on how surprising an agreement would be between different entities, not merely how similar two strings look. Its basic combination of comparison evidence assumes independence between comparisons.

That matters when designing features. Counting an email address, its extracted name and a name field copied from that same address as three independent confirmations can exaggerate the evidence. Inspect where each field came from before deciding that agreement across columns is corroboration.

Splink's term-frequency guidance addresses another problem: common and uncommon values need not provide equal evidence. Agreement on a widely shared surname is less distinctive than agreement on a rare one. Frequency adjustments help represent that difference; they do not make a rare typo or fabricated identifier trustworthy.

An embedding similarity or language model's stated confidence is not automatically a calibrated identity probability. If either proposes candidates or comparison features, evaluate it against adjudicated matches and non-matches from the intended population. Keep the original values and transformation history available to reviewers. A fluent explanation of a match should never substitute for the evidence that supports it.

Audit the pairs the model never sees

Comparing every record with every other record rapidly becomes expensive. Splink's blocking documentation describes generating only pairs satisfying selected rules, with multiple rules combined so that satisfying any one can admit a pair. Its example shows how an exact-name rule misses a true match containing a name typo.

The operational implication is easy to miss: lowering the match threshold cannot recover a pair that was never generated. A scoring evaluation restricted to candidates therefore cannot establish end-to-end linkage recall.

Test candidate generation separately. For each known matching pair, record whether at least one blocking rule admitted it. Examine misses involving changed addresses, incomplete names, transliteration and missing fields. Add a complementary rule only after measuring both the additional true matches and the additional comparison workload it creates.

Keep three states distinguishable in the output: not compared, compared without enough supporting evidence, and rejected because of a verified contradiction. Treating all three as a negative match erases the information needed to debug coverage and safely reconsider a record later. A missing comparison is neither evidence of equality nor evidence of difference.

Follow one false link through the whole cluster

Splink's clustering API documents connected-components clustering over pairwise predictions above a threshold. Connectivity is transitive: if A connects to B and B connects to C, all three enter the same component. That does not establish that the observed evidence for A and C was compatible.

Consider this deliberately synthetic test fixture. The numbers are illustrative model outputs, not measured performance or recommended thresholds. Suppose a candidate matcher accepts scores of 0.95 or higher:

Connected components over the three accepted edges place A, B, C and D together. The B–C edge defeats the identity boundary even though A–B and C–D are sound. If a profile summary then joins every member's correspondence, a correct source citation can support a statement about the wrong customer.

The test should fail at cluster promotion. Preserve the verified A–B and C–D associations, hold the B–C proposal for review and prevent the contradictory component from becoming operational. Simply choosing the most complete record as the representative does not resolve the conflict; it hides the other identity behind a convenient display record.

Also test the converse. Remove the A–D contradiction and provide legitimate evidence that all four records belong together. A policy that rejects every chain-shaped cluster would now miss a valid identity. Good tests distinguish an unsupported connection from an unfamiliar but genuine history.

Use graph structure to direct review, not declare truth

A bridge is an edge whose removal divides a connected component. Splink's graph-metrics guide identifies bridges as useful signals for investigating false links, especially between otherwise well-connected groups. It also warns that graph metrics are rarely definitive in isolation and depend on the underlying dataset.

For an operational review queue, prioritise connections that change many records' interpretation. A new edge joining two established clusters usually deserves more attention than another supporting edge inside one well-evidenced cluster. This is a consequence-based prioritisation rule, not a claim that all bridges are wrong.

Ask reviewers to inspect the whole proposed component and its conflicting evidence. Show source records, dates, the triggering pair, existing membership and the downstream products affected. A screen containing only the two highly similar names encourages approval of the local comparison while concealing the global consequence.

Large or dense clusters need context. A frequent customer may generate many legitimate records. A copied default contact value can generate many mutually consistent but false links. Neither size nor density should become an automatic certificate of quality. Where a source is genuinely duplicate-free, source-cardinality constraints can help, but an undocumented assumption of uniqueness can also split real identities.

Give cluster promotion an explicit [contract](/industries/legal)

Separate the graph used for exploration from the graph consumed by operational AI. Candidate edges may exist without changing the accepted mapping. The following contract is a proposed design, adaptable to the consequences of the application:

• Every member retains its source-system and source-record identifiers.
• Every proposed edge records comparison evidence, model version and decision rule.
• Not-compared pairs remain distinguishable from adjudicated non-matches.
• Verified cannot-link constraints are checked across the entire proposed component.
• Component changes identify which previously separate groups would be joined.
• Unresolved conflicts prevent operational promotion, without deleting the proposal.
• Review decisions include their evidence and the scope of identity they establish.
• Published mappings have a revision, effective time and explicit supersession history.

Do not demand direct positive comparisons between every pair as a universal remedy. Sparse records can be correctly connected through complementary evidence, and exhaustive comparisons may be costly. Instead, choose the cluster invariants that the use case can justify, then evaluate the false merges and fragmentation they produce.

Avoid irreversible union-only storage when corrections matter. Removing one accepted edge may require recomputing a component and updating downstream membership. Keep the accepted edge set and source evidence so a split can be reconstructed. Our AI data-deletion guide describes the related problem of propagating changes through derived stores; identity corrections likewise need a consumer inventory, not just an edited lookup table.

Measure linkage quality and fitness for the AI task

The ONS data-linkage policy explicitly rejects match rate as a quality metric and calls for precision and recall estimates. It also asks projects to understand how matching errors and bias affect subsequent analysis. This is ONS policy for its linkage work, not a universal commercial compliance rule.

Measure at more than one level. Pair precision asks how many accepted links are correct. Pair recall asks how many true links were found. Neither alone shows whether a complete customer profile mixes different people or whether one person's history has fragmented across several profiles.

Statistics Canada's 2017 Record Linkage Project Process Model separates internal linkage validation from external fitness-for-use validation. It describes assessing errors, examining sub-populations and unlinked records, and repeating validation after adjusting the strategy. That separation remains useful for AI systems: a linkage model can improve its own score while making an application's customer histories less dependable.

Use a probability sample for population estimates and a separately reported challenge set for difficult cases. Oversampling bridge links is useful for finding defects, but its raw error proportion is not the population error rate. Keep reviewer disagreements and unknown identities visible; do not force uncertain labels to manufacture a clean benchmark. Report sample sizes and uncertainty alongside any estimated rates.

Re-test the join when the evidence changes

Treat a new source, normalisation change, blocking rule, model or threshold as a new linkage release. Compare old and proposed membership, then examine cluster joins and splits before refreshing retrieval indexes. Hold the retriever and answer model fixed when measuring downstream attribution, following the diagnostic logic of our retrieval-quality audit.

Retain a small regression suite containing the false-bridge fixture, genuine sparse chains, shared contact details, reused source identifiers and late-arriving contradictory evidence. Verify both initial promotion and correction after a mapping has already been consumed. Include a test where a rejected edge remains stored for investigation but cannot influence the production profile.

Monitor disputed memberships, reviewed bridge outcomes, correction age and wrong-entity retrieval separately from linkage throughput. Revisit the policy when the source population or consequences change, not only when the model changes. The useful release claim is specific: these mappings meet these identity constraints and measured error tolerances for this application. A high pair score cannot make that claim on its own.