Entity Resolution
Our data layer resolves records from different systems into persistent company entities before higher-level reasoning is applied.
The problem
The same customer may appear as ABC Holdings LLC in accounting, ABC Holdings in a CRM, ABC in email, and under multiple contacts or historical identifiers elsewhere. Employees can appear under legal names, nicknames, changed email addresses, or duplicated profiles.
If those records are treated as different entities, downstream retrieval, financial analysis, relationship mapping, and automation can all become incorrect.
Resolution path
Our entity-resolution process can combine multiple classes of evidence:
- Source records
- Normalization
- Deterministic identifiers
- Aliases + fuzzy matching
- Relationship evidence
- Probabilistic resolution
- Canonical entity
We prefer deterministic evidence where it exists: stable cross-system IDs, exact identifiers, authoritative mappings, or known aliases.
Where deterministic resolution is unavailable, additional signals can include normalized names, historical identifiers, associated people, accounts, contracts, locations, and other relationship evidence. Fuzzy or probabilistic matching is used only where ambiguity warrants it.
Canonical entity types can include customers, employees, managers, vendors, companies, locations, accounts, and contracts.
Canonical does not mean destructive
Source records are not interchangeable merely because they resolve to the same real-world entity. The canonical layer preserves the relationship back to underlying records so that provenance, source-specific fields, and conflicting evidence remain inspectable.
Entity resolution is not the same as deleting duplicates.
Two records can refer to the same entity while preserving different historically valid information.
Ambiguity is allowed
We do not force uncertain matches simply to create a clean database.
An incorrect merge can contaminate every downstream relationship, calculation, retrieval result, and automated action built on top of it. Where evidence is insufficient, records can remain unresolved or move to additional review.
That makes uncertainty part of the data model rather than something to hide.
Position in the stack
Entity resolution sits upstream of much of the intelligence stack:
- Identity
- Relationships
- Retrieval
- Historical state
- Reasoning
- Action
A model can search documents without this layer. It cannot reliably understand a company if it does not know when different records refer to the same real-world thing.