What is entity resolution?

Entity resolution is the process of deciding which records, held in different systems and written by different people, refer to the same real-world thing. One person, one company, one invoice — however many places describe them and however differently they spell it.

It is also called record linkage, deduplication or identity resolution, with shades of difference: record linkage usually means joining across two datasets, deduplication means collapsing within one.

The problem looks trivial until you look at real data:

mailbox   sam@bigco.com              "Sam"
ticket    Samuel Lee                  samuel.lee@bigco.co.uk
CRM       contact 0012f               S. Lee · BigCo Ltd
invoice   BIGCO LIMITED               accounts@bigco.com
ledger    Bigco (UK) Ltd              VAT GB123456789

One person and one company, or five of each, depending on whether anything resolved them. Nothing in those rows is a shared key.

How it is done

Blocking. Comparing every record against every other is quadratic and infeasible past a few thousand rows, so candidates are first grouped by something cheap — email domain, postcode, the first three letters of a surname — and compared only within a group. Blocking is where most of the engineering effort goes, and a bad blocking key silently guarantees missed matches.

Comparison. Within a block, pairs are scored on each field: exact match on an email, edit distance on a name, phonetic similarity, normalised company suffixes (Ltd, Limited, LTD.).

Classification. Scores combine into a decision — match, no match, or send it to a human. The threshold is a policy choice, not a technical one, and it trades the two error types against each other.

Clustering. Pairwise decisions must be made transitively consistent. If A matches B and B matches C, something has to decide whether A matches C, and naive transitive closure is how two genuinely different customers end up merged through a shared shipping address.

Survivorship. Once records are grouped, which value wins? The most recent, the most complete, the one from the system of record? This is the step that gets forgotten, and it determines what your answers actually say.

Why the two error types are not symmetric

A missed match (one entity seen as two) under-reports. A customer looks smaller than they are; a support history looks shorter; a question about "all our business with BigCo" returns half of it. It is a quiet, wrong-but-plausible answer.

A false match (two entities merged into one) is worse, and much worse with AI in the loop. Two customers' data is now one customer's data. Every figure downstream is wrong in a way that passes every sanity check, because the merged record is internally consistent. And if a model is answering from it, you may have just shown one customer's information to another — a permissions failure produced by a data-quality decision.

This asymmetry is why conservative thresholds and a human review queue are usually right, and why "the AI will work it out" is not a strategy.

The connection to AI

Here is the part that matters for anything retrieval-based: similarity is not identity.

Vector search ranks text by resemblance. Two records about the same customer may share no words at all — an invoice and a support thread look nothing alike. Two records about different customers may share a great many, because they are both complaints about delivery. Embeddings cannot distinguish these cases, because they were never measuring the right thing.

So a retrieval system without entity resolution hands a model three records and leaves the joining to a probabilistic guess about a sentence. That is precisely where confident wrong answers about company data come from, and it is the structural argument for resolving identity in a graph before deciding what to fetch rather than hoping the model infers it afterwards. We have written about why this is the missing primitive.

In Memtro, resolution happens in the memory graph: entities carry aliases, the same person or company resolves across every connected system, and each fact keeps the source it came from, so a merge can be inspected afterwards.

It cannot be undone, though, and that is the honest version. Two entities folded into one are one entity in every reading of the graph, including past ones — bitemporal storage preserves the history of what each fact said, not a route back from a wrong merge. Which is why the bar to merge is deliberately high: names whose identifiers differ are never treated as the same thing, a shared identifier is the only evidence acted on by itself, and every other candidate goes to a model with both records' identifiers and relationships in front of it, told to decline when it is unsure. A false match you cannot reverse is worth several missed ones.