Fellegi Sunter model, applied to a five year registration archive

Somebody in the room asks what score you merge at, and the honest answer is that the question has the order wrong. Under the Fellegi Sunter model you state the error rates you can live with first, and the cut offs come out of that decision rather than out of anybody's judgement about whether 82 sounds high.

Ivan Fellegi and Alan Sunter published the model in the Journal of the American Statistical Association in 1969. It is the piece of statistical machinery underneath nearly every commercial matching product sold today, and it says two things worth keeping straight. You classify pairs of records, ordered by a likelihood ratio. You cut that ordering in two places, and the second cut is the one everybody forgets.

The pair, field by field

Two rows from a five year registration archive, one from the 2022 edition and one from 2026. Compare four fields after normalisation and record what happened.

• Surname. Both read Kowalczyk. Agreement.
• Forename. Anna against A. Disagreement, since a single initial does not clear the comparator's threshold.
• Employer. Northgate Foods Ltd against Northgate Foods Group. Token overlap of 0.67 after stripping legal suffixes, which lands in the agreement band.
• Mobile. Present on the 2022 row, absent on the 2026 row, so it counts as disagreement under the simple two level scheme.

That pattern of agree, disagree, agree, disagree is the comparison vector, and it is what the model classifies. Each field contributes a weight: the base two logarithm of the chance of that outcome among true matches divided by the chance of it among non matches.

With surname agreement at 8.07 bits, forename disagreement at minus 2.82, employer agreement at 5.32 and mobile disagreement at minus 1.15, the pair totals 8.07 minus 2.82 plus 5.32 minus 1.15, which is 9.42 bits. Where those four numbers come from is the subject of match weight calculation, and the arithmetic there is worth doing once by hand before you trust any of it.

What does the 1969 decision rule actually say?

Fellegi and Sunter defined three possible actions on a pair: link it, do not link it, or designate it a possible link and leave it for clerical review. The rule is a pair of thresholds on the likelihood ratio. Above the upper one, link. Below the lower one, do not. Between them, review.

The part that gets forgotten is where the thresholds come from. The model starts from two error probabilities that you fix in advance. The first is the chance of linking a pair that is truly not a match. The second is the chance of failing to link a pair that truly is. Fellegi and Sunter then proved a result about the ordering: for any pair of stated error rates, ranking candidate pairs by the likelihood ratio and cutting at the two corresponding points minimises the number of pairs left in the middle region. No other decision rule achieving those same error rates sends less work to a human.

Winkler, writing for the US Census Bureau in 2006, describes the same rule and calls the middle band the no decision region, and adds that in some situations resources are available to review pairs clerically. That framing is the practical one. The middle region is a budget line, and the two cut offs decide how big it is.

Where do the two cut offs come from?

Here is the sequence that actually works, on a five year archive with 11.4 million candidate pairs surviving blocking.

Label a sample. Take 400 candidate pairs, stratified across the score range so the sample is not all obvious non matches, and have somebody who knows the sector judge each one. Record the score and the verdict.

Then state your two rates. For an event business I would start at a 0.1 per cent chance of a false link among the pairs the model links automatically, and a 5 per cent chance of missing a true pair. Those are not symmetric, deliberately. A false merge removes a buyer from your audience, stops her invitations and leaves no error behind. A missed pair leaves a duplicate that somebody will notice and complain about, which is a self correcting failure.

Read the cut offs off the labelled sample. Sort the sample by score. Walk down from the top until the false link rate among the pairs above your position reaches 0.1 per cent, and that score is the upper cut off, say 12.0 bits. Walk up from the bottom until the true matches below your position reach 5 per cent of all true matches in the sample, and that score is the lower cut off, say 6.0 bits.

Our pair scored 9.42 bits. It lands in the middle region, and that is the correct outcome. One agreeing surname and one partial employer match against a missing mobile and a bare initial is genuinely ambiguous, and a model that returned a confident answer there would be lying to you.

Apply the same two cut offs to the whole run and the shape of the work appears. Of the 11.4 million candidate pairs, 21,600 score above 12.0 bits and merge without anybody looking. Another 4,200 fall between 6.0 and 12.0 and go to the queue. The remaining 11.37 million sit below 6.0 and are dropped, which is 99.8 per cent of everything the model scored.

Now check the middle number against a calendar. A steward who knows the sector settles roughly 240 of these a day once the interface is decent, so 4,200 pairs is about 17 working days. If your merged audience file has to be ready for the campaign launch four weeks after the show closes, that fits. If the band comes out at 30,000 pairs, it does not fit, and the choice is to raise the lower cut off, accept the missed pairs, and write down what you gave up.

Why the middle region is the point rather than a failure

Most implementations treat the review band as an embarrassment to be minimised, which gets the incentive backwards. The band is where the model puts its uncertainty so that the two automatic decisions can be trusted.

Three regions map onto three different pieces of operational work, and they should be built as three different queues. The link region feeds the merge job and needs no interface. The non link region needs nothing at all except the ability to re examine it when the rules change. The middle region needs a screen showing both records side by side, the fields that agreed, the fields that disagreed, and a button that records the verdict along with the reviewer and the timestamp.

Those recorded verdicts are the asset. Every judged pair becomes a labelled example, and after two editions you have a few thousand of them, which is enough to re estimate the model's probabilities and to check whether last year's cut offs still deliver last year's error rates. A review queue that does not persist its verdicts is throwing away the only training data your organisation will ever generate for free.

What five years of archive does to all three regions

Scale changes the regions in a way that catches people out on the second run.

The number of true pairs grows roughly with the size of the file. The number of candidate pairs grows with the square of it, before blocking, and considerably faster than the true pairs afterwards. So as the archive extends from three editions to five, the proportion of candidate pairs that are true matches falls, the prior odds get worse, and every score shifts down relative to the thresholds even though no field changed. A pair scoring 9.42 bits in a three year run may sit below the lower cut off in a five year run.

Two consequences follow. Recompute the prior for every run rather than inheriting last year's cut offs, and version the thresholds alongside the rule set so a change in merge behaviour can be traced to the run that caused it. When someone asks why the portfolio gained 3,000 unique people this quarter, you want to be able to say whether the audience grew or the threshold moved, and the only way to answer is to have written it down.

Where this stops

The model assumes the field outcomes are independent given match status, which registration data violates constantly, and the violation inflates scores in a specific direction. Employer name and work email domain move together, so counting both as separate evidence double counts one fact. That correction has its own post at the conditional independence assumption.

The second limit is that the error rates you state are only as good as the sample you read them off. Four hundred labelled pairs give you a defensible upper cut off and a shaky lower one, because the lower region contains far more pairs and your sample thins out there. Treat the lower cut off as provisional and revisit it once the review queue has produced a few thousand verdicts.

The third is that none of this decides what the merged record should say. Which value wins when two matched rows disagree is a survivorship question and it sits downstream of the whole model, inside the unified data layer.

The first step is cheap. Take last quarter's merge log, sample 50 merged pairs, and have somebody judge them cold. If more than one is wrong, your upper cut off is too low and you can say so with a number attached, which is a better meeting than the one about whether 82 sounds high. Then read probabilistic record linkage for how the scores were produced in the first place.