Ecosystem
Registry Stack assumes a wider ecosystem and is designed to fit into it, not replicate it. This page maps where it sits relative to the systems, standards, and tools already in use.
Neighbor systems
Section titled “Neighbor systems”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.
Reach for Registry Stack 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.
Reach for Registry Stack 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 should 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.
Reach for Registry Stack alongside 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.
Reach for Registry Stack 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.
Reach for Registry Stack 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 we adopt
Section titled “Standards we adopt”Registry Stack adopts established standards rather than inventing new ones. See the Standards register for the full table with claim levels (emit, map to, align with, compare against).
Short map:
- Metadata: DCAT, BRegDCAT-AP, CPSV-AP, ODRL.
- Shape: SHACL, JSON Schema, OpenAPI.
- Evidence: CCCEV (JSON-LD), SD-JWT VC, OID4VCI.
- Sector: SP DCI (mapped), OGC API Records (emitted), OGC API Features (aligned), GovStack Digital Registries Building Block (compared).
- Identity: W3C Decentralized Identifiers, restricted to the narrow DID surfaces the runtime services document.
No universal registry ontology is claimed.
What’s still open
Section titled “What’s still open”- No production integrations exist with named domain registry platforms. The design is shaped to support such integrations; the work itself is not yet done.
- AI-assisted integration is treated as context, not as a product pillar. AI tools can read contracts and generate clients faster, which makes narrow, named registry surfaces more valuable, not less.
- Sector standards adoption is at varying claim levels. Check the standards register before assuming conformance.