Citizen Codex · 2026

Citizen Codex Research · 2026

A Matter of Matching

What entity resolution is, why it matters, and what every team needs to ask.

Record A: Source: SSA Master File
Name: Ned Johnson DOB: 04/14/42 SSN: ***-**-7823 Status: Active
Record B: Source: Death Report
Name: Edward N. Johnson DOB: April 14, 1942 SSN: ***-**-7823 Status: Deceased, 11/2024

Are these the same person?

Your answer matters.

Part 1

You Already Know This Problem.

You Might Not Have a Name for It.

Entity resolution sounds like a technical term. It is, but it has real world implications. It is a problem you've experienced dozens of times, but often you just didn't know what to call it.

Entity resolution is what happens when a computer has to decide whether two pieces of data refer to the same real-world thing without a shared identifier to rely on: a name, a company name, a product description, a city and state. It's a judgment call and the consequences of getting it wrong depend entirely on what's at stake.

Move the dial to explore the range.

LOW MED HIGH

The stakes vary enormously, but the underlying problem is always the same: separate systems, inconsistent records, and a judgment call about whether two things are one thing.

That is entity resolution.

Part 2

Why It's Hard

Entity resolution isn't a solved problem. If it were, the hospital merger would be straightforward and the package would always arrive. There are three reasons it remains hard, and understanding them is the foundation for everything that follows.

See how the same problem takes three different forms.

Variation The same entity, recorded differently.

Part 3

Now Raise the Stakes

Everything so far has been abstract. Let's make it concrete. Because when entity resolution fails in civic and government systems, it doesn't just hold up a package or create a duplicate charge.

Match Everything Match Nothing
There is no default.

Part 4

What to Take With You

Entity resolution is infrastructure. It runs underneath products you use every day and systems that govern access to benefits, credit, housing, and opportunity. Most of the time you don't see it. You see the outcome.

What changes when you know it's there is that you start asking different questions: before you build, before you ship, before you connect two datasets and call it done.

Here are five questions every team working with matched data should be able to answer. Each card has the question. Flip it to see what good practice looks like.

Each card has a question. Flip it to see what good practice looks like.

Question 01
Have we defined what counts as a match, and written it down?
Flip to see →
Good Practice
A documented matching criteria spec: a plain-language description of what signals the system uses, how they are weighted, and what threshold triggers a confirmed match versus a possible one. This document should be readable by a PM, a designer, and a user, not just an engineer. If you cannot write it in plain language, that is usually a signal the logic is not well understood even internally.
← Flip back
Question 02
Have we decided who bears the cost if we're wrong, and is that acceptable?
Flip to see →
Good Practice
Make this decision explicitly before building, not after a failure. In design terms this means mapping the error states: what does a false positive look like for a real user, what does a false negative look like, and who in that scenario has the least power to correct it. The person with the least power to correct an error should receive the most protection in the design.
← Flip back
Question 03
Is there a path for someone to dispute or correct a match?
Flip to see →
Good Practice
Build the correction path before launch, not as a post-launch fix. Technically this means a feedback mechanism that writes back to the system, not just a support ticket that disappears. In product terms it means the correction path is as visible and accessible as the match result itself. If a user has to hunt for it, it will not be used.
← Flip back
Question 04
Do we know how confident our matching is, and is that confidence visible to the people relying on it?
Flip to see →
Good Practice
Translate confidence into a state the user can act on. A raw percentage is often not useful. A distinct visual state, a label, a flag, or a separate category for uncertain matches gives the user something to do with the uncertainty rather than ignoring it. The design question is: what does the user need to know to decide whether to trust this result?
← Flip back
Question 05
What would a false positive look like here, and would we know if it happened?
Flip to see →
Good Practice
Instrument for failure, not just for success. This means defining in advance what a false positive looks like in your specific context, then building a way to detect it: a metric, a feedback loop, a user report mechanism, or a regular audit. If the only way you find out about false positives is when a user escalates loudly, your detection is not working.
← Flip back

These questions don't belong to any one role. They aren't PM questions or engineering questions or design questions. They're the questions any thoughtful team asks when they are working on something that connects records about real people.

Entity resolution is everywhere. It is inside the systems we build, the data we use, and the products we ship. Most of the time it works. When it doesn't, when a living person is marked as dead, when a family is denied benefits because a name was recorded two ways, the consequences are real and the correction is slow.

Knowing it's there is the first step. Asking these questions is what comes next.

  1. Westneat, Danny. "A Seattle Man Woke Up to Find He Was Dead, According to Social Security." The Seattle Times, March 15, 2025.
  2. "Man Loses Social Security, Medicare After Being Declared Dead." Newsweek, March 18, 2025. newsweek.com/man-loses-social-security-medicare-after-being-declared-dead-seattle-2046573
  3. "Seattle Man Loses Social Security After Being Mistakenly Declared Dead." Newsweek, March 18, 2025. newsweek.com/seattle-man-loses-social-security-mistakenly-declared-dead-2045837
  4. "Man Falsely Declared Dead by Social Security Still Dealing with Fallout." ABC News, March 26, 2025. abcnews.go.com/US/man-falsely-declared-dead-social-security-dealing-fallout/story?id=120135649
  5. "Seattle Man Wrongly Declared Dead Loses Social Security Benefits." FOX 9 / LiveNOW from FOX, March 21, 2025. livenowfox.com/news/seattle-man-social-security-error
  6. Ellis, Blake. "Social Security Wrongly Declares 14,000 People Dead Each Year." CNN Money, August 17, 2011. money.cnn.com/2011/08/17/pf/social_security_deaths_mistakes/index.htm
  7. "What Social Security Says to Do If You're Incorrectly Listed as Dead." CBS News, March 18, 2025. cbsnews.com/news/social-security-benefits-ssa-death/
  8. "What Should I Do If I Am Incorrectly Listed as Deceased in Social Security's Records?" SSA.gov FAQ. ssa.gov/faqs/en/questions/KA-02917.html
  9. "Viktor Labin: GRU Officer in Brussels Funnels Military Exports to Russia." Euromaidan Press, January 27, 2024. euromaidanpress.com/2024/01/27/insider-gru-officer-in-brussels-funnels-military-exports-to-russia/
  10. "Russia Sanctions Evasion Case Study: Viktor Labin." Institute for Financial Integrity, 2024. finintegrity.org/russia-sanctions-evasion-case-study-viktor-labin/
  11. "Suspected Russian Spy Arrested in Brussels." VRT News, February 2026. vrt.be/vrtnws/en/2026/02/24/suspected-russian-spy-arrested-in-brussels/