DPI safeguards alignment
Use this page to place Registry Stack inside a safeguards program and to distinguish software evidence from responsibilities that remain with the institution governing and operating a DPI.
Claim scope
Section titled “Claim scope”Registry Stack is compared against version 2.0 of the Universal DPI Safeguards Framework as implementation evidence, not as certification. The stack maps mainly to technical foundations. It does not create lawful basis, public mandate, inclusion practice, grievance handling, or independent oversight.
This mapping is hand-written documentation. Treat it as a reviewed argument that must be checked against the cited product contracts.
Safeguards support
Section titled “Safeguards support”| Safeguards question | Stack evidence | Boundary |
|---|---|---|
| What does the registry expose? | Registry Manifest renders portable catalog, schema, service, policy, and evidence-offering metadata. | Metadata describes a surface. It does not authorize access. |
| Who can request evidence? | Evidence Gateway authenticates the assertion caller against its configured OpenID Connect issuer and matches one complete entitlement before contacting a source. | Deployment policy decides who receives scopes and workload authority. |
| Is data minimized? | Evidence Gateway evaluates predefined requirements and returns only the declared concepts, each in a closed value form. | The operator still chooses the requirements and how coarse each value form is. |
| Can the exchange be reviewed later? | Evidence Gateway writes keyed audit records at durable gates. Signed assertions carry the configuration revision used to produce them. | Audit records support accountability but do not provide lawful basis or oversight. |
| Can other systems interoperate? | Manifest emits standards-shaped metadata. Evidence Gateway publishes OpenAPI and can serialize an assertion as a Selective Disclosure JWT Verifiable Credential. | These are scoped adoption claims, not blanket conformance to every named standard. |
Project roles
Section titled “Project roles”| Project | Safeguards contribution | Explicit boundary |
|---|---|---|
| Registry Manifest | Validates and renders portable catalog, schema, service, policy, and evidence-offering metadata. | Manifest does not serve HTTP, read production data, authorize callers, or evaluate claims. |
| Evidence Gateway | Evaluates predefined requirements against fixed, bounded source requests and returns signed, minimum-disclosure assertions with keyed audit. | Evidence Gateway does not accept caller-provided facts, run a general policy engine, decide eligibility, or certify source truth. |
| Registry Platform | Supplies shared primitives for authentication, audit envelopes, HTTP security, cryptography, secret references, and bounded source access. | Each runtime configures and enforces its own behavior. See RS-SEC-G. |
Principle alignment
Section titled “Principle alignment”| Framework principle cluster | How the stack helps | What remains outside the stack |
|---|---|---|
| Data privacy by design (O3) | Computed answers in closed value forms and selective disclosure reduce unnecessary data movement. | Legal privacy duties, data-subject rights, retention rules, and consent operations remain deployment responsibilities. |
| Data security by design (O4) | Protected operations authenticate and authorize before source access and use shared security primitives. | Key custody, network controls, incident response, and production hardening remain operator responsibilities. |
| Data protection during use (O5) | Evidence Gateway writes keyed audit records for each evaluation and returns stable denial codes. | A program still needs lawful basis, oversight, retention policy, and protections against overreaching requests. |
| Transparency and accountability (F4) | Portable metadata, OpenAPI references, stable error codes, audit records, signed assertions, and the standards register make behavior reviewable. | Public governance, remedies, procurement discipline, and independent accountability mechanisms are institutional controls. |
| Autonomy and agency (F6) | An Evidence Gateway subject is represented by an audience-scoped opaque binding, limiting correlation across relying parties. | The stack does not provide a wallet, consent journey, opt-out path, appeal process, or assisted service channel. |
| Inclusion and non-discrimination (F2, F3, O6) | Metadata, audit, and assertion records can help reviewers inspect what a service exposes and how it behaves. | Accessibility, language access, community participation, and non-digital alternatives require institutional action. |
Fit boundaries
Section titled “Fit boundaries”The stack fits at the implementation-evidence layer. Manifest metadata does not grant access, Evidence Gateway assertions do not decide benefits, and audit events do not replace remedy, supervision, or public accountability.