Boundaries and map

The formal Registry Stack has four products with distinct responsibilities: Registry Platform, Registry Manifest, Registry Relay, and Evidence Gateway. Registry Mint is a supporting service beside them, issuing short-lived access tokens for deployments that have callers and no identity provider. Solmara Lab is a separate adopter project that demonstrates the products together. Use this page to decide which project owns a question before opening implementation docs, and to understand how the products and the external demo connect at runtime.

Registry Platform

registry-platform

Shared Rust workspace for security and operational primitives consumed by Registry Relay, Evidence Gateway, and related registry services, including auth helpers, OIDC verification, JWKS fetching, audit envelopes, HTTP security, outbound HTTP policy, the bounded read-only SQLite boundary, crypto, SD-JWT VC support, and test fixtures.

Owns

• Shared auth, OIDC, JWKS fetching, audit, HTTP security, outbound HTTP, crypto, SD-JWT, and testing primitives.
• The bounded read-only SQLite access boundary both Registry Relay and Evidence Gateway open their sources through.
• Cross-service crate APIs that must behave consistently in Relay, Evidence Gateway, and other registry services.
• Shared Rust hygiene templates and supported integration-test fixtures.

Does not own

• Registry Relay contract compilation, resource routing, disclosure planning, or access-rule semantics.
• Evidence Gateway requirement definitions, authorization grants, disclosure decisions, service routes, assertion construction, or signing policy.
• Product-level authorization policy, tenant isolation, audit retention, secret provisioning, or deployment configuration.

Source docs

• README
• Registry Platform crates

Registry Manifest

registry-manifest

Renders standards-shaped catalog, service, schema, form, policy, evidence-offering, OGC Records, and embedded SKOS-shaped codelist metadata from a single YAML metadata manifest, so a registry's published surface stays consistent across formats.

Owns

• Metadata manifest model and compiled metadata model.
• Pure renderers for catalog, DCAT, CPSV-AP service catalogues, CCCEV requirements and evidence type lists, BRegDCAT-AP, SHACL, JSON Schema, form JSON Schema, OGC Records, policies, evidence offerings, and embedded SKOS-shaped codelist nodes.
• CLI validation, rendering, static publication, and profile fixture validation.

Does not own

• Registry Relay runtime data access.
• Auth, audit, observability, DataFusion, Postgres, Axum, or secret handling.
• Production source configuration.
• Evidence Gateway deployment configuration. An Evidence Gateway process loads one immutable governed bundle and one closed runtime file mounted read-only at startup, and reads no portable manifest.

Source docs

• README
• Local examples

Registry Relay

registry-relay

Publishes one existing authoritative registry as a governed, read-only HTTP API. An adopter writes a registry contract over a read-only SQLite source; the compiler turns that contract into the served routes, the semantic and governance artifacts, the disclosure and access decisions, and the audit record, so all of them agree by construction. It composes shared auth, OIDC, audit, HTTP security, bounded SQLite access, and crypto primitives from Registry Platform.

Owns

• The registry contract, its compiler, and the sealed package a deployment serves.
• Compiled read-only operations, limited to Consultation retrieve, list, and a constrained exact-lookup search profile, plus explicitly declared pre-aggregated statistical datasets.
• Generated artifacts derived from the one contract, covering OpenAPI, JSON Schema, SHACL shapes, JSON-LD contexts, codelists, and capability discovery.
• Disclosure profiles, access rules, requester minimization, and value-free audit events.
• The `relay` runtime binary and the offline `relayctl` adopter tooling that authors, checks, generates, tests, diffs, and packages a project.

Does not own

• Source-registry provisioning, write-back, or any domain-data mutation path.
• Record matching. A compiled exact lookup returns records, never candidates, confidence, or a matching explanation.
• Assertion evaluation, disclosure policy, and signing owned by Evidence Gateway.
• Shared security and operational primitives owned by Registry Platform.
• Portable metadata renderers owned by Registry Manifest.
• Storage table ids or arbitrary SQL in public APIs. A database object no resource declares stays invisible.

Source docs

• README
• Product concept
• Runtime crate

Evidence Gateway

registry-evidence

Minimum-disclosure assertion service. Given authenticated authority, an authorized purpose, a predefined requirement, and the selector data an authoritative provider needs, each evaluation answers one bounded question about one complete subject-role set and returns the smallest sufficient signed assertion. Its request-batch route groups up to sixteen independent audience-scoped evaluations under one common requirement and purpose. Evidence Gateway composes shared audit, crypto, HTTP security, OIDC, and SD-JWT primitives from Registry Platform.

Owns

• Requirement definitions, bounded evaluation, and the acquisition posture recorded with every answer.
• Authorization grants, purpose and audience checks, and the disclosure decision that releases an assertion.
• Fixed bounded HTTP JSON source execution, sequential request-batch fanout, and an optional fixed-path source-batch optimization with bounded script-owned preparation and extraction.
• Assertion construction, signing, response format selection, and redacted audit events.
• The `evidence` binary, one serving process, and one operator-controlled trust domain.

Does not own

• General source access, protocol adaptation, or Registry Relay runtime internals.
• Record lookup or identity resolution beyond a provider outcome of match, no match, or ambiguous.
• Portable metadata renderers owned by Registry Manifest.
• Shared security and operational primitives owned by Registry Platform.
• Token issuance, end-user authentication, or identity proofing.
• A credential lifecycle or delivery protocol. Evidence Gateway supports the declared holder-bound subject-binding mode and its bounded issuance envelope, but no OID4VCI, interactive holder-binding ceremony, issuance session, status list, revocation, delegated evaluation, or federation. SD-JWT VC remains a response format under a frozen profile, never a lifecycle.
• How a consumer acts on a returned assertion.

Source docs

• README
• Operator contract

Registry Mint

registry-mint

Supporting service rather than a product line. Issues short-lived, audience-bound access tokens to registered machine clients, so a resource server such as Evidence Gateway can require signed expiring tokens without the deployment first standing up a general purpose identity provider.

Owns

• The client registry that binds a client id to its registered authentication material and to the authority Mint asserts for it.
• The `client_credentials` grant with `private_key_jwt` as the default client authentication, plus explicitly selected client-secret compatibility for standard authorization clients.
• Token signing, lifetime, and audience binding, and the `mint` binary.

Does not own

• End-user authentication, identity proofing, or consent.
• Caller-declared authority. Authority is written from the client registry, never from the assertion payload.
• Evidence Gateway requirement definitions, authorization grants, or disclosure decisions.

Source docs

• README

Solmara Lab

solmara-lab

Standalone Registry Stack adopter demo for the fictional Republic of Solmara. Runs a whole country's worth of registry services over generated synthetic data, with six authority-owned Evidence Gateway cells that have their own providers, issuers, signing keys, JWKS, and audit sinks, five purpose-limited Relay projects, one lab Mint, a programme portal, and a public Visitor's Center. Some requirements read checkpointed immutable SQLite extracts and others read named Relay lookups, and the programme application composes the signed answers so that no authority decides for another.

Owns

• End-to-end local and hosted demo topologies for the authority Evidence Gateway cells, their Relay projects, Mint, static metadata, scenario services, the programme portal, and the Visitor's Center.
• Deterministic synthetic data, authority-owned demo configuration, purpose catalogues, and fictional country stories.
• The demo publisher lifecycle that mutates a Relay-backed source live and republishes a named immutable extract that only a rebound cell serves.
• Demo orchestration, smoke checks, browser journeys, hosted deployment wrappers, and release-pin checks.

Does not own

• Production deployment guidance.
• Normative API or metadata contracts.
• Real product integrations for OpenCRVS, OpenSPP, DHIS2, OpenIMIS, MOSIP, or other systems.

Source docs

• README
• Local topology
• Evidence cells
• Relay projects
• Relay source publisher
• Extract publisher

Update via projects.yaml. Generated from src/data/projects.yaml.

Flow across the stack

For how the products connect at runtime and how Solmara Lab demonstrates them, see the architecture overview.

Ownership quick reference

Question	Owning project
Which shared Rust crate owns auth helpers, OIDC verification, audit envelopes, HTTP security, outbound HTTP policy, crypto, SD-JWT VC helpers, or test fixtures?	Registry Platform
How is a SQLite extract or SQLite-backed registry exposed as a governed, read-only, authorized API?	Registry Relay
How is that registry contract authored, checked, and sealed into a package before it is served?	relayctl
How is metadata.yaml validated or rendered into standards-facing artifacts?	Registry Manifest
How is one bounded question about one subject answered with a signed assertion that carries the answer and not the record?	Evidence Gateway
How does a deployment with callers and no identity provider issue access tokens?	Registry Mint
How do the services run together in a local demo?	Solmara Lab

Cross-project explanation, standards evidence, and contract indexes live in these docs (not in any one project repo).

Registry Platform

Registry Platform is a shared crate workspace. It does not run a service or decide product policy.

Does not own:

• Registry Relay route behavior, runtime source binding, metadata publication, or Relay-specific scope semantics.
• Evidence Gateway requirement definitions, authorization grants, disclosure decisions, service routes, assertion construction, or signing policy.
• Operator responsibilities such as tenant isolation, audit retention, secret provisioning, deployment configuration, and incident response.

Use Registry Platform when a primitive needs to behave identically across services. Use the consuming repo when the question is about a product route, config file, or user-facing workflow.

Registry Manifest

Registry Manifest is a pure library and CLI with no runtime data dependencies.

Does not own:

• Registry Relay runtime data access. Manifest doesn’t serve HTTP, doesn’t talk to databases, doesn’t run inside a gateway.
• Auth, audit, observability, or secret handling. These are intentionally excluded so the library can be used without running any runtime service.
• Production source configuration. Source file paths, source view and column names, scopes, and other deployment details belong in the Registry Relay registry contract and runtime file, not in a portable manifest. Relay does not read a manifest to find them.
• Evidence Gateway deployment configuration. An Evidence Gateway process loads one immutable governed bundle and one closed runtime file mounted read-only at startup, and reads no portable manifest.

No HTTP serving, no database queries, no authorization scoping. The manifest compiles and renders only.

Registry Relay

Registry Relay compiles a reviewed registry contract into a fixed set of read-only operations and serves them over the read-only SQLite sources it binds. It owns the compiled contract: which operations exist, which reviewed views and columns they may read, which access profile guards each one, which disclosure profile shapes each response, and what its audit record says. Everything on that list is decided before the process starts, sealed into a package, and re-derived and byte-compared at startup.

It does not own:

• Record provisioning, writes, or any mutation path. This is not a scoping decision deferred to a later version: the router is a fixed set of 14 routes with exactly one POST (a declared lookup) and no PUT, PATCH, or DELETE anywhere.
• Source adaptation. Relay reads one local read-only SQLite file per binding, opened in place. It speaks no source protocol, holds no source credential, and makes no outbound call to a source, so a CSV, spreadsheet, Parquet, PostgreSQL, or HTTP registry has to be turned into SQLite by something else before Relay can serve it.
• Portable metadata schema ownership. The metadata.yaml manifest format and its renderers are owned by Registry Manifest. Relay does not consume a manifest and does not emit one: its artifact generator produces no registry-manifest.yaml, and a test holds that.
• Assertion evaluation, disclosure, and signing owned by Evidence Gateway. Relay signs nothing. A Relay response is a JSON document shaped by a disclosure profile, with no signature and no assertion semantics, and Relay declares no evidence offering.
• Shared auth, OIDC, audit, HTTP security, crypto, secret-reference, and read-only SQLite primitives owned by Registry Platform. Relay owns how those primitives are configured and enforced on its own operations.
• Storage internals in public APIs. Public route paths use resource and operation identifiers from the contract; source view and column names stay inside the compiled statements and never appear in a served response, an artifact, or an operational log line.
• External policy evaluation. Relay carries no policy decision point and evaluates no ODRL, consent, or jurisdiction rule. It checks the scope, purpose claim, and row authority its own contract names, and nothing else.
• The correctness or freshness of the data underneath. Relay returns what a reviewed view returns, and attaches no observation time to it.

Registry Relay is not an open-data portal and not a query service. It publishes a closed set of governed reads for authorized systems, and a caller cannot widen one. A request may narrow a response, by selecting fewer fields or filtering on a declared filterable field, but a field or filter the contract did not declare is a stable 400 rather than a wider read.

Evidence Gateway

Evidence Gateway answers one bounded question about one subject and returns a signed assertion carrying the answer rather than the record. It does not own:

• Source access as a general capability. Each evaluation uses one closed acquisition: one fixed bounded request, or one fixed search followed after a unique schema-valid match by one fixed fetch. A source reaches its data over one of two coequal transports. An HTTP JSON stage has a fixed method, a fixed or tagged selector or prior-fact-bound path, fixed non-secret headers, denied redirects, and a client-side response projection. A statement stage runs one reviewed SQL statement, with its declared result columns and parameter bindings, against a read-only SQLite extract file the runtime binds by logical profile, reaching no origin and resolving no credential. Pagination, transport retry, response-led routing, general multi-source fulfillment, and source-planning scripts are outside the Version 1 contract.
• Record lookup and identity resolution. The authoritative provider owns lookup. Evidence Gateway accepts only match, no_match, or ambiguous, and does not score candidates, choose a provider record, or expose counts, near-match hints, or per-field diagnostics.
• Portable metadata renderers owned by Registry Manifest. Evidence Gateway produces no DCAT, SHACL, BRegDCAT-AP, or OGC Records artifacts and consumes no manifest.
• Shared auth, OIDC, audit, HTTP security, crypto, SD-JWT, and testing primitives owned by Registry Platform. Evidence Gateway owns the assertion behavior that composes those primitives.
• Token issuance and identity proofing. Evidence Gateway verifies access tokens under one reviewed OIDC profile with exactly one trusted issuer; it issues none. Registry Mint issues them for a deployment with no identity provider.
• Consumer decisions. Requirements, eligibility, ranking, approval, routing, payment, workflow, and action policy stay with the accountable decision owner. Evidence Gateway is not a workflow, orchestration, or case-management engine and not a runtime policy engine or general PDP.
• A credential lifecycle. Version 1 has no issuance session, holder binding ceremony, status list, revocation, or presentation verification, and no federated or delegated evaluation between peers.

The default Evidence Gateway response is a flattened JWS JSON assertion (application/jose+json), not a W3C Verifiable Credentials Data Model JSON-LD envelope. An SD-JWT VC serialization (application/dc+sd-jwt) of the same stateless assertion is releasable only where the immutable bundle and the one matched authority grant both name that format, under the frozen profile in products/evidence/contracts/sd-jwt-vc-profile.yaml. That profile adds a response format, never a credential lifecycle.

Registry Mint

Registry Mint issues short-lived access tokens to registered machine clients so a deployment with no identity provider still has one. It does not own:

• End-user authentication, identity proofing, or consent. Registry Mint authenticates registered machine clients through private_key_jwt by default or an explicitly selected standard client-secret compatibility method, not people. A secret identifies the managed installation.
• Caller-declared authority. Token authority is written from the client registry and never from the caller’s own request.
• Evidence Gateway authorization. Evidence Gateway independently verifies the token and re-authorizes every request against its own bundle and authority grants.

Solmara Lab

Solmara Lab is a separately maintained adopter demo for the fictional Republic of Solmara. It uses generated synthetic data, but it is not a formal Registry Stack product. It does not own:

• Production deployment guidance. The demo uses generated synthetic data and demo configuration. It is not a reference for production configuration.
• Normative API or metadata contracts. API contracts are owned by the runtime services; metadata contracts are owned by Registry Manifest.
• Real product integrations. The services simulate civil registration, population, social protection, pension, and agriculture registry patterns but are not real integrations with OpenCRVS, OpenSPP, DHIS2, OpenIMIS, MOSIP, or other systems.

Where to look

Detailed setup, configuration, and command references live in the owning repo; cross-project orientation, standards evidence, and contract indexes live in these docs.

When a page needs both, these docs summarize the decision and link to the owning source.

Next

• Architecture overview: how the formal products connect at runtime and how the separate Solmara Lab demo consumes them.