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

# When to use Registry Stack

> What Registry Stack is, when it fits a registry integration problem, and the non-goals it deliberately leaves to other systems.

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](https://registrystack.org/).

## What it is

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.

{/* SVG diagram. Essential labels are restated in the bullets above and the sentence below. */}
<figure>
  <img src="../../images/registry-relay-or-notary.svg"
       alt="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." />
</figure>

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](https://github.com/registrystack/solmara-lab/tree/00cd51a2be4a405ef75d337ddcede0f9de134b1f)
adopter project demonstrates the four formal products in local and hosted topologies.
For how the pieces connect at runtime, see the [architecture overview](../../explanation/architecture/).

## When to use it

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](../../explanation/architecture/).

## Non-goals

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.

## Next

- [Run a protected registry API locally](../../tutorials/publish-spreadsheet-secured-registry-api/)
- [Evaluate a claim with Registry Notary](../../tutorials/verify-claim-registry-api/)
- [Choose by question (homepage router)](../../)
- [Architecture overview](../../explanation/architecture/)