Entity Resolution: The Unsexy Problem Behind Every Clean Dataset

A resolution pipeline merges two customer records that share a surname, a postcode, and a phone number that one of them changed last year. The merged record inherits both purchase histories, both marketing preferences, and one of the two email addresses. Six weeks later the wrong person receives a communication referencing a purchase they did not make, and unpicking the merge means finding every downstream system that consumed the merged identifier. The match was reasonable on the evidence. The merge was irreversible, which is the part that made it expensive.

A wrong match and a missed match are both errors. Only one of them is difficult to undo.

Entity resolution means deciding which records refer to the same real entity, with match thresholds reflecting that false merges cost more than false splits, survivorship rules explicit, and merges reversible.

Is Your Engineering Velocity Real, or Just a Reporting Illusion?

Discover whether your engineering velocity reflects real output or hidden inefficiency.

Download Whitepaper

However, most pipelines tune for match rate and treat the merge as a final state, which makes the more expensive error the one they optimise toward.

If you are a CTO or Head of AI at an enterprise, the intent of this article is:

Define why false merges cost more than false splits
Show what survivorship rules must decide
Lay out how reversibility is designed in

To do that, let's start with the basics.

What Is Entity Resolution? The Basic Definition

At a high level, entity resolution determines which records across systems refer to the same real-world entity: a customer, a supplier, a property, a product. Two errors are possible. A false split leaves one entity as two records, which produces duplicate communications and fragmented history, and is fixable later by merging. A false merge combines two entities into one, which propagates a wrong identity into every downstream consumer and is fixable only by reconstructing what was combined. Those costs are not symmetric, which means the threshold should not be set as though they are.

To compare:

A false split is filing one person's documents in two folders. Annoying, and both sets are intact. A false merge is combining two people's folders and shredding the dividers. The information is now mixed, and separating it requires knowing what belonged where before.

Why Does Entity Resolution Matter?

Issues that it addresses or resolves:

False merges propagating wrong identity downstream
Match thresholds tuned as if errors were symmetric
Survivorship decided implicitly by load order

Resolved Issues by Resolution Done Well

Thresholds reflecting asymmetric error cost
Survivorship rules explicit and reviewable
Merges reversible rather than final

Core Components of Entity Resolution

Matching with calibrated confidence
Thresholds reflecting error asymmetry
Survivorship rules per attribute
Merge lineage enabling reversal
Downstream consumption aware of identifier stability

Modern Entity Resolution Tooling

Probabilistic matching with confidence scores
Review queues for the uncertain band
Explicit survivorship configuration
Merge lineage retained for reversal
Identifier stability contracts for consumers

These tools make identity correctable. Retained merge lineage is what turns an irreversible mistake into a fixable one.

Other Core Issues They Will Solve

Wrong identity correctable rather than permanent
Attribute selection deliberate rather than incidental
Downstream systems tolerant of identifier change

In Summary: Entity resolution should be tuned for the asymmetry between false merges and false splits, with explicit survivorship and retained lineage so merges can be undone.

Importance of Entity Resolution in 2026

Identity underpins personalization, fraud, and reporting. Four reasons explain why this matters now.

1. Merged identity propagates fast.

Downstream systems consume the identifier within hours, which multiplies the cost of a wrong merge.

2. Match rate is the wrong headline.

A high match rate can mean good resolution or an aggressive threshold producing false merges.

3. Survivorship is usually accidental.

Which email or address survives a merge is frequently determined by load order rather than by a rule.

4. Reversal is rarely designed for.

Without retained lineage, undoing a merge means reconstructing it from memory and exports.

Traditional vs. Modern Entity Resolution

Match rate optimised vs. error asymmetry reflected
Merge as final state vs. merge as reversible
Survivorship by load order vs. explicit per-attribute rules
Consumers assuming stable identifiers vs. contracts for change

In summary: A modern approach treats a merge as a reversible decision with explicit rules and asymmetric thresholds.

Details About the Core Components of Entity Resolution: What Are You Designing?

Let's go through each component.

1. Matching Layer

Deciding sameness.

Matching decisions:

Attributes and weights defined
Confidence calibrated
Blocking strategy for scale

2. Threshold Layer

Where to act.

Threshold decisions:

Auto-merge threshold set conservatively
Review band defined for uncertainty
Auto-split threshold separate

3. Survivorship Layer

Which value wins.

Survivorship decisions:

Rules per attribute rather than per record
Recency, source authority, or completeness chosen deliberately
Rules documented and reviewable

4. Lineage Layer

Undoing merges.

Lineage decisions:

Pre-merge state retained
Merge events recorded with evidence
Reversal procedure tested

5. Consumption Layer

Downstream tolerance.

Consumption decisions:

Identifier change contract published
Consumers handling reassignment
Propagation of reversals

Benefits Gained from Resolution Done Well

Wrong merges correctable rather than permanent
Attribute survivorship deliberate
Downstream systems tolerating identity change

How It All Works Together

The enterprise sets the auto-merge threshold conservatively and the auto-split threshold separately, because the two errors have different costs and a single threshold implicitly claims otherwise. The band between them becomes a review queue rather than a coin flip, which concentrates human attention on exactly the cases where evidence is ambiguous. Survivorship is configured per attribute with a deliberate basis, recency for contact details, source authority for regulated fields, completeness for descriptive ones, rather than being determined by whichever record loaded second. Pre-merge state and merge evidence are retained so a reversal is a procedure rather than a reconstruction, and that procedure is tested rather than assumed. Downstream consumers are given a published contract about identifier reassignment so a reversal propagates instead of leaving each system holding a stale identity.

Common Misconception

Our match rate is high, so resolution is working.

A high match rate is produced equally by good resolution and by an aggressive threshold, and the two are distinguishable only by looking at the errors. An aggressive threshold merges records that share incidental attributes, which raises the match rate, reduces apparent duplication, and produces exactly the error that is hardest to undo. Meanwhile a conservative threshold leaves some duplicates, which looks worse on the metric and is straightforwardly fixable later. Match rate as a headline metric rewards the more expensive failure mode, which is why threshold decisions should be framed around error cost instead.

Key Takeaway: A high match rate is equally consistent with good resolution and an aggressive threshold. The metric rewards the expensive error.

Real-World Entity Resolution in Action

Let's take a look at how it operates with a real-world example.

We worked with an enterprise whose merged records propagated a wrong identity downstream, with these constraints:

Set merge and split thresholds separately by error cost
Configure survivorship per attribute deliberately
Retain lineage so merges can be reversed

Step 1: Separate the Thresholds

Two errors, two decisions.

Auto-merge set conservatively
Auto-split set separately
Review band defined

Step 2: Queue the Uncertain Band

Human attention where it counts.

Ambiguous cases routed to review
Evidence presented to reviewers
Decisions captured as training signal

Step 3: Configure Survivorship

Per attribute.

Basis chosen per attribute
Recency, authority, or completeness
Rules documented

Step 4: Retain Lineage

Make reversal possible.

Pre-merge state retained
Merge evidence recorded
Reversal procedure tested

Step 5: Contract with Consumers

Propagate reversals.

Identifier change contract published
Consumers handling reassignment
Reversals propagated

Where It Works Well

Domains with attributes supporting confident matching
Pipelines able to retain pre-merge state
Consumers able to handle identifier reassignment

Where It Does Not Work Well

Single threshold for merge and split
Survivorship determined by load order
Merges treated as final with no lineage

Key Takeaway: Separate the thresholds, queue the uncertain band, configure survivorship, retain lineage, and contract with consumers.

Common Pitfalls

i) Treating errors as symmetric

A false merge propagates a wrong identity and is hard to undo; a false split is fixable. One threshold treats them as equivalent. Set them separately.

The match was reasonable on the evidence
The merge was irreversible
That is what made it expensive

ii) Survivorship by load order

Which email survives a merge should be a rule, not an accident of ingestion sequence. Configure per attribute.

iii) No retained lineage

Without pre-merge state, reversing a merge means reconstructing it from exports and memory. Retain it and test the reversal.

iv) Consumers assuming stable identifiers

A reversal that cannot propagate leaves downstream systems holding a stale identity. Publish a change contract.

Takeaway from these lessons: The merge is a decision that will sometimes be wrong, so design for correcting it rather than for avoiding it perfectly.

Entity Resolution Best Practices: What High-Performing Teams Do Differently

1. Set merge and split thresholds separately

Reflect the asymmetry in error cost rather than implying with one number that the errors are equivalent.

2. Route the uncertain band to review

Put human attention exactly where the evidence is ambiguous, and capture those decisions as signal.

3. Configure survivorship per attribute

Choose a deliberate basis per field rather than letting ingestion order decide which values survive.

4. Retain merge lineage and test reversal

Make undoing a merge a procedure rather than an archaeology exercise.

5. Publish an identifier change contract

Let downstream consumers handle reassignment so corrections actually propagate.

Logiciel's value add is helping enterprises design entity resolution around error asymmetry and reversibility, so identity decisions can be corrected rather than lived with.

Takeaway for High-Performing Teams: Separate thresholds, queue ambiguity, configure survivorship, retain lineage, contract for change.

Signals You Are Doing Entity Resolution Well

How do you know it is working? Not by match rate, but by whether a wrong merge can be undone this week. These are the signals that separate correctable identity from permanent identity.

Thresholds differ. Merge and split are set separately by cost.

Ambiguity is reviewed. The uncertain band goes to people.

Survivorship is configured. Each attribute has a documented basis.

Lineage exists. Pre-merge state is retained and reversal is tested.

Consumers cope. Identifier reassignment propagates downstream.

Adjacent Capabilities and Connected Work

This work does not exist in isolation. Entity resolution depends on, and feeds into, the surrounding platform. Ignoring the adjacencies is the most common scoping mistake.

Master data management owns the survivorship policy. Customer 360 consumes the resolved identity. Fraud detection depends on linkage being correct. Document processing supplies references needing resolution. Naming these adjacencies upfront keeps the work scoped and helps leadership see reversibility as the deliverable.

The common mistake is treating each adjacency as someone else's problem. The threshold asymmetry is your problem. The survivorship configuration is your problem. The lineage retention is your problem. Pretend otherwise and a reasonable match will produce a permanent wrong identity. Own the adjacencies you depend on, partner with the teams that hold them, and share the rules.

Conclusion

Entity resolution makes two kinds of error and they cost very different amounts. A false split leaves one entity as two records, which fragments history and duplicates communications and can be merged later. A false merge combines two entities, propagates a wrong identity into every downstream consumer within hours, and can only be corrected by reconstructing what was combined. Tuning for match rate rewards the expensive error, because an aggressive threshold raises the metric. Set merge and split thresholds separately by cost, route the ambiguous band to review, configure survivorship per attribute, retain pre-merge lineage, and publish an identifier change contract.

Key Takeaways:

False merges cost more than false splits and are much harder to undo
Match rate as a headline metric rewards the more expensive error
Survivorship determined by load order is a decision nobody made

Doing entity resolution well requires designing for reversal. When done correctly, it produces:

Wrong merges correctable rather than permanent
Attribute survivorship that was actually decided

Why Great CTOs Don't Just Build, They Evaluate

Learn how disciplined evaluation separates credible AI systems from hype.