Integration patterns
Registry Stack is the registry-facing surface that sits behind systems already in a delivery stack. This page describes the technical wiring for each neighbor: what the neighbor owns, what Registry Stack adds, and the conditions under which a Registry Stack surface belongs in the path. For where the registry family sits relative to the wider ecosystem as a product positioning, see the marketing ecosystem page.
Country evidence mesh
Section titled “Country evidence mesh”At country scale, the same pattern can sit next to several domain platforms. Clinical health systems can expose bounded facts through a FHIR API, public-health program systems can be reached through DHIS2 and OpenFn, and social protection, agriculture, education, and civil registration systems can keep their own authoritative stores. Registry Notary instances return configured claims to a social protection management information system and citizen-facing service channels without turning those consumers into raw-record readers.
Domain registry platforms
Section titled “Domain registry platforms”Examples: OpenCRVS (civil registration), OpenSPP (social-protection household and programme management), DHIS2 (health management information), OpenIMIS (health insurance information).
These platforms own storage, business rules, correction workflows, user interfaces, and a runtime API for their domain. Registry Stack adds standardized metadata description, scoped read-only routes over source data, configured evidence responses, and tamper-evident audit records.
Wire Registry Stack in alongside a domain platform when:
- The platform does not yet publish DCAT/BRegDCAT-AP catalogs or CPSV-AP service descriptions.
- Callers need evidence-shaped responses (predicate, redacted, selected value) rather than full records.
- A read path is needed for callers that must not be granted direct database access.
Workflow engines
Section titled “Workflow engines”Examples: OpenFn (cross-system orchestration popular in humanitarian and government data flows), Camunda, Flowable.
Workflow engines own process state, task assignment, timers, branching, retries, escalation, and history. Registry Stack adds a stable registry contract that workflow steps can call, without learning source tables, raw SQL, or full records.
Wire Registry Stack in alongside a workflow engine when:
- A workflow step needs an authoritative registry fact (status, predicate, selected value).
- A workflow step needs an evidence artifact or credential rather than an internal service result.
- Generated workflow connectors must not depend on source schema details.
Exchange layers
Section titled “Exchange layers”Examples: X-Road, OpenFn (when used as the cross-institution data flow), GovStack-style reference exchanges.
Exchange layers own participant onboarding, message transport, mutual trust, routing, addressing, and cross-institution policy. Registry Stack adds the registry-facing surface that sits behind the exchange layer: what entities exist, which fields are exposed, what evidence can be requested.
Wire Registry Stack in behind an exchange layer when:
- The exchange layer handles network trust but the registry endpoint still needs route-level scopes, field projection, and source-specific access controls.
- An exchange-forwarded request needs a configured evidence response rather than a copied record.
Wallets
Section titled “Wallets”Examples: SD-JWT VC wallets, OID4VCI-compatible wallets.
Wallets own key management, credential storage, holder consent, and presentation to relying parties. Registry Stack adds the server-side issuance path: claim evaluation against registry data, plus the metadata describing what a registry-backed issuer offers.
Wire Registry Stack in alongside a wallet when:
- A registry-backed issuer needs to produce SD-JWT VC credentials or an OID4VCI issuance flow.
- An evidence offering needs to be discoverable before integration begins.
Public-service platforms
Section titled “Public-service platforms”Examples: citizen portals, casework systems, service catalogue platforms.
These platforms own the user journey: forms, case queues, notifications, payments, channels. Registry Stack adds the narrow registry-facing surface those journeys can call: entity routes, evidence responses, scoped metadata, and audit records.
Wire Registry Stack in alongside a service platform when:
- A service platform needs a registry answer during delivery but must not pull the full record.
- A service catalogue needs to discover an evidence offering before integration.
Standards each surface speaks
Section titled “Standards each surface speaks”Each integration surface involves a different set of standards. The claim level differs per standard (some surfaces emit a standard, others map to or compare against it); the standards register is the authoritative list of claim levels and per-project evidence.
| Integration surface | Relevant standards |
|---|---|
| Catalog and service discovery (Registry Manifest, Relay metadata routes) | DCAT, BRegDCAT-AP, CPSV-AP, OGC API Records, SHACL, JSON Schema, ODRL |
| Protected data routes (Registry Relay) | OpenAPI, SP-DCI, GovStack Digital Registries, OGC API Features |
| Evidence and credentials (Registry Notary) | OpenAPI, CCCEV, SD-JWT VC, OID4VCI, W3C DID |