DPI safeguards alignment
If you are a DPI implementer or reviewer trying to place the registry stack inside a safeguards program, this page compares the stack to the Universal DPI Safeguards Framework at the technical implementation layer. It shows where it helps and where it does not.
The registry stack is not a complete safeguards program. The broader safeguards outcome depends on the institution that governs, deploys, audits, and operates the DPI system. Alignment with this page is not certification.
Good fit and poor fit
Section titled “Good fit and poor fit”The registry stack fits best when a team needs to expose sensitive registry facts to authorized systems without making raw registry data broadly available.
Good fit:
- Cross-ministry intake checks (one ministry asks another whether a person is registered, without copying the record).
- Social protection eligibility evidence (a program checks whether a household meets a criterion, without fetching the underlying data).
- Civil registration fact verification (a downstream service checks a vital fact against the authoritative registry).
- Interagency aggregate statistics (configured aggregates instead of raw rows).
- Signed evidence receipts that a downstream reviewer can verify later.
Poor fit:
- Unrestricted public data portals.
- Generic data warehouses or ad-hoc SQL access.
- Unrestricted record export.
- Service decision engines operating without external governance.
Reference framework
Section titled “Reference framework”The Universal DPI Safeguards website is the online reference for the safeguards initiative and framework.
Technical alignment
Section titled “Technical alignment”The registry stack is most relevant where safeguards depend on:
- Controlled access: authorized systems only, with API key or OIDC.
- Data minimization: configured fields, declared filters, selective disclosure on credentials.
- Purpose-bound exchange: per-claim disclosure policy and per-caller metadata scoping.
- Auditability: redacted audit events, signed evidence receipts.
- Reviewable metadata: published DCAT, SHACL, JSON Schema, and policy documents.
- Verifiable provenance: DID documents, SD-JWT VC credentials, provenance receipts.
These are technical foundations that can support a DPI program’s governance work. They are not a substitute for it.
Alignment pillars
Section titled “Alignment pillars”Privacy by design. Registry Relay can expose only configured fields, require filters, separate metadata from runtime bindings, and evaluate evidence without returning raw registry rows by default.
Data security by design. Registry Relay enforces authorized access via API key or OIDC, keeps admin routes off the public listener, runs read-only against its sources, and applies body limits and timeouts at the gateway.
Transparency and accountability. Registry Manifest and Registry Relay publish what a registry exposes (OpenAPI, metadata routes, schemas, evidence offerings, policies, stable error codes, and provenance artifacts) so reviewers can inspect it before integration.
Open assets and interoperability. Registry Manifest, Registry Relay, and Registry Notary produce or reference standards-shaped artifacts (DCAT, SHACL, JSON Schema, ODRL, OpenAPI, and SD-JWT VC profiles) so downstream systems can consume them without bespoke contracts.
Evidence-based improvement. Audit logs, aggregate disclosure records, validation reports, provenance receipts, and standards registers can provide material for review and impact assessment.
This alignment is strongest at the implementation-evidence layer. It helps reviewers see what a registry system exposes, which project owns each surface, and which controls are available before deployment decisions are made.
Stack commitments and framework pillars
Section titled “Stack commitments and framework pillars”The registry stack’s three commitments map to the framework’s five pillars:
| Stack commitment | DPI Safeguards pillar |
|---|---|
| Interoperability | Open assets and interoperability |
| Safeguards | Privacy by design; Data security by design |
| Reviewability | Transparency and accountability; Evidence-based improvement |
Distributed custody is the architectural premise of the stack rather than a pillar of its own. It supports every framework pillar by ensuring no single authority can compromise data flowing from another.
Governance boundary
Section titled “Governance boundary”The Universal DPI Safeguards Framework covers more than software controls. A DPI program still needs lawful basis, public governance, procurement discipline, data protection operations, accessibility, remedies, oversight, security audits, and community participation.
The registry stack does not obtain consent, approve data-sharing agreements, run grievance channels, certify production sources, or make final eligibility decisions. It also does not replace a data protection impact assessment, independent security review, or public consultation process.
The intended boundary is clear: registry components produce evidence that responsible institutions can review. They do not hide governance decisions inside software.