Lesson 5 — Entity Resolution, Matching, and Reversibility
Entity resolution answers one deceptively simple question:
Do these records refer to the same real-world entity or to different entities?
Because the answer changes enterprise identity, mistakes can be expensive. Chapter 10 therefore cares about methods, error types, workflow strength, stewardship, and the ability to reverse bad decisions.
Candidate identification vs identity resolution
Candidate identification finds records worth comparing. Blocking, indexing, rules, or similarity methods narrow the search to plausible pairs.
Identity resolution makes or maintains the final same/different-entity decision.
Do not confuse “we found a similar record” with “we proved it is the same entity.”
Similarity analysis
Candidate records are compared on relevant evidence: names, addresses, identifiers, dates, phones, relationships, or other domain-specific attributes. The evidence can be evaluated deterministically or probabilistically.
Deterministic matching
Uses explicit predefined rules or patterns. With the same inputs and rule set, the result is repeatable and easy to explain.
Example:
Match when normalized SSN and DOB are exact.
Strengths: explainability and consistency.
Limitation: fixed rules can miss variations designers did not anticipate.
Probabilistic matching
Estimates likelihood statistically from weighted evidence and can be trained or tuned using observed outcomes.
Example:
Weigh name similarity, address evidence, phone, DOB, and other signals to estimate the probability that two records represent the same person.
It can handle fuzzier variation, but thresholds, training data, false-match risk, and stewardship remain governance concerns.
False positive vs false negative
False positive
The process says same entity when the records actually represent different entities.
Example: two different Jane Smiths receive one Global ID.
Memory cue: the system gave a positive “same” decision that was false.
False negative
The process says different entities when the records actually represent the same entity.
Example: one customer remains under two Global IDs.
The cost of each error differs by domain. Merging two people can have more serious consequences than temporarily leaving a duplicate unresolved, so thresholds cannot be set without business-risk context.
Three reconciliation workflows
Duplicate identification — flag only
The system flags likely duplicates for review but does not change identity.
Best when uncertainty or risk makes automatic action unsafe.
Match-link — connect identity, preserve source content
Confirmed same-entity records are linked through cross-reference/identity relationships while source attributes remain intact.
It supports enterprise identity with relatively easier reversal.
Match-merge — reconcile content
Records are combined into a unified master representation. The process must decide which values survive when sources disagree.
This is why survivorship/trust rules matter.
Intervention and reversal complexity generally increase:
Flag → Link → Merge
Why match history is governance evidence
Incorrect decisions must be correctable. History supports: - unmerge/remerge; - auditability; - investigation of false matches; - metrics; - rule/model tuning; - steward feedback; - reconstruction of prior identifiers and values.
A merge without sufficient history can make it difficult to restore the two original identities after a false positive.
Example
Two customer records have the same name and address but different tax identifiers. The cost of falsely merging them is high.
A sensible response is duplicate identification + steward review, not automatic match-merge.
If later evidence confirms they are the same entity and consumers need a unified profile, the workflow can move to match-merge with survivorship and reversible history.
Stop and check
- Different people combined = false positive.
- Same person left separate = false negative.
- Similarity rules = matching method.
- Flag/link/merge = reconciliation workflow after match evidence.
Source anchor: pp. 343–346.