Unreleased documentation. These pages follow the main branch and can change before the next release. For supported guidance, use v0.26.1.
Registry Stack documentation
Registry Stack helps institutions manage controlled access to authoritative data. Evidence Gateway signs the answer to a bounded question, Registry Relay publishes selected records from an existing source, and Base Registry Engine (BReg) provides a configuration-defined writable registry backed by PostgreSQL.
Answer a bounded question with Evidence Gateway
Section titled “Answer a bounded question with Evidence Gateway”Use Evidence Gateway when the caller needs to learn only a fact, not to read a record. It answers one bounded question about one subject and signs the answer, releasing the answer rather than the row behind it. For example, a licensing authority can answer whether a professional licence is active. Requirements and their permitted outputs come from reviewed configuration.
Evidence Gateway overview explains the source, assertion, verification, and audit boundaries. Continue with your first Evidence Gateway assertion to see the boundary in one verified request. When local authoring is complete, build and deploy an Evidence Gateway project creates a reviewed candidate without promoting local development state. Deployments provide a compatible OAuth issuer for protected service access.
Publish selected records with Registry Relay
Section titled “Publish selected records with Registry Relay”Use Relay when the caller needs to read specific records or fields. The
institution exposes a reviewed read-only SQLite view, a data publisher writes
one contract naming the resources, operations, access profiles, and disclosure
rules, and relayctl compiles, tests, and seals that contract into a package
the relay service verifies before it opens a listener. Database tables and
columns never become routes by convention.
Publish a governed SQLite registry runs the supplied synthetic business Registry end to end in about 20 minutes. Continue with author a Registry Relay project to bind an institution-owned view, then operate Registry Relay for sources, token issuers, audit retention, and revision replacement.
Build a writable registry with Base Registry Engine
Section titled “Build a writable registry with Base Registry Engine”Use Base Registry Engine when the institution needs a system of record it does not hold yet, with create and update operations. A registry project declares the entities, relationships, constraints, access profiles, and events; the compiler turns it into a PostgreSQL schema, a REST API, per-profile permissions, revision history, and an audit journal. Holdings, plots, businesses, and assets are configured models, not built-in types. Base Registry Engine overview explains what runs where and which path fits your role. Continue with create and query your first registry to make a verified request against a local registry. When the model is ready, build a production candidate tests, packages, and signs it, and query a registry from Python and Node calls it from an application.
Give a team a coordinated inbox with Registry Casework
Section titled “Give a team a coordinated inbox with Registry Casework”Use Registry Casework when authorized people must claim, draft, and decide work that a source system owns, or bounded decisions a calling service submits. A policy declares access profiles, queues, hosted kinds, routing, and clocks; the runtime keeps assignment, private drafts, accountable attempts, and recovery, while eligibility, visibility, and the registry mutation stay with the source. Staff, Supervisors, and Administrators are human roles the token issuer asserts; a Requester is a service. Registry Casework overview explains what runs where and which path fits your role. Continue with decide your first work item to run a local Casework with its database and token issuer, then author a Casework policy and deploy Registry Casework.
Keep the product boundaries clear
Section titled “Keep the product boundaries clear”Registry Relay owns source access and protected record surfaces. Evidence Gateway owns bounded question answering, signing, and minimum disclosure, and runs independently of Relay against its own configured authoritative sources. The caller receives only the output authorized for that service.
The products have separate adopter tooling and deployment contracts, while reusing shared Registry Platform primitives. Relay responses are not signed: portable signed minimum disclosure is what Evidence Gateway is for. BReg owns its PostgreSQL records; it does not publish them through Relay or configure Evidence Gateway on your behalf.
Registry Stack is not an eligibility, ranking, or automatic-decision engine. Registry Casework coordinates the people who decide; it does not decide for them, and the source system keeps the mutation. Registry Stack does not decide legal authority, data ownership, or institutional approval, and it is not a publisher of unrestricted open data. It makes those boundaries visible; the responsible institutions still make the decisions.
Who does what
Section titled “Who does what”- The assertion provider is the institution that answers requests with signed facts through Evidence Gateway.
- The data publisher is the institution that exposes records through Registry Relay, maintains a registry through Base Registry Engine, or decides work through Registry Casework.
- The consumer or verifier is the relying service that calls a product’s API and verifies the answers it receives.
- The operator is whoever runs the deployment.
One institution can hold several of these roles, and each tutorial names the role it is written for.