Preview release. These docs are a work in progress. Pages are still being written, links may break, and structure may shift without notice. Treat everything here as a draft and report issues on GitHub.
Why safer registry surfaces matter now
Registry Stack is infrastructure for safer registry interoperability. It gives human teams, exchange layers, workflow engines, and AI-assisted tools a registry surface to work against, instead of raw files, undocumented tables, broad APIs, or copied extracts.
The goal is not to make registries available to AI; it is to make registry use explicit, governed, and reviewable for every caller. AI and automation make that goal more urgent because they let teams build integrations faster than they can understand the data, the authority for access, the disclosure risk, or the meaning of each field.
The existing problem
Section titled “The existing problem”Registry-like data often exists before the service surface around it exists. An institution may have the right spreadsheet, extract, database, or legacy application, but not the metadata, API contract, access policy, disclosure rule, or audit trail that another service needs.
When that happens, policy stays in documents and meetings. The runtime system does not know which caller is allowed to use which route, which fields can leave the source boundary, which evidence response is acceptable, or which audit event must be created.
That is the gap Registry Stack targets: make registry use operational, not only documented.
What Registry Stack enables
Section titled “What Registry Stack enables”Registry Stack provides registry-facing tools that make existing data usable and safer to depend on.
- Registry metadata gives humans and tools structured information about datasets, entities, fields, schemas, policies, services, and evidence offerings.
- Registry Relay exposes configured read-only routes over existing sources. A caller cannot widen the route at request time to fetch extra fields or broader source records.
- Registry Notary can answer configured evidence questions instead of forcing source-record access.
- Audit behavior records trust-critical access and evidence events for review.
- Semantic metadata makes meaning, sensitivity, and assumptions visible before integration code is written.
These controls are useful for ordinary integrations today, and they give automated and AI-assisted integrations safer material to work from.
From policy text to runtime checks
Section titled “From policy text to runtime checks”Safeguards are weak when they exist only as principles, policies, or implementation notes. Registry Stack helps enforce policy at the point of access.
A registry surface can require a caller scope before a route is used. It can expose only declared fields. It can return a configured evidence response instead of a full record. It can make purpose, policy, and disclosure rules inspectable before integration work starts. It can record the access or evidence event for later review.
That does not remove the need for legal authority, governance, human review, or appeal paths. It makes those decisions easier to operationalize because the registry surface can carry and enforce part of the policy.
The question shifts
Section titled “The question shifts”Without these controls, the main question is whether two systems can connect. For modern interoperability, that question is too weak.
The better question is whether this request is legitimate, scoped, meaningful, minimal, and auditable. That requires a registry surface that can answer practical review questions.
- Which entity or evidence response is being requested?
- Which purpose, policy, and scope apply?
- Which fields or claims can leave the source boundary?
- Which semantic definition is being used?
- Which audit event records the access or evidence decision?