Key takeaways
- Entity resolution decides which records refer to the same real-world entity.
- Similarity is evidence for a candidate match, not a guarantee of identity.
- Preserve relationships and uncertainty when names, domains or employment change.
Overview
Resolution can use deterministic rules, probabilistic matching or a combination. The correct approach depends on the available identifiers and the cost of false matches. Keep entity identity separate from relationships: a person working for a company is not the same entity as that company, and two subsidiaries need not be merged because they share a parent.
How it works
Choose the entity type and prepare comparable identifiers.
Generate candidate matches and evaluate supporting and conflicting evidence.
Assign stable identities, retaining uncertain matches for review.
Choose the entity and the scope
A person, a company, a household and a device are different entity types. In B2B workflows, distinguish a person from their current employment relationship and a corporate parent from a subsidiary. If the scope is unclear, a matching system can be technically consistent while answering the wrong identity question.
Define the identifiers available and their reliability. A source-issued profile ID may be strong within that source, while a name and city may only narrow the candidate set. Document when identifiers can be reassigned or shared. No single field should be treated as universally definitive without understanding the source and the entity model.
| Evidence | Useful role | Limitation |
|---|---|---|
| Stable source identifier | Connect repeated records within a source | Requires consistent source scope |
| Domain and location | Narrow the organization candidate | Brands and subsidiaries may share infrastructure |
| Name similarity | Find spelling variants and aliases | Namesakes can look nearly identical |
| Relationship evidence | Explain parent, subsidiary or former employer links | Related entities are not necessarily the same entity |
Separate candidate generation from acceptance
Candidate generation should find plausible matches without comparing every record with every other record. Acceptance then applies stronger evidence to decide whether a candidate is the same entity. These stages have different goals: a broad candidate search can tolerate some irrelevant options, while an automatic merge needs a much higher standard.
Retain unmatched and ambiguous outcomes. If two companies share a name and neither has a reliable domain, the correct result may be unresolved. Adding fields from the top search result simply to complete the record can create a chain of incorrect enrichment, scoring and delivery decisions.
Measure false matches and missed matches
An illustrative review of 100 proposed matches finds 92 correct, five incorrect and three unresolved. Report all three groups and state how the reference was established. Also inspect known matches the system missed; a conservative matcher may produce accurate accepted results while leaving a large share of the population unresolved.
The cost of errors depends on the action. A candidate suggestion can tolerate more uncertainty than merging customer records or transferring account history. Use thresholds that reflect those consequences and retain the match explanation. When source data or matching rules change, review representative cases before applying new identity decisions to existing relationships.
What this looks like in practice
“Acme Robotics Ltd.” and “Acme Robotics” share a domain and registration identifier, supporting a match. A similarly named company in another country with a different domain remains separate.
Examples explain the concept; they are not reported customer results.What to check
Test match precision, recall and difficult cases such as shared names, acquisitions and job changes. Document which identifiers are authoritative for each entity type.
Common mistake
Using string similarity alone as proof of identity or allowing a low-confidence match to trigger irreversible updates.
Entity resolution vs. Data deduplication
Entity resolution establishes identity across records. Deduplication is one application of that identity decision; resolved records may remain separate for source history or analysis.
Read the Data deduplication definition →Questions answered
What is Entity resolution?
Entity resolution determines which records from one or more sources refer to the same real-world person, organization or other entity, despite differences in identifiers or representation.
Is an exact match always correct?
No. An exact name or shared address can belong to different entities. The identifier’s uniqueness and context matter.
What should happen to uncertain matches?
Retain the candidates and evidence with an explicit uncertainty state. Use a review threshold appropriate to the consequence of a wrong match.
Is entity resolution the same as deduplication?
Entity resolution determines which records refer to the same entity or to related entities. Deduplication uses that identity decision to reconcile repeated records. Resolution can also connect records across systems without merging them, which is useful when each source needs to preserve its own representation.
Can a confidence score replace match evidence?
No. A score can help prioritize or automate decisions if its meaning is validated, but reviewers still need the identifiers and observations behind it. A high score produced from weak or correlated fields can be misleading. Preserve uncertainty and test the threshold against the specific action being authorized.
References and further reading
Primary documentation and source material for this topic. Sources checked September 14, 2026; provider requirements can change.
Continue reading on the blog
Explore all articles and guides →Put the concept to work.
Explore the relevant AstroFabric workflow and see how the pieces connect.
Help keep this guide useful. Suggest a correction or browse the full glossary.