Registry stack documentation: machine-readable Markdown. Index of all pages: https://docs.registrystack.org/llms.txt Full corpus: https://docs.registrystack.org/llms-full.txt # Boundaries and map > The four formal Registry Stack products, the separate Solmara Lab adopter demo, and the boundaries between them. import ProjectMap from '../../../components/ProjectMap.astro'; The formal Registry Stack has four products with distinct responsibilities: Registry Platform, Registry Manifest, Registry Relay, and Registry Notary. Solmara Lab is a separate adopter project that demonstrates the four products together. Use this page to decide which repository owns a question before opening implementation docs, and to understand how the products and the external demo connect at runtime.
Four formal Registry Stack products and the separate Solmara Lab adopter demo. Registry Platform provides shared primitives. Registry Manifest compiles portable metadata. Registry Relay binds metadata to runtime sources and exposes protected APIs. Registry Notary evaluates claims and issues credentials. Solmara Lab runs published images of the runtime services in demo topologies.
{/* Generated from src/data/projects.yaml by the ProjectMap component. Update projects.yaml to change any row; do not hand-edit the table above. */} ## Flow across the stack For how the four products connect at runtime and how Solmara Lab demonstrates them, see the [architecture overview](../../explanation/architecture/). ## 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](https://github.com/registrystack/registry-stack) | | How is a CSV, XLSX, Parquet, or PostgreSQL source exposed as authorized entity routes? | [Registry Relay](../../products/registry-relay/) | | How is `metadata.yaml` validated or rendered into standards-facing artifacts? | [Registry Manifest](https://github.com/registrystack/registry-stack) | | How is a claim evaluated, delegated to a trusted Notary, or turned into an attestation or credential? | [Registry Notary](../../products/registry-notary/) | | How do the services run together in a local demo? | [Solmara Lab](https://github.com/registrystack/solmara-lab/blob/00cd51a2be4a405ef75d337ddcede0f9de134b1f/README.md) | Cross-project explanation, standards evidence, and contract indexes live in these docs (not in any one project repo). {/* Generated from src/data/projects.yaml does_not_own lists, reinforced below with evidence packet citations. */} ## 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. - Registry Notary claim definitions, evaluation rules, disclosure decisions, service routes, or claim-to-credential mapping. - 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. {/* Evidence: Boundary section, "must not depend on Registry Relay, Axum, DataFusion, Postgres, auth, audit, observability, runtime row access", crates/registry-manifest-core/README.md:33-41 at tag v0.9.0. */} - Auth, audit, observability, or secret handling. These are intentionally excluded so the library can be used without running any runtime service. {/* Evidence: Boundary section, crates/registry-manifest-core/README.md:33-41 at tag v0.9.0. */} - Production source configuration. Source paths, table IDs, scopes, cache paths, and backend runtime details belong in Registry Relay configuration, not in portable manifests. {/* Evidence: contracts.yaml, registry-manifest.metadata-yaml consumer note. */} - Runtime federation policy. Manifest can publish public Notary federation metadata, but peer allowlists, signing keys, replay stores, purpose policy, and evaluation scopes belong in Registry Notary config. No HTTP serving, no database queries, no authorization scoping. The manifest compiles and renders only. ## Registry Relay Registry Relay exposes protected read-only APIs over registry sources. It does not own: - Record provisioning or writes. The README explicitly states write operations are out of scope for v1. {/* Evidence: "Provisioning and Write are intentionally out of scope for V1", crates/registry-relay/README.md:20 at tag v0.9.0. */} - Portable metadata schema ownership. The `metadata.yaml` manifest format and its renderers are owned by Registry Manifest. Registry Relay may serve compiled artifacts over HTTP and scope them for callers, but the schema is defined and versioned in Registry Manifest. {/* Evidence: crates/registry-manifest-core/README.md:7-9 at tag v0.9.0 (schema ownership); registry-relay evidence packet, metadata publication section. */} - Standalone claim service internals owned by Registry Notary. Registry Relay can declare evidence offerings and route clients to a Registry Notary endpoint, but claim evaluation, disclosure policy, and credential issuance run in Registry Notary. {/* Evidence: registry-relay evidence packet, evidence offering verification section. */} - Shared auth, OIDC, audit, HTTP security, outbound HTTP, crypto, and SD-JWT helper primitives owned by Registry Platform. Registry Relay owns how those primitives are configured and enforced on Relay routes. - Storage table IDs or arbitrary SQL in public APIs. Public route paths use dataset and entity identifiers; internal table names and query shapes are configuration internals. {/* Evidence: projects.yaml, registry-relay does_not_own; registry-relay evidence packet configuration surface. */} Registry Relay is not an open-data portal. It publishes restricted consultation APIs for authorized systems only. {/* Evidence: crates/registry-relay/README.md:16 at tag v0.9.0. */} ## Registry Notary Registry Notary evaluates claims and issues SD-JWT VC credentials. It does not own: - Registry source access or adaptation. Registry Notary calls Registry Relay through a compiler-pinned consultation contract for registry-backed claims. A Notary-only deployment supports source-free and self-attested claims; it does not open a registry source directly. Relay owns HTTP, script, and snapshot adaptation, including protocol helpers used by authored integrations. - Portable metadata renderers owned by Registry Manifest. Registry Notary does not produce DCAT, SHACL, BRegDCAT-AP, or OGC Records artifacts. {/* Evidence: registry-notary evidence packet, standards not found in code section: "DCAT: no data.europa.eu/r8g references", "OGC API Records: no OGC references". */} - Shared auth, OIDC, audit, HTTP security, outbound HTTP, crypto, SD-JWT, and testing primitives owned by Registry Platform. Registry Notary owns the claim service behavior that composes those primitives. - Open federation, dynamic trust-chain discovery, shared replay storage, audit checkpoint exchange, or federated credential issuance. The current federation implementation is static-peer delegated evaluation only. {/* Evidence: FederationRuntimeState::from_config iterates config.peers with no dynamic discovery path, crates/registry-notary-server/src/federation/runtime.rs:32-50 at tag v0.9.0. */} - Registry Notary does not inspect published discovery artifacts, parse DCAT catalogs, or run capability queries. Registry Notary credentials are SD-JWT VC format (`application/dc+sd-jwt`), not W3C Verifiable Credentials Data Model JSON-LD envelopes. No W3C VC Data Model namespace or `@context` is present in the issued credential. {/* Evidence: registry-notary evidence packet, credential issuance section, "W3C Verifiable Credentials Data Model: NOT PRESENT". */} ## Solmara Lab Solmara Lab is a separately maintained adopter demo for the fictional Republic of Solmara. It runs published Registry Stack images in local and hosted topologies, 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. {/* Evidence: the pinned Solmara Lab README linked in the ownership table and src/data/projects.yaml, solmara-lab does_not_own "Production deployment guidance". */} - Normative API or metadata contracts. API contracts are owned by Registry Relay and Registry Notary; metadata contracts are owned by Registry Manifest. {/* Evidence: src/data/projects.yaml, solmara-lab does_not_own. */} - Real product integrations. The services simulate civil, social protection, and health registry patterns but are not real integrations with OpenCRVS, OpenSPP, DHIS2, OpenIMIS, MOSIP, or other systems. {/* Evidence: the pinned Solmara Lab README and src/data/projects.yaml. */} ## 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](../../explanation/architecture/): how the four formal products connect at runtime and how the separate Solmara Lab demo consumes them.