Registry Stack

Registry Stack helps institutions run registry-facing services over the data they already hold and the registries they do not hold yet: a configuration-defined writable registry, signed minimum-disclosure assertions, a provider index, portable metadata, and audit records, without turning the registry into a shared database.

This repository is the monorepo source of truth for Registry Stack product code, release manifests, and docs.

Status: Registry Stack ships versioned v0.x releases for self-hosted deployments. APIs and deployment contracts may still change before 1.0. Adopters should use matching release artifacts and documentation for one version.

Start Here

Goal	Start here
Understand the product	registrystack.org
Read the technical docs	docs.registrystack.org
Get a first minimum-disclosure assertion	Evidence Gateway overview
Build a writable registry backed by PostgreSQL	Create and query your first registry
Publish an index of registry providers	Publish and consume a Registry Discovery index
Explore separate and combined product projects	Individual and combined examples
Install VS Code or Zed integration	Editor integrations
Work on the monorepo	See Development
Review the public roadmap	ROADMAP.md
Review release evidence	See Release And External Inputs

What It Includes

Registry Stack ships ten installable products on one release train. Each has its own deployment contract and adopter tooling, and each one is optional. An eleventh, the Document Store, is documented and built from source but held out of releases.

• Base Registry Engine: a configuration-defined writable registry backed by PostgreSQL. A registry project declares Record Types, relationships, constraints, access profiles, Actions, Proposals, and events; the compiler turns it into a PostgreSQL schema, a REST API, per-profile permissions, revision history, and an audit journal. Docs: Base Registry Engine overview. Two supporting services run beside it: breg-mcp, an MCP gateway a chat host uses to read one verified citizen's own data and draft a Proposal, and breg-review, the page where that citizen reviews and submits the draft. Docs: Citizen chat assistant.
• Evidence Gateway: signed, minimum-disclosure assertions from fixed requests to authoritative sources. Version 1 excludes credential lifecycles, documents, federation, and a general policy engine. Docs: Evidence Gateway overview.
• Registry Discovery: one immutable index built offline from an operator-approved list of public provider descriptions. It is a catalog, not a trust broker, authorization service, protocol adapter, or data proxy. Docs: Registry Discovery is an index.
• Registry Manifest: portable metadata that describes what a registry exposes, rendered without touching the production source. Docs: Registry Manifest reference.
• Registry Casework: a bounded human-review service with policies fixed at acceptance, accountable tasks, and correlated results. It runs with submitted snapshots or read-only current-source context; the producer authorizes later changes. Docs: Registry Casework overview.
• Registry Scheduling: a coordinated booking surface over anchored supply: published openings, exact-time offerings, arrival windows with channel subquotas, holds, and accountable appointments, with every capacity decision made inside one transaction under a task grant. Docs: Registry Scheduling API.
• Registry Messaging: sends one email or SMS to one recipient for an authorized caller, rendered from a reviewed template through a provider the operator connected, and reports what is known about delivery. Why and when to send, who the recipient is, and consent to be contacted stay with the caller's source of record. Docs: Registry Messaging API.
• Registry Render: renders a PDF from registry data to the same bytes every time, and can seal it with a PAdES signature. Docs: Registry Render overview.
• Registry Coordinator: finite, reviewed workflows of calls to the other products' APIs, kept across durable waits, outages, and restarts. Binaries, installer, and the client namespace ship from v0.44.0; its container image is held. Docs: Registry Coordinator overview.
• Registry Adapter: a governed facade that exposes a standard registry API over a source an institution already operates, from reviewed, digest-pinned packs. Binaries and installer ship from v0.46.0. Docs: Registry Adapter.

Evidence Gateway can use a fixed Base Registry Engine route or another bounded HTTP endpoint as a source, and keeps its own authorization either way. The stack also includes Registry Platform shared primitives, the bregctl, caseworkctl, schedulingctl, messagingctl, evidencectl, and discoveryctl adopter tools, unified Node.js and Python clients, and release tooling for validating the public source model.

Explore individual and combined examples

Use the product-owned projects to inspect each component separately:

Product	Example entry point
Base Registry Engine	Minimal directory, reviewed change, and facility registry
Evidence Gateway	Standalone HTTP assertions
Registry Casework	Standalone snapshot review and current-source review
Registry Coordinator	Maintained flows, including external directory and job examples
Registry Scheduling	Exact-time project and arrival-window project, with setup instructions
Registry Messaging	Starter project and local development instructions
Document Store	Starter project with three document policies and event hooks, held out of releases (product notes)
Registry Discovery	Offline catalog project
Registry Manifest	Static publication examples
Registry Render	Receipt, certificate, and card bundles, with compile instructions

For combined projects, start with BReg and Evidence, BReg and Casework review, or BReg events and Coordinator. The reviewed notice combines BReg, Coordinator, Casework, and Messaging; the deferred appointment combines BReg, Coordinator, Casework, Scheduling, and Messaging. Each project keeps product authority and deployment configuration separate.

Install a released build

# Base Registry Engine: breg and bregctl
curl -fsSL https://github.com/registrystack/registry-stack/releases/latest/download/breg-install.sh | bash

# Registry Casework: casework and caseworkctl
curl -fsSL https://github.com/registrystack/registry-stack/releases/latest/download/casework-install.sh | bash

# Registry Scheduling: scheduling and schedulingctl
curl -fsSL https://github.com/registrystack/registry-stack/releases/latest/download/scheduling-install.sh | bash

# Evidence Gateway: evidence, evidencectl, and evidence-oid4vci
curl -fsSL https://github.com/registrystack/registry-stack/releases/latest/download/evidencectl-install.sh | bash

Each installer verifies the binaries against the published SHA256SUMS before writing them to $HOME/.local/bin, or to the directory BREG_INSTALL_DIR, CASEWORK_INSTALL_DIR, SCHEDULING_INSTALL_DIR, or EVIDENCECTL_INSTALL_DIR names. For other products and the BReg citizen services, find their installers and check binary availability for your platform in the assets for your release tag.

Container images for breg, breg-mcp, breg-review, casework, scheduling, messaging, registry-render, evidence, evidence-oid4vci, and discovery are published as ghcr.io/registrystack/<name>:<tag>. See platform support for runtime and installer requirements.

flowchart LR
    source["Existing registry source<br/>file, extract, database, platform"]
    manifest["Registry Manifest<br/>describe"]
    breg["Base Registry Engine<br/>hold and update records"]
    evidence["Evidence Gateway<br/>minimum-disclosure assertions"]
    discovery["Registry Discovery<br/>index published providers"]
    caller["Approved service or verifier"]

    breg --> caller
    source -. fixed request .-> evidence
    breg -. protected fixed request .-> evidence
    evidence -. signed assertion .-> caller
    evidence -. advertisement .-> discovery
    discovery -. index lookup .-> caller

Loading

Repository Layout

• crates/: Rust crates and runnable binaries for Base Registry Engine, Evidence Gateway, Registry Casework, Registry Scheduling, Registry Messaging, Registry Discovery, Registry Manifest, Registry Platform, and the bregctl, caseworkctl, schedulingctl, messagingctl, evidencectl, and discoveryctl adopter tools. Base Registry Engine lives in crates/registry-breg with one breg binary, Evidence Gateway in crates/registry-evidence with one evidence binary, Registry Casework in crates/registry-casework with one casework binary, Registry Scheduling in crates/registry-scheduling with one scheduling binary, and Registry Messaging in crates/registry-messaging with one messaging binary. The Base Registry Engine citizen services live in crates/registry-breg-mcp (breg-mcp) and crates/registry-breg-review (breg-review).
• products/: product-owned docs, examples, Docker inputs, specs, security material, scripts, performance harnesses, and fixtures that are not normal workspace crates.
• docs/site/: the public Registry Stack docs site.
• editors/: source-installed VS Code and Zed semantic navigation integrations.
• release/: stack release manifests, schemas, import audit records, and public release and conformance tooling.
• external/: notes for external inputs that intentionally stay outside this source tree.

Development

Prerequisites:

• Rust toolchain from rust-toolchain.toml.
• Python 3.11 or later for release helper tests and conformance tooling.
• Node.js 24.11.0 and npm for docs/site.

Useful first checks:

cargo metadata --locked --format-version 1
cargo fmt --check
cargo check --locked --workspace --all-targets
cargo test --locked -p registry-evidence

Release source checks:

python3 -m unittest release/scripts/test_registry_release.py
release/scripts/registry-release validate release/manifests/registry-stack-beta-28.yaml
release/scripts/registry-release audit release/manifests/import-map-2026-06-24.yaml
release/scripts/check-release-source-model.sh
python3 -m unittest release/scripts/test_check_release_source_model.py

Docs checks:

cd docs/site
npm ci
npm test
npm run check

The GitHub Actions workflow in .github/workflows/ci.yml is the reference for the current pull request gate.

Major new functionality must include automated tests with the change proposal. Release candidates are built from exact protected-main source and lockfiles. Independent repeatability exercises run outside ordinary Beta publication. See CONTRIBUTING.md for the formal test and repeatability policies.

Release And External Inputs

Crosswalk remains an external pinned input and is not imported into this repository. Release builds use the pinned Git dependency declared in the root workspace manifest and record the exact ref in release/manifests/*.yaml.

Historical release manifests retain immutable Registry Atlas and eSignet relay authenticator refs for releases that used them as lab-only external inputs.

Release evidence lives in:

• release/manifests/
• release/notes/
• release/conformance/
• release/scripts/

Release assets are published with an authenticated SHA256 checksum chain. The exact candidate manifest and bundle are attested and verified before promotion. See release/VERIFY.md for verification commands and release/REPEATABLE-BUILDS.md for asynchronous repeatable-build evidence.

Support And Contribution

Use GitHub issues for non-security bugs, questions, and feature discussion. See SUPPORT.md for support expectations and CONTRIBUTING.md for contribution workflow. Before opening a pull request, run the relevant checks from Development and keep changes scoped to the owning crate, product, docs, or release area. Open issues are triaged with public labels described in CONTRIBUTING.md.

Security

Report vulnerabilities privately. See SECURITY.md before opening a public issue for suspected minimum-disclosure failure, auth bypass, audit redaction failure, source connector data leakage, or signing key handling bugs.

License

Registry Stack is released under the Apache License 2.0.