Boundaries and map

The registry stack has six repositories with distinct responsibilities. Use this page to decide which repository owns a question before opening implementation docs, and to understand how the six repositories 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.

Registry Manifest

registry-manifest

Renders standards-compliant catalog, service, schema, form, policy, evidence-offering, and public Notary federation metadata artifacts (DCAT, CPSV-AP, CCCEV, BRegDCAT-AP, SHACL, JSON Schema, OGC Records, ODRL) 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, and evidence offerings.
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.

Registry Relay

registry-relay

Read-only HTTP gateway that fronts a sensitive registry database. Exposes entity-shaped query routes, caller-scoped metadata, and evidence-offering verification while composing shared auth, OIDC, audit, HTTP security, crypto, and SD-JWT 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 verification.

Does not own

Record provisioning or writes in v1.
Portable metadata schema ownership.
Standalone claim service internals owned by Registry Notary.
Shared security and operational primitives owned by Registry Platform.
Storage table ids or arbitrary SQL in public APIs.

Registry Notary

registry-notary

Standalone service that evaluates eligibility claims against registry data, 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.
HTTP source connectors for Registry Data API and SP DCI-style sources.

Does not own

Registry Relay source code or 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 owned by Registry Atlas.

Registry Atlas

registry-atlas

Browser workbench for inspecting what a registry publishes (catalogues, public services, requirements, schemas, policies, forms, and evidence offerings) and navigating the service-first semantic graph before integration code is written.

Owns

Browser UI for published catalogue, CPSV-AP service, CCCEV requirement, and registry discovery artifacts.
Local fetch proxy for inspected metadata endpoints.
Service-first semantic navigation over public services, requirements, evidence option groups, providers, access services, forms, and discovery gaps.
Strict capability queries over accepted machine terms.
Semantic asset discovery fixtures and envelopes.

Does not own

Registry runtime APIs.
Legal authorization or source-of-truth decisions based only on metadata discovery.
Natural-language inference in v0.1 capability discovery.
Persistent token storage in browser or proxy logs.

Registry Lab

registry-lab

Docker Compose demo of the registry runtime on a laptop. Wires three Relay instances, four Notary instances, live Postgres and Zitadel services, a private OpenFn sidecar scenario, a static metadata publisher, and narrated demo clients together with Registry Platform, Relay, and Notary source pins, fixtures, and smoke tests.

Owns

End-to-end local topology for Relay, Notary, live Postgres, live Zitadel, the private OpenFn sidecar path, the static metadata publisher, and demo-client fixtures (Atlas is run separately and is not in the compose topology at v0.1).
Demo scripts, smoke checks, generated local credentials, live-service checks, service-first discovery checks, and narrated client flows.
Citizen self-attestation walkthrough that exercises the Notary OID4VCI flow end-to-end through the `just citizen-oid4vci-*` recipes.
Acceptance rehearsal after rename waves land.

Does not own

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

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

Flow across the stack

Registry Platform provides shared Rust primitives that Relay and Notary compose for auth, audit, OIDC, HTTP security, crypto, SD-JWT VC handling, outbound HTTP policy, and testing. Registry Manifest defines portable metadata and compiles it into standards-facing service, registry, schema, form, policy, evidence, and public Notary federation artifacts. Registry Relay binds logical datasets and entities to protected runtime sources and exposes them as authorized read-only APIs. Registry Notary evaluates configured claims against registry sources, serves static-peer delegated evaluation, and issues SD-JWT VC credentials. Registry Atlas inspects published discovery artifacts, parses service catalogues and registry metadata, and navigates service-first requirements, evidence options, providers, forms, and access routes. Registry Lab runs the smallest local ecosystem demo, composing three Relay authorities, four Notary services, live Postgres and Zitadel services, a private OpenFn sidecar path, a static metadata publisher, and narrated clients.

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 are discovery artifacts inspected or matched against capability needs?	Registry Atlas
How do the services run together in a local demo?	Registry 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 source 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 Relay source code or runtime internals. Registry Notary calls Registry Relay over HTTP using a source connector; it does not import or link Registry Relay libraries. Both services can depend on Registry Platform.
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.
Browser inspection workflows owned by Registry Atlas. Inspecting published discovery artifacts, parsing DCAT catalogs, and running capability queries are Atlas responsibilities.

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.

Registry Atlas

Registry Atlas is a browser workbench for inspecting published discovery artifacts. It does not own:

Registry runtime APIs. Atlas inspects artifacts that are already published; it does not own the APIs that serve them.
Natural-language inference in v0.1 capability discovery. The v0.1 capability matcher is strict: no fuzzy matching, synonym expansion, or AI inference. Every match requires exact label, IRI, or field name correspondence after documented canonicalization. Natural-language query assist is explicitly deferred.
Persistent token storage in browser or proxy logs. Bearer tokens are session-only and are never written to browser storage or server logs.

Atlas-derived hypotheses such as candidate_route and gap flags are not standards predicates and must not be published back into metadata catalogs as if they were source-verified claims.

Registry Lab

Registry Lab is a compose-based local demo. It does not own:

Production deployment guidance. The demo uses CSV, XLSX, and Parquet fixtures and demo-grade credentials. 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.

Documentation rule

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

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

Next: Architecture overview: how the six projects connect at runtime.

Looking for the legacy-to-current name mapping or per-repo rename state? See the 2026-05-23 rename decision.