Entity identity and matching are unclear
A tax authority queries a cadastral registry to confirm that a taxpayer owns a parcel before issuing a property-tax assessment. The cadastral registry is keyed by parcel ID; the tax authority knows the owner by taxpayer number and a name on the deed. The cadastral service responds “owner confirmed.” It does not say which cadastral record it matched, on what fields, or how confident the match was. The assessment goes out anyway.
The problem
Section titled “The problem”Two registries can be about the same thing. They are rarely keyed the same way.
Two registries can describe the same person, company, facility, parcel, or licence under different local identifiers. They can also contain duplicates, stale links, or records that are similar enough to match operationally but not strong enough to prove identity.
When the API route or evidence response omits the identifier basis (“matched on taxpayer number and surname”), the downstream system can treat a weak match as a strong identity assertion. The assumption disappears into integration code.
Why it matters
Section titled “Why it matters”A signed “active” or “owner confirmed” answer carries the weight of the registry behind it. If the answer is about the wrong subject, the registry’s authority got attached to a mistake.
The reviewer cannot find the mistake by reading the response: the response looks correct. They have to find the matching rule, somewhere in deployment code or an integration script, and ask whether it should have matched at all.
Why common approaches stall
Section titled “Why common approaches stall”Matching glue inside integration code is the most common pattern. One system sends a local ID, the other searches by name or tax number, and the mapping rule sits in code, deployment config, or an operations playbook. It works for one trusted pair. It stalls when a reviewer, an auditor, or a third partner needs to see which record was matched and why.
A single foundational identifier is sometimes proposed as the answer. Some deployments have such an identifier for some entities. Many registry domains still operate with local keys, source identifiers, and relationship metadata, and pretending otherwise creates incorrect linkages elsewhere.
Probabilistic entity resolution services can match records well in batch. They do not, by themselves, produce an answer a downstream service can act on with confidence: an unbounded probability score is not an identity assertion.
What Registry Stack changes
Section titled “What Registry Stack changes”The match becomes part of the contract.
Registry Manifest describes the entity schemas and evidence offerings the registry exposes, including which identifier fields the entity is keyed on.
Registry Relay exposes entity-shaped routes rather than raw storage tables. A caller asks for an entity by a declared identifier, and the route either returns the entity or does not match: there is no implicit join hidden in the response.
Registry Notary evaluates configured claims against named subject inputs and records the claim result, including which source record the subject input was bound to.
The cadastral service can still answer “owner confirmed” to the tax authority. The answer now carries which record matched and on what basis, instead of asking the assessor to trust a hidden join. Registry Stack does not decide that two records are the same entity; the deployment configures that behavior. For the broader model, see the architecture overview.
What is built today
Section titled “What is built today”Registry Relay documents public entity routes, configured identifiers, declared fields, and scope-controlled reads. Registry Notary documents claim definitions with subject types, inputs, source bindings, evaluation rules, and disclosure policy. Registry Manifest documents entity schemas and evidence-offering metadata.
See consultation flow and evidence issuance for the current runtime models.
What is future-facing or out of scope
Section titled “What is future-facing or out of scope”Registry Stack is not a foundational identity system. It does not provide national ID issuance, biometric deduplication, universal entity resolution, or master data management.
Future pages can describe patterns for carrying resolution evidence and matching metadata. Those patterns will still depend on deployment-specific identity and data-governance decisions.
- Registry Relay overview
- Registry Notary overview
- Glossary
- Planned explanation: federation boundaries