Boundaries and map

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.

Registry Platform

registry-platform

Shared Rust workspace for security and operational primitives consumed by Registry Relay, Registry Notary, and related registry services, including auth helpers, OIDC verification, JWKS fetching, audit envelopes, HTTP security, outbound HTTP policy, 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.
• OID4VCI credential offer, nonce, credential request, and issuer metadata primitives via the `registry-platform-oid4vci` crate.
• Cross-service crate APIs that must behave consistently in Relay, Notary, and future registry services.
• Shared Rust hygiene templates and supported integration-test fixtures.

Does not own

• Registry Relay runtime data access, entity routing, metadata publication, or scope policy semantics.
• Registry Notary claim configuration, evaluation rules, disclosure policy decisions, or service routes.
• 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, public Notary federation, 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.
• Public Registry Notary federation metadata and evaluation profile validation.
• 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.

Source docs

• README
• Local examples

Registry Relay

registry-relay

Read-only HTTP gateway that fronts a sensitive registry database. Exposes entity-shaped query routes, caller-scoped metadata, evidence-offering discovery, and optional OGC API adapters while composing shared auth, OIDC, audit, HTTP security, and crypto primitives from Registry Platform.

Owns

• Runtime configuration and source binding.
• Entity-shaped Registry Data API routes.
• Relay-specific API key and OIDC resource-server configuration, scope checks, and route enforcement.
• Caller-scoped metadata publication.
• Relay-native evidence offering discovery and publication.

Does not own

• Source-registry provisioning, write-back, or domain-data mutation paths in v1.
• Portable metadata schema ownership.
• Standalone claim service internals owned by Registry Notary.
• Credential issuance, DID hosting, and issuer signing keys owned by Registry Notary.
• Shared security and operational primitives owned by Registry Platform.
• Storage table ids or arbitrary SQL in public APIs.

Source docs

• README
• Local API docs
• Local metadata docs

Registry Notary

registry-notary

Standalone service that evaluates Relay-backed or self-attested claims, serves static-peer federated delegated evaluation, and issues SD-JWT verifiable credentials with selective disclosure, composing shared auth, audit, OIDC, HTTP security, crypto, SD-JWT, and testing primitives from Registry Platform.

Owns

• Claim configuration and evaluation.
• Disclosure policy and redacted audit event semantics.
• Registry Notary API routes.
• Static-peer delegated evaluation at `/federation/v1/evaluations`.
• Credential issuance workflow and claim-to-credential mapping.
• OID4VCI Draft 13 credential offer flow (credential-offer, nonce, credential endpoints) and the `/.well-known/openid-credential-issuer` metadata endpoint.
• Compiler-pinned Registry Relay consultation contracts for registry-backed claims.
• Source-free and self-attested claim evaluation.

Does not own

• Registry source access, credentials, protocol adaptation, or Registry Relay runtime internals.
• Portable metadata renderers owned by Registry Manifest.
• Shared security and operational primitives owned by Registry Platform.
• Open federation, dynamic trust-chain discovery, shared replay storage, or federated credential issuance.
• Browser inspection workflows outside the current formal v1 stack scope.

Source docs

• README
• OpenAPI source

Solmara Lab

solmara-lab

Standalone Registry Stack adopter demo for the fictional Republic of Solmara. Runs published Registry Stack images pinned by digest with generated synthetic data, purpose-limited Relay APIs, Notary evidence services, and citizen portal journeys.

Owns

• End-to-end local and hosted demo topologies for Relay, Notary, Postgres, eSignet, static metadata, scenario services, and the citizen portal.
• Deterministic synthetic data, authority-owned demo configuration, purpose catalogues, and fictional country stories.
• 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

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

Flow across the stack

For how the four 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 CSV, XLSX, Parquet, or PostgreSQL source exposed as authorized entity routes?	Registry Relay
How is metadata.yaml validated or rendered into standards-facing artifacts?	Registry Manifest
How is a claim evaluated, delegated to a trusted Notary, or turned into an attestation or credential?	Registry Notary
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.
• 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.
• 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 paths, table IDs, scopes, cache paths, and backend runtime details belong in Registry Relay configuration, not in portable manifests.
• 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.
• 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.
• 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.
• 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.

Registry Relay is not an open-data portal. It publishes restricted consultation APIs for authorized systems only.

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.
• 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.
• 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.

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.
• Normative API or metadata contracts. API contracts are owned by Registry Relay and Registry Notary; metadata contracts are owned by Registry Manifest.
• 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.

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 four formal products connect at runtime and how the separate Solmara Lab demo consumes them.