Somewhere in your MDM or CDP platform there is a configuration screen most executives have never seen. It asks you to set match thresholds in three bands. Above the top threshold, records merge automatically. Below the bottom one, they're rejected. And in between sits the third band, the one every entity resolution playbook tells you to configure carefully:
Look at that middle band for a second, because it is a confession.
The architecture of probabilistic matching has a human review queue built into its design. Not as a workaround — as a load-bearing component. The entire discipline of tuning match thresholds is the discipline of deciding how much uncertainty to route to people. Which means every match rate you've ever been quoted — the 97-point-somethings that vendors put on slides — was never a pure quality claim. It was a price. It priced how much residual error your organization could absorb, given that the ambiguous cases would surface to a human, get squinted at, and get fixed.
That price was set for a world that is ending.
What happens when the review band has no one in it
An AI agent does not staff the review queue. When agents become the primary consumers of your resolved entities — and in most enterprise AI roadmaps I've seen, that's the explicit plan — the middle band doesn't get reviewed faster. It effectively collapses into auto-merge, at machine speed, with no squinting anywhere in the pipeline.
Notice what changed and what didn't. The match rate didn't change. The error destination did. A 2% residual mismatch used to be data-quality debt: it sat in the estate, occasionally embarrassed a report, eventually got cleaned. The same 2% now becomes executed error — payments routed, orders placed, records merged, decisions made — because the consumer acts instead of reads. I made a version of this argument in my last piece about governance in general: the green lights travel with the data, and the guess doesn't announce itself. Entity resolution is the sharpest case of it, because identity is the thing everything else joins on.
So the question I'd put to any architect right now is not "what's our match rate?" It's a question the vendor slide can't answer: which of our identities are guessed, and which never had to be?
The three rungs of identity
The industry talks about two kinds of matching. There are actually three rungs, and the difference between the second and third is the one that matters for agents.
- Guessed — Probabilistic matching — similarity scores, phonetic algorithms, ML models weighing name-address-date combinations. Genuinely impressive engineering, and for large parts of your estate, the only option. But the output is a probability wearing a record. Someone chose a threshold; the threshold chose your entities.
- Joined — Deterministic matching — exact joins on identifiers like email, phone, customer ID. This is often sold as the safe rung, and it's certainly better. But be precise about what the identifier is: something a counterparty typed into a form. Self-reported. The vendors' own implementation guides warn that self-reported fields cause false deterministic matches. A deterministic join on a self-attested identifier is still your systems trusting an unverified claim — it just trusts it exactly instead of approximately.
- Registered — An identifier administered by infrastructure outside both parties — a national organization number, a tax registration, a network participant identifier. Nobody matched anything. Nobody typed it into your form. It was issued, and its binding to the entity is maintained by someone whose job is exactly that.
Most enterprise architectures treat the third rung as a compliance detail. I think it's about to become the most valuable identity asset a company holds. Let me show you what "registered" actually means mechanically, because the difference from matching is not subtle.
What registration looks like from the operator's seat
On the Peppol network, before a business can receive a single document, it is published to the network's directory under a participant identifier — an identifier tied to a real-world scheme, like a national business registry number or a VAT registration. Publishing it is not a data entry task. As an Access Point operator, verifying that the party actually controls the identifier it claims is a condition of being allowed to operate on the network at all.
- Once published, an identifier lives in exactly one place. If a participant moves to another service provider, that's a formal migration with a handover, not an edit to a field. There is no scenario where two providers both "kind of" hold the same participant.
- And then discovery — the part that replaces matching — is almost boring. When a document needs to reach a counterparty, the network resolves the identifier through a lookup: identifier in, capability record and verified endpoint out. Or: failure. Those are the only two outcomes. There is no confidence score anywhere in that path. There is no threshold for me to tune. I could not configure my own infrastructure to deliver a document to "probably this company" if I wanted to — the option does not exist in the protocol.
- Clearance regimes go a step further down the same road. In the model we operate under in Saudi Arabia, the invoicing systems themselves are registered — cryptographically credentialed with the tax authority before they can submit anything. Not just who is this participant, but which specific system is speaking for them.
Hold that against the matching stack for a moment. One side of your architecture computes Jaro-Winkler distances to decide, at 94% confidence, whether two records are the same company. The other side already knows — not because it matched better, but because the question was answered at registration time by an external administrator, and the answer is binary by construction.
Where this argument has to stop
Now the boundary, because every piece in this series has one and this piece is no exception.
A registry resolves identity. It does not rate conduct. A registered participant can still default, deceive, or disappoint you — registration tells you who, never whether you should. If that sounds familiar, it's the same boundary clearance has: validity is not creditworthiness. Carry the registered identity into an agent's context without that boundary and you've rebuilt the exact failure I keep writing about.
And registered identity has edges of its own. One legal entity can legitimately hold identifiers under multiple schemes — a VAT number here, an organization number there, a GLN for logistics — so a registry removes the guessing about whether an identifier binds to a participant; it does not dissolve every question about corporate structure. More bluntly: most of your estate isn't on any registry at all. Consumers, prospects, the long tail of counterparties outside any mandate's scope — no one issued them a network identity, and no one is going to soon.
So the honest conclusion is not "matching is dead." It's that matching gets demoted — from the default mechanism for all identity to the residual mechanism for unregistered identity. That's a smaller kingdom than the one it rules today, and it keeps shrinking. Saudi Arabia completed the last of its twenty-four integration waves at the end of June — for a VAT-registered business there, operating on registered, cleared rails is no longer a phase-in; it is simply the condition of trading. The EU's 2030 requirements will do the same at continental scale.
The metric that replaces the match rate
If match rate was priced for humans, what's the agent-era number? I'd argue it's the share of your critical identities that are registered versus joined versus guessed. Call it guess exposure. It's not on any vendor slide, it's answerable with a weekend of analysis, and it tells you something a match rate structurally cannot: how much of your agents' ground truth was ever verified by anyone at all.
I might be early on this — enterprise B2B is my seat, and I may be overweighting how fast agents reach transaction-critical workflows elsewhere. But the direction seems hard to argue with. Every mandate wave moves companies from guessed to registered. Every agent deployment raises the cost of a guess.
This is the third piece in a series that turns out to have a shape. The golden record was a choice about what to believe. The witness was what you could check. The registry is the part you never had to guess — and knowing, precisely, which parts of your estate are which: that's the actual work.
Keep an eye out for the next one!
Mandate specifics, as at publication
Published 24 July 2026. ZATCA's Wave 24 — taxpayers with VAT-subject revenue above SAR 375,000 in 2022, 2023 or 2024 — had an integration deadline of 30 June 2026, as the essay describes. One update since: ZATCA announced Wave 25 on 24 July 2026, at a SAR 187,500 threshold with an integration deadline of 1 February 2027 — so the rollout has extended past the twenty-fourth wave rather than concluding with it. The direction of the argument is unaffected; if anything each further wave moves more companies from guessed to registered identity. The EU's ViDA package makes structured e-invoicing and digital reporting mandatory for intra-EU B2B trade from mid-2030. Current status is maintained on the mandate tracker and the Saudi Arabia briefing.
Data Trust — a three-part series
Part One — The golden record was always a choice
Part Two — You cannot govern your way to ground truth
Part Three — Your data match rate was priced for humans (this
essay)
First published by Qasim Shah on LinkedIn, 24 July 2026 — read the original. Republished here unedited.