Is This the Same Citizen, Twice?

Opening Scene

A clerk at the central registry lays two file cards side by side. One reads “Jon A. Reyes, 14 Birchwood Ave.” The other reads “Jonathan Reyes, 14 Birchwood Avenue, Apt 2.” Different first name spelling. Slightly different address. No shared file number, because the cards came from two different district offices years apart. The clerk doesn’t guess. She checks the birth date on both, checks the phone number on file, and pulls a third card — a change-of-address slip filed eighteen months ago — that bridges the two. Only then does she stamp both cards as referring to the same citizen and begin the process of merging them into one file.

That careful, evidence-based judgment call — is this the same person, or two different people who merely resemble each other on paper — is exactly what entity resolution automates at scale.

In Plain English

Entity resolution, often called matching, is the process of determining whether two or more records from different sources refer to the same real-world entity. It’s harder than it sounds because entities almost never present themselves with a single, perfectly consistent identifier across every system — names get misspelled, addresses change, phone numbers get reassigned. Matching works by comparing multiple fields at once — name, address, date of birth, email, phone — and weighing how much agreement (or disagreement) across those fields adds up to genuine confidence that two records are the same entity, rather than two different entities that simply happen to look alike.

The Old Way

Matching has always relied on the same handful of underlying signals, however they get combined:

• Exact identifiers — a shared government ID, tax number, or account number is the strongest possible signal, when it exists and is entered correctly, because it was specifically designed to be unique to one entity.
• Quasi-identifiers combined together — no single field like “last name” or “city” reliably identifies one entity alone, but several quasi-identifiers agreeing simultaneously — name, birth date, and postal code together, for instance — sharply narrow the odds that two records describe different people.
• Blocking, to make comparison tractable at all — comparing every record against every other record directly doesn’t scale past a small dataset, so matching systems first group records into smaller “blocks” — by shared postal code or phonetic name encoding, for instance — and only compare records within the same block, trading a small risk of missing a genuine match for a dramatic reduction in comparison work.

None of this is new — clerks have used a version of quasi-identifier reasoning for as long as registries have existed. What’s changed is the sophistication and scale at which it can now be applied.

What’s Changing (and Why AI Is the Reason)

1. AI-assisted fuzzy matching goes well beyond simple string-distance comparisons, recognizing that “Jon” and “Jonathan” or “Bob” and “Robert” are the same underlying name even when no traditional rule-based system was told to expect that specific variant. Models trained on large volumes of real name and address variation generalize to unfamiliar cases in a way that hand-written matching rules never could.
2. AI-assisted matching produces a calibrated confidence score rather than a binary yes/no, distinguishing a near-certain match from a plausible-but-uncertain one. This is a genuine shift from older deterministic matching, which could only say “matched” or “not matched” — the confidence score is what makes intelligent, risk-appropriate human review queues possible, a topic Article 10 covers directly.
3. AI-assisted matching can incorporate behavioral and contextual signals beyond the record’s own fields — shared devices, shared payment methods, or shared login patterns, for instance — surfacing matches that field-comparison alone would miss entirely. This extends matching’s reach into cases where the textual data genuinely doesn’t overlap enough to resolve the match any other way.

The Metaphor, Fully Extended

Registry Element	Master Data Management Concept
Two file cards with different name spellings and addresses	Two source records that may or may not describe the same real-world entity
A shared government ID number stamped on both cards	An exact identifier, the strongest possible matching signal when present
Checking birth date, phone number, and address together	Comparing multiple quasi-identifiers in combination to build matching confidence
Sorting file cards by district before comparing them at all	Blocking — grouping records to make matching computationally tractable at scale
A newly trained clerk who recognizes “Jon” and “Jonathan” as the same name instinctively	AI-assisted fuzzy matching, generalizing to name and address variation without explicit rules

Quick Recap

• Entity resolution determines whether two or more records from different sources describe the same real-world entity, using exact identifiers and quasi-identifiers in combination.
• Blocking makes large-scale matching computationally tractable by comparing records only within smaller, likely-relevant groups.
• AI-assisted fuzzy matching generalizes to name and address variation, produces calibrated confidence scores instead of binary answers, and can incorporate behavioral signals beyond the record’s own fields.
• Matching quality is always bounded by the quality of the underlying source data, no matter how sophisticated the matching approach itself becomes.

Where This Fits in the Series

Article 2 explained why the same entity ends up scattered across systems; this article covered how to recognize when two scattered records are actually the same entity. Article 4 turns to what happens once a match is confirmed — deciding which conflicting field value actually survives into the golden record.