What is Identity Resolution?

Identity resolution is the process of determining that two or more records describe the same real-world entity — usually a person — and joining them into a single view.

Within one application this is not a problem. Every row carries a foreign key to a user, the user has an ID, and the join is exact. The problem appears the moment records come from independent systems that never coordinated on identifiers. Each one issued its own, in its own namespace, with its own rules about whether it lasts. Nothing in the data says these two rows are the same human. That fact has to be inferred, and every inference has an error rate.

Messaging is the hardest common case: the identifier space is fragmented by design, and the most visible fields are the least reliable ones.

The same person reaches you as an account on one messenger, a phone number on another, an email address in a third, and a handle they can change this afternoon in a fourth. None of those namespaces overlap. No authority maps between them, and there is no field that is reliably present, stable, and unique everywhere at once.

Identity is anchored differently on every platform, and the durable anchor is rarely the one a person sees on screen. The fields a human would reach for first — display name, profile photo, handle — are exactly the fields the platform lets the user rewrite whenever they like. So the visible surface of a contact is the part most likely to move, and the parts that hold still are not shown to anyone.

On top of that, people are legitimately plural. One human has a work line and a personal line, two mailboxes, occasionally two accounts on one platform for two parts of their life. None of that is an error to be cleaned up. It is what a real contact looks like.

Some of the joins that result are simply certain. Most are judgment calls, and a system that cannot tell the two apart is going to be confidently wrong somewhere.

There is a real difference between merging two records into one and linking them while both survive.

A merge collapses two records into a single identity: one record owns both histories. A link asserts a relationship between two records that stay distinct — useful when the evidence is good but not conclusive, or when the two identities are separate roles of one person you want to keep separable.

Whichever you choose, the operation must be reversible. That is a data-model requirement, not a UI nicety. It means keeping the contributing records intact underneath the unified view and being able to unwind exactly one join without disturbing the others. A merge implemented as a destructive rewrite — copy the fields over, delete the loser — cannot be undone once another record joins on top of it. By the time a bad join is noticed, the information needed to reverse it is gone.

Identity resolution is one of the rare problems where the two error types are nowhere near equal in cost.

A missed match leaves a duplicate. The user sees the same person twice, notices, and fixes it. The history is split but nothing is wrong — every message is still attached to a record that legitimately owns it. The failure is visible and cheap.

A false merge blends two real people into one record. Now one person's history appears under another person's name. Nothing in the interface signals an error, because a merged record looks exactly like a correct one. The user reads a summary of a relationship that never happened, and — the part that actually matters — private context from one person becomes visible in the other person's view.

So the tuning is not symmetric. Systems that handle real relationship data should be biased toward leaving duplicates rather than risking a blend, hold a high bar for joining anything on their own, and route everything in the ambiguous middle to a human. Aggressive merging looks better in a demo and is the more dangerous direction in production.

Follow the asymmetry through and it settles the interaction model.

Where the evidence is unambiguous, resolving automatically is correct, and asking the user would be noise — nobody wants to confirm the obvious. Where it is ambiguous, the honest move is to surface the proposed join and let a person confirm it.

That prompt is not a missing feature or an automation someone did not finish. It is the system correctly declining to make an irreversible, invisible decision on evidence that does not support one. The alternative is a product that is quietly wrong about who someone is and never tells you, which is worse than one that occasionally asks.

Pantheon is built this way: it resolves the same person across channels automatically where the evidence is unambiguous, asks where it is not, and keeps joins reversible so a mistake stays a mistake instead of becoming the record.