Identity Is Not a Match Score

A person rarely appears in a data system as a person.

They appear as an email address, a phone number, a device, a cookie, an account, or a sequence of records created at different moments by different systems. Each identifier is real in the narrow sense that it was observed. None of them, by itself, is the identity we are trying to understand.

The usual response is to compare identifiers two at a time. If two records share enough attributes, produce a high score. If the score crosses a threshold, call them a match.

This is useful. It is also where the harder problem begins.

I have been working on an open-source project called CellID to explore that problem. It started as a synthetic-data testbed for probabilistic record linkage, but the work kept exposing the same boundary:

A match is a statement about a pair. An identity is a coherent claim about a whole set of identifiers, made over time.

Those are not the same object.

A Pair Is Not a Person

Suppose a system concludes that identifier A matches B, and B matches C. It has created a transitive claim: A, B, and C belong to one entity.

Now suppose another source says A cannot match C.

Each pairwise judgment may look defensible in isolation. Together, they describe an impossible identity. No probability attached to one edge can resolve the contradiction on its own, because the error exists in the structure produced by all the edges.

This is why identity resolution cannot stop at pair scoring. It needs a graph operation that considers transitivity, hard constraints, conflicting evidence, singleton identifiers, and the consequences of every merge.

A false negative leaves two parts of one person separate. A false positive can be more destructive: it may join two people, then pull every identifier connected to either of them into one contaminated component. Local confidence becomes a global mistake.

The distinction matters because pair metrics can look strong while the resulting identities remain poor. A model may rank likely matches well and still choose an operating point that produces large false merges. Average precision measures the ordering of edges. It does not tell us whether the final partition of people is coherent.

CellID therefore evaluates both levels. It measures pair probabilities, but it also measures complete identity partitions: cluster precision and recall, exact recovery, over-merging, over-splitting, and the size of the largest contaminated component.

The entity is the result that matters.

Silence Is Also Evidence

The second problem is less visible.

Most matching systems record the signals they receive and ignore the signals they do not. But absence has more than one meaning.

A source may have examined a pair and found nothing. It may not have been applicable to that kind of pair. Or it may never have had the opportunity to look.

Collapsing those states into an empty cell destroys information.

CellID preserves three distinct conditions for every candidate pair and source: observed, no_signal, and not_applicable. A source that usually detects genuine matches but stays silent on one eligible pair is telling us something. A source designed only for phone numbers tells us nothing about a pair of device identifiers.

That distinction became the basis for IdentityREIM, the identity-specific evidence model developed as an extension of REIM. It learns how each source behaves on matches and non-matches, including when applicable silence is informative. It produces calibrated pair evidence and source-level provenance.

It still does not assign identities.

That boundary is deliberate. Evidence calibration answers, “How should these observations change our belief about this pair?” Graph resolution answers, “Which complete partition remains coherent when all accepted relationships interact?” One layer should not quietly pretend to be the other.

Identity Must Survive Correction

Even a coherent partition is only a snapshot.

Identifiers arrive, disappear, and change. Two clusters may merge when new evidence appears. A merged cluster may split when an earlier conclusion is contradicted. If downstream systems use the temporary label of a clustering run as the identity itself, every recomputation can rewrite history.

CellID separates the resolved partition from the persistent identifier assigned to it.

Its registry receives a complete partition and issues opaque CellIDs with an append-only lifecycle. It records creation, maintenance, merges, splits, aliases, and retirement. An unchanged entity keeps its CellID. A merge selects a survivor and preserves the other identifiers as historical aliases. A split keeps continuity only when policy provides a stable anchor; an ambiguous split creates new identities rather than inventing certainty.

The principle is simple:

Correction should change the current state without erasing how the system arrived there.

This makes identity a temporal claim, not a timeless label. A CellID identifies a versioned resolution state. It can be replayed, audited, superseded, and interpreted in the context of the evidence available at that moment.

That is a less convenient definition than “one person, one permanent ID.” It is also more honest.

A Database Does Not Decide What an Identity Means

Identity graphs are often discussed as if choosing a graph database solves identity resolution. A graph database can store identifiers, memberships, aliases, events, and lineage efficiently. It cannot decide the semantics of a merge.

In CellID, persistence comes after identity inference, graph resolution, and lifecycle policy. The same logical history can be stored in memory or in LadybugDB. Both backends must return the same snapshots, transitions, and events for the same commits.

The database preserves the decision. It does not make the decision true.

This separation produces a deliberately explicit architecture:

evidence generation
    -> pair calibration
    -> constrained graph resolution
    -> temporal CellID registry
    -> identity graph persistence

Each layer has one job. Ground truth exists only in the evaluation boundary. Pair calibration does not allocate identities. The resolver does not issue persistent CellIDs. The registry does not score evidence. The storage backend does not define lifecycle policy.

The result is more modular, but modularity is not the main point. The point is that every claim has an address.

What the Benchmarks Can and Cannot Say

CellID generates synthetic populations in which the true relationship between identifiers is known by construction. That makes it possible to measure false merges, false splits, transitive errors, and temporal behavior instead of inspecting a few plausible-looking clusters.

On the frozen internal benchmark, IdentityREIM improved the complete-partition result substantially over the unchanged mean-score baseline. The work also transferred to FEBRL3, an external synthetic record-linkage dataset, without changing the model or graph contracts.

The external result was more instructive than a simple victory. IdentityREIM produced a large improvement in probability calibration but almost no change in partition quality over a simple field mean. The mean was slightly better on some measures and avoided all false merges at its selected operating point.

That is not an inconvenient result to hide. It is the reason to build the testbed.

A model can contribute better-calibrated uncertainty without dominating every ranking or clustering regime. A method that succeeds on generated data has not proved itself on independently collected production data. A clean benchmark should make those limits visible, not convert them into marketing.

CellID is therefore not a claim to universal identity, a replacement for every commercial identity graph, or proof that one inference model wins everywhere. It is an executable environment for asking better questions about evidence, graph coherence, continuity, and error.

Identity Infrastructure Before Identity Claims

There is a larger product direction behind this work: privacy-first identity infrastructure for controlled data collaboration.

But an identity engine is not yet a clean room.

Tokenization, tenant isolation, query approval, minimum cohort rules, deletion workflows, and aggregate release controls belong to a separate security and policy boundary. Adding them casually to the resolver would make both systems harder to reason about. The current CellID release candidate keeps that boundary explicit.

Before a system can govern how identities are used, it needs a defensible account of how those identities were inferred. Before it can promise stable identifiers, it needs a policy for what stability means when evidence changes. Before it can store an identity graph, it needs to define which decisions the graph is allowed to preserve.

This is the premise behind CellID:

Identity is not found in one record, one score, or one database. It is maintained as a coherent, revisable history of evidence and decisions.

The CellID source code and documentation are available on GitHub. The repository includes the identity-resolution contract, the CellID registry specification, the v1 API contract, the IdentityREIM benchmark, and the FEBRL3 external validation report.