Safeguards need technical enforcement

A medical licensing authority signs a data-sharing agreement with a large insurance company: the practitioner registry may be queried to verify credentials for empanelment, and for that purpose only. The API the insurer calls has no purpose field, no scope narrower than “authenticated as the insurer,” and an audit log limited to HTTP access times. A year later, an inspector asked to confirm the insurer respected the agreement has nowhere to look.

The problem

The policy exists. The runtime cannot see it.

Registry integrations often rest on policy documents, signed agreements, or access approvals that sit outside the API. The route the caller actually hits does not know the caller’s purpose, allowed scope, disclosure limit, or audit requirement. When the runtime cannot see the safeguard, the safeguard is enforced by hope.

Why it matters

A safeguard that lives only in a signed document is not a control. It is a description of an expectation. The reviewer cannot see whether the expectation held; the registry owner cannot point to evidence; the caller cannot prove they stayed inside the line.

The reviewer’s question is not “was there a policy?” but “what did the API actually accept, return, and record?” Without a runtime answer, every audit becomes a conversation about what people remember.

Why common approaches stall

Paper agreements state the intended control. They stall the moment a request arrives at a runtime that cannot read the agreement, enforce its limits, or record what was disclosed against it.

Application-side checks can work inside a single system. They stall the moment the registry, the workflow tool, the exchange layer, and the reviewer each have a different copy of “what the policy was supposed to be.”

API gateway rules can authenticate the caller and rate-limit them. They do not say what purpose was authorised, what scope is allowed, or what was disclosed, and the access logs they produce are not the kind of audit record a reviewer can read.

What Registry Stack changes

The agreement does not change. The runtime starts knowing what it says.

Registry Manifest publishes the policy and evidence-offering metadata the deployment is operating under. Reviewers, callers, and operators can read the same contract.

Registry Relay enforces configured caller scopes and writes a tamper-evident audit record for each request: who asked, when, for what, against which dataset.

Registry Notary enforces configured claim rules, disclosure modes, and credential issuance paths. The evaluation event is itself recorded.

Registry Platform provides the shared primitives (authentication, audit envelopes, cryptography, SD-JWT handling) that make those guarantees consistent across components.

An inspector asking “did the insurer respect the agreement?” now has a record to inspect. Registry Stack does not decide what the agreement should say; it makes the agreement enforceable and the enforcement reviewable. For the broader model, see the architecture overview.

What is built today

The current docs describe Relay API-key and OIDC modes, dataset-scoped scopes, projected fields, declared filters, and tamper-evident audit records. They describe Notary disclosure modes, configured claim evaluation, delegated evaluation, credential issuance, OID4VCI routes, and audit-stamped results. They also describe Manifest policy and evidence-offering render outputs.

See DPI safeguards alignment, Authorize callers, and Evidence issuance.

What is future-facing or out of scope

Registry Stack does not decide legal basis, institutional accountability, or programme eligibility. It also does not replace security operations, incident response, retention policy, or human review.

The future Trust Control Plane is an operations direction, not a current v2 product surface.

Next

• Registry Platform overview
• Registry Relay reference
• Registry Notary reference
• Planned explanation: executable safeguards