Skip to content
Registry StackDocsv0.13.0

When to use Registry Stack

View as Markdown

Registry Stack is a registry-facing layer for institutions that already hold authoritative data. It does not store records or run a domain registry. It adds controlled service surfaces over data you already operate: a published metadata contract, protected registry APIs, governed evidence responses, and hash-chained audit records.

For broader problem framing, who benefits, and where the stack fits in a wider ecosystem, see registrystack.org.

Registry Stack supports two runtime patterns:

  • Protected Registry APIs expose files, extracts, databases, and legacy registry systems through scoped, read-only routes.
  • Evidence Gateway evaluates the request, source context, policy, freshness, redaction, and audit requirements before returning a protected read, minimized fact, selected value, signed claim result, credential, redacted result, or denial.

These docs cover the two products you build against directly:

  • Registry Relay exposes existing source data (a file, extract, database, or legacy system) through protected, scoped, read-only HTTP routes, without giving callers database access.
  • Registry Notary evaluates configured evidence claims and returns a status, predicate, selected value, or signed credential, instead of the full source record. An evidence consumer uses that evidence, while the decision owner remains accountable for any resulting requirements, decisions, or actions.
Decision strip. A caller that needs the records themselves uses Registry Relay:
protected, scoped, read-only HTTP routes over existing source data, without giving
callers database access. A caller that needs an answer, evidence, or a credential
uses Registry Notary: a status, predicate, selected value, or signed credential
(SD-JWT VC), instead of the full source record. In a combined project, Registry
Notary consumes compiler-pinned consultation results from Registry Relay.

The two patterns also compose. A combined Registry Stack project compiles source access and adaptation into Registry Relay, then binds Registry Notary claims to the resulting typed, contract-hashed consultation profiles. Registry Notary does not treat Relay as an arbitrary HTTP source.

The other two formal products are Registry Manifest for portable metadata and Registry Platform for shared primitives. The external Solmara Lab adopter project demonstrates the four formal products in local and hosted topologies. For how the pieces connect at runtime, see the architecture overview.

Reach for Registry Stack when a registry that already exists needs a governed read path, and one or more of the following is true:

  • Data exists in files, extracts, databases, or legacy systems, but other services cannot depend on a clear, approved interface over it.
  • Callers need a status or evidence response, but the available record APIs move more data than the purpose requires.
  • A data-sharing agreement describes intended access on paper, but the API itself has no scopes, no purpose field, no disclosure limits, and no audit record.
  • Other teams need to inspect a registry’s fields, schemas, policies, services, and evidence offerings before they integrate.
  • A registry-backed issuer needs to produce SD-JWT VC credentials or run an OID4VCI issuance flow.

For how the stack wires in behind exchange layers, workflow engines, wallets, and domain platforms, see the architecture overview.

Registry Stack deliberately leaves these to other systems:

  • It does not replace a domain registry platform (such as OpenCRVS, OpenSPP, DHIS2, or OpenIMIS), a workflow engine, an exchange layer, a wallet, or a public-service portal. It provides the registry-facing controls those systems call.
  • It does not solve foundational identity, deduplication, legal authority, semantic governance, or institutional approval by itself. It makes those boundaries explicit so they can be reviewed before data moves.
  • Registry Notary is not an eligibility, prioritization, workflow, or action engine. It evaluates atomic, reusable evidence statements under evidence authorization and disclosure policy. The evidence consumer determines how the evidence is used, and the decision owner retains accountability for its rules and outcomes. Notary can attest a decision already made by an authoritative source only when the claim identifies the decision as source-owned.
  • Registry Relay does not mutate source registry data: provisioning, inserts, updates, and write-back are out of scope for its consultation API.
  • Registry Relay is not an open-data portal: it publishes restricted consultation APIs for authorized systems only.