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 a governed service surface over data
you already operate: a published metadata contract, protected read-only APIs, configured evidence
answers, and tamper-evident audit records.

This is the one "why" page these docs keep. For the full problem framings, who benefits, and where
the stack fits in a wider stack, see the marketing site at
[registrystack.org](https://registrystack.org/).

## What it is

Registry Stack is a set of repositories with distinct responsibilities, organized around one
capability sequence: describe what a registry can provide, expose protected read-only access, then
certify evidence that fits the purpose of the request.

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 claims and returns a status, predicate, selected value, or
  signed credential, instead of the full source record.

The wider stack (Registry Manifest for portable metadata, Registry Atlas for inspection, Registry
Platform for shared primitives, and Registry Lab for a local compose demo) is described at
[registrystack.org](https://registrystack.org/). 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 Relay is read-only in v0: write operations (provisioning, inserts, updates) are out of
  scope.
- Registry Relay is not an open-data portal: it publishes restricted consultation APIs for
  authorized systems only.

## Next

- [See it live](../see-it-live/)
- [Choose by question (homepage router)](../../)
- [Architecture overview](../../explanation/architecture/)