Two records. One person?

Three index cards lie on a desk, each with a number typed in its top corner. The first says Alex Rivera, 14 Linden Street, born March 14, 1988. The second says A. Rivera, 902 Harbor Road, with the same birth date and the same email address as the first. The third says Alex Rivera, 902 Harbor Road, with the same phone number as the second card and a birth date in 1961. The people, the addresses and every number on the cards are invented. Each card has a valid key, and no two keys are alike. The file is in perfect order, and nobody at the desk can yet say how many people the three cards describe.

Two kinds of identity are tangled together here, and they need to be pulled apart. The first is record identity: the key that lets a database tell one row from another. The second is real-world entity identity: the fact of which person, household or company a row is about. A unique key settles the first completely and the second not at all. Deciding that two records describe one person, or two, is a judgment made from evidence, and like any judgment it can be wrong in two directions, each with its own cost.

This is not an argument against keys, which are indispensable, or against matching software, which is often good. Nor is it a claim that identity is unknowable. It is a claim about where a decision lives. Companies now ask AI tools which customers are drifting away, what customers want and which ones are worth the most. Every one of those answers rests on an earlier decision about which records belong to which customer, and that decision is usually made somewhere else, by a rule nobody looking at the answer has read.

Three jobs that look like one

When a team says it has cleaned the customer data, it may mean any of three different jobs. The first is assigning keys: giving each row a number that no other row has. That is what lets a database find a row, update it and join it to rows in other tables. It is a property of the storage, settled the moment the row is written. The key 22917 will always point to the second card, whoever the second card turns out to describe.

The second job is standardizing: making the same thing, written different ways, look the same. "Harbor Rd" and "Harbor Road" become one spelling, phone numbers lose their parentheses, and email addresses go to lower case. This helps, because it lets a comparison see agreement that formatting would hide. But it settles nothing about people. After standardizing, the second and third cards have an identical address and an identical phone number, and in the invented world of this essay they are still a parent and a grown child who share a name.

The third job is resolution: deciding that two records refer to the same entity in the world. It is the only one of the three that is about the world rather than about the data, and it is the one most often done without anyone noticing, as a side effect of the other two. A cleanup script that merges every pair of rows with the same standardized name and phone number has made an identity decision. It has just not written the decision down.

An earlier essay here, on storing each fact once, was about duplication inside a single design. This is a different problem. The records arrive from different systems, each of them tidy on its own terms, and nothing inside any one of them says that a row elsewhere describes the same person.

The same what?

Before two records can be the same customer, someone has to say what a customer is. William Kent's Data and Reality, first written in 1978 and reissued in a third edition with commentary by Steve Hoberman, is a book-length case that this question is harder than it looks.¹ It opens with a chapter on entities whose first section is called "One Thing," separates the records in an information system from the things they represent, and gives a whole chapter to naming, including what happens when names change and what it means for two things to be the same.¹ Among the questions the book raises, its publisher lists the difference between "oneness, sameness, and categories."¹

Kent offers no matching algorithm, and the book does not hand down one correct definition of a customer. What it offers is the habit of asking which thing a record stands for, and the recognition that the answer depends on purpose. A bank may count a couple with a joint account as one account and two people. A utility counts a household, because it sends one bill to one address. A supplier counts a legal entity, and a parent company with four subsidiaries can be one customer for its credit limit and five for shipping. A retailer selling to a chain may care about each site. None of these counts is wrong, and two departments can report different customer totals from the same records without either database being broken. They are counting different entities.

So the first question is not whether two records are the same, but the same what. The three cards might describe two people and one household. Asked where to send a catalogue, the answer is two addresses, one of them out of date. Asked whose birthday offer to send, the answer is two people. Asked how many accounts to bill, the answer could be three, if each card opened one.

Evidence, weighed

Once the entity is defined, deciding whether two records describe it is a matter of weighing evidence, and there is a well-developed theory of how to do that. In 1969 Ivan Fellegi and Alan Sunter, of Canada's Dominion Bureau of Statistics, published a mathematical model for recognizing the records in two files that represent identical persons, objects or events.² Its central idea is that each comparison between two records carries a weight built from two probabilities: how often the comparison comes out that way when the records truly match, and how often it comes out that way by coincidence when they do not. The weight is the logarithm of the ratio between the two.²

That ratio explains intuitions most people already have. A shared surname is weak evidence when the surname is common and stronger when it is rare, because coincidental agreement on a rare name is unlikely. A shared birth date is strong evidence, because two unrelated people seldom share one. A shared phone number is weaker than it looks, because households share phones, so it often agrees for people who are merely related. Disagreement is not always strong evidence against a match, either. People move, so a different address says little. People change surnames when they marry, so a different surname says less than a different birth date.

Missing information is the case that matters most and the easiest to get wrong. The third card has no email address. A rule that treats the blank as a mismatch counts it against the match. A rule that compares two blanks as equal strings counts it in favor. Both are errors. A blank is no evidence at all, and the weighing should carry on without it.

Add up the weights and each candidate pair gets a score. Here Fellegi and Sunter made their second contribution. They did not ask the score for a yes or a no. They allowed three decisions: a link, a non-link, and a possible link, which sends the pair to a person.² They treated that middle decision as the expensive one, since it means manual work, and showed that for any error levels one is willing to accept there is an optimal rule that keeps it as rare as possible.²

The theory has been extended since. A 2024 Census Bureau review by Yves Thibaudeau calls the original theory the starting point of later developments, and surveys newer methods that treat linkage as dividing records into clusters, often within a Bayesian framework.³ One reason for the newer work, the review notes, is that the pairwise model does not extend straightforwardly to groups of three or more records.³ Three cards that may describe two people are exactly such a group.

Two ways to be wrong

Fellegi and Sunter named the two errors precisely: linking a pair that does not match, and failing to link a pair that does.² In customer terms, call them a false merge and a missed match.

A false merge combines two people's histories into one. Merge every Alex Rivera on the cards and the result is one customer born in both 1961 and 1988, whose purchases belong to two generations. The damage depends on what the record is used for. A letter goes to the wrong person. A model learns that a single customer buys reading glasses and running shoes. Where the history drives a consequential action, such as a credit decision, a fraud flag or a medical chart, a false merge can attach one person's past to another person's name, and that is hard to see and hard to undo.

A missed match leaves one person's history divided. Trust the keys, and Alex Rivera becomes two customers: an old one who went quiet in 2019, and a new one who appeared in 2024. A churn model counts a loss and a gain. The real customer gets a second welcome offer and none of the loyalty they earned.

Neither error is the safe one. Raise the score needed for a match, and false merges fall while missed matches rise. Lower it, and the reverse happens. Where the threshold belongs depends on what happens next. A company deduplicating a mailing list may accept some false merges to avoid sending two catalogues to one house. A hospital joining patient records should accept many missed matches, and pay for review, before it accepts one false merge. The algorithm and the scores can be identical in both places and the right threshold different.

The ledger below makes the trade concrete with twenty-four invented candidate pairs. Six are written out with their evidence; all twenty-four are marked on the score ruler, with an invented truth so that the errors can be counted. Move the threshold, and try sending the near misses to review.

At the starting threshold of 8, without review, the invented matcher makes three false merges and misses four true matches. Raise the threshold to 17 and every false merge disappears, but eight of the eleven true matches are missed. Turn on review at 8 and four pairs go to a person, leaving three false merges and two missed matches. That middle band is what Fellegi and Sunter's third decision buys: fewer errors on both sides, paid for in someone's time.

The hardest pair is the twins, Jordan and Jamie Hale, recorded once as J. Hale. They share a surname, a birth date, an address and a phone, and they disagree only on email. In this invented set no threshold removes that false merge without also missing the true matches scored just below it. No weighting fixes a case like that. More evidence does, or a person who knows that twins exist.

Keep the uncertainty on the books

If identity is a judgment, the system should record it as one. In practice that comes down to four habits.

Three states, not two. A pair of records is matched, unmatched, or waiting for review, and the third state is visible to everyone who uses the data, not buried inside the matching tool.

Keep the source keys. Linking records under one person identifier should never delete the rows' own keys. The gold numbers stay on the cards; the blue loop is drawn around them.

Record the evidence and the rule. For every link, store which fields agreed, which disagreed, the score, and the version of the rule or model that made the call, so that a later question about why two records merged has an answer.

Make merges reversible. A merge and a split are events in a history, not edits that overwrite it. When a false merge comes to light, the split should restore both histories as they were. An earlier essay here, on answers that change with time, argued for keeping that kind of history in general; identity is a case where losing it is especially costly.

None of this requires a person to review every match. Review is expensive, which is the whole reason Fellegi and Sunter minimized it. It requires only that the system know which of its identity claims are established and which are merely plausible.

This is also where AI fits, and where it does not. A language model is good at the second job: it can read "Apt 2, 14 Linden" and "14 Linden St #2" as one address, and it can propose candidate pairs from messy text faster than a hand-written rule. It can be a useful source of evidence. What it should not do is erase the line between a plausible match and an established identity, by merging records silently or by answering questions about "customers" without saying which grouping it was given. A faster matcher makes the same decision faster. It does not make the decision unnecessary.

Objections, considered

A good identifier solves this. Deterministic identifiers, such as a verified account login, a tax number or a patient number issued at registration, can be highly effective when they are well governed, and where they exist they should be used. But they move the question to the moment the identifier was issued, and records from before then, from partners, or from guests who never signed in have none. A good identifier is evidence of great weight, not a reason to stop recording how each link was made.

Probabilistic matching is good enough. For many purposes it is. Marketing analysis can live with a small rate of error in either direction. Other uses, such as payments, health care and legal notices, need stronger verification. The argument is not that probability is inadequate. It is that the tolerable error depends on the action, so a single setting for the whole company is the wrong design.

We need a golden record. A single best view of each customer makes systems easier to use, and companies that build one are often right to. The objection is to building it by overwriting. A golden record that throws away the source rows and the evidence can be neither audited nor unmerged. Build it as a view over preserved sources, and it keeps its usefulness without its risk.

Review everything uncertain. Review costs time and money, and a system that refuses every uncertain match causes harm of its own: the loyalty points that never combine, the allergy recorded in a chart that was never linked. Review belongs where the score is genuinely uncertain and the stakes are high, not everywhere.

Identity changes. It does. Companies merge and split, couples separate, children leave home and households form. That is an argument for dating the relationships between records and entities, not for pretending the world stands still. A link that was right in 2019 may be wrong in 2026, and both facts belong in the history.

A unique key identifies the record; the evidence identifies the person.

Before you ask the data about customers

• What entity is being counted? An individual, a household, a legal entity, a site or an account, written down for each report that counts customers.
• Which error costs more here? A false merge or a missed match, for the specific action the data will drive, and who made that call.
• Where do uncertain pairs go? The review state, who works it, and how many pairs are waiting in it today.
• How is a wrong merge undone? The source keys, evidence and rule version that let a split restore both histories.

Back to the three cards. Their keys, 10482, 22917 and 31056, were never in doubt. Draw a loop around the first two, because the birth date and the email agree and the change of address has an ordinary explanation. Leave the third outside it, because its birth date disagrees and a shared phone is what families have. Then leave a small pencil question mark beside the loop, because that is what the evidence supports: a strong case, not a certainty, and a record of why.