Skip to content
Registry stack docs v0 · draft
Search

Architecture overview

The registry stack is organized around two layers: a portable metadata layer and a runtime services layer. The metadata layer (Registry Manifest) compiles and renders discovery artifacts that describe what a registry exposes, without touching production sources. The runtime services layer (Registry Relay, Registry Notary) binds those artifacts to real data, enforces access control, evaluates claims, serves delegated evaluation between trusted Notaries, and issues credentials. Registry Platform provides shared Rust primitives consumed by both runtime services. Registry Atlas inspects the published artifacts. Registry Lab runs all services together in a local demo.

This split matters because it separates the obligation to describe (what a registry declares it can expose and under what policy) from the obligation to enforce (what a running service will actually return to an authorized caller). A reviewer can audit the portable metadata bundle before any runtime service is deployed. An integrator can validate schemas and claim shapes offline. A governance team can publish updated policy documents without touching deployment config.

Architecture flow: Registry Platform provides shared primitives. Registry Manifest compiles metadata artifacts. Registry Relay binds those artifacts to protected runtime sources. Registry Notary evaluates claims against HTTP sources and issues credentials. Registry Atlas inspects published discovery outputs. Registry Lab wires runtime services into a local compose topology.

Data and contract flow

Section titled “Data and contract flow”
  1. Registry Platform provides reusable security and operational primitives consumed by runtime services.
  2. A metadata manifest (registry-manifest/v1 schema) describes datasets, entities, fields, policies, and evidence offerings.
  3. Registry Manifest compiles and validates the manifest, then renders a static discovery bundle (catalog, DCAT, SHACL, JSON Schemas, OGC Records items, policies, evidence-offering metadata, and an index.json).
  4. Registry Relay starts with runtime config that binds the manifest’s logical datasets and entities to actual data sources. Clients reach entity routes, metadata routes, and evidence-offering endpoints through configured auth.
  5. Registry Notary evaluates claims against configured HTTP sources (registry_data_api or dci connectors). It renders results as application/vnd.registry-notary.claim-result+json, CCCEV-shaped JSON-LD (application/ld+json; profile="cccev"), or SD-JWT VCs (application/dc+sd-jwt).
  6. A trusted Registry Notary can call another trusted Registry Notary through POST /federation/v1/evaluations for signed delegated evaluation. Registry Manifest can publish discovery metadata for that relationship, but local Notary peer policy grants access.
  7. Registry Atlas fetches published catalog and discovery artifacts through its proxy, classifies them by artifact kind, and runs strict capability queries over the indexed metadata terms.

For what each project does and does not own, see ownership boundaries and map.

Next

Section titled “Next”
  • Publishing pipeline explains the metadata compilation and artifact rendering path.
  • Consultation flow explains how Registry Relay serves authorized callers and scopes metadata by caller visibility.
  • Evidence issuance explains claim evaluation, disclosure policy, delegated evaluation, and credential issuance in Registry Notary.