registrystack / registrystack/registry-stack

Publish a DPI Safeguards-aligned coverage profile with honest enforcement status

Open
#595 0 comments 0 reactions 0 assignees View on GitHub
area:docs area:platform area:registryctl area:relay criticality:p2 documentation enhancement post-1.0 triage:roadmap
Dominant language
Rust
Stars
2
Forks
0
Avg merge
2h 57m
Merged PRs (30d)
128

Description

Tracked by #590. Depends on #593. Runtime-enforced outcomes also depend on #594.

## Outcome

Registry Stack publishes a versioned, reviewable DPI Safeguards-aligned profile that maps relevant framework requirements to concrete Registry Stack controls, external operator responsibilities, or explicit unsupported gaps without inventing a `dpi:` field taxonomy or claiming blanket compliance.

## Requirements

- Pin the exact DPI Safeguards framework source, version, retrieval provenance, and content digest used by the profile.
- Separate framework safeguards from semantic concepts and privacy classification vocabularies.
- Map only requirements relevant to Registry Stack's bounded responsibilities.
- For each mapping, record the safeguard reference, interpretation, applicable product surface, expected evidence, owner, and one status:
- `enforceable`
- `declared_external`
- `unsupported`
- `not_applicable` with rationale
- Bind `enforceable` entries to stable safeguard-profile rule IDs and concrete implementation tests or runtime evidence.
- Keep organizational controls, legal determinations, retention operations, human oversight, and other external responsibilities visibly outside runtime enforcement when Registry Stack cannot prove them.
- Produce a deterministic coverage report from the selected Registry Stack release, enabled features, semantic/classification profiles, and safeguard profile.
- Prevent report-only configuration, descriptive metadata, or an unverified classification from being presented as enforced.
- Include a review and update procedure for new framework versions and changed Registry Stack capabilities.

## Acceptance criteria

- [ ] Every included safeguard has an exact source reference and one unambiguous status.
- [ ] Every `enforceable` claim points to a stable rule ID, enforcement point, and passing evidence.
- [ ] External and unsupported responsibilities remain visible in generated output.
- [ ] No mapping treats `DPI Safeguards`, `HIPAA`, `GDPR`, or another regime name as an inherent field classification.
- [ ] The generated report is deterministic, bounded, versioned, and digest-covered.
- [ ] Documentation states that the profile is implementation coverage evidence, not a legal compliance certification.
- [ ] An independent policy/security review finds no unsupported enforcement claim.

## Non-goals

- A universal compliance engine
- Automated legal-basis or jurisdiction decisions
- Runtime interpretation of mutable framework web pages
- Replacing institution-specific risk assessment, approvals, or operating procedures
- Making every DPI Safeguards principle a Relay runtime feature

Contributor guide

Open the contributing guide

Research direction

The issue names no files, tests, or entry points. Start by reviewing the dependencies in #590, #593, and #594 and the repository’s existing profile and evidence conventions. Done means a versioned, deterministic coverage report meets every listed acceptance criterion, with independent policy/security review and no unsupported enforcement claims.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
documentation, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.