T02 inbox check, wired into make check and verified against the actual 2026-08-19 failure — replayed at that moment it surfaces all three messages that were already waiting. T03 sweeps the rest of the quietly-tolerated class: bad dates, cadence off the ladder, undefined disclosure states, dangling constraint_on and related refs, embargoes without conditions, escalations without triggers. T04 requests verification of user-engine's tenant boundary — the first walk down the on-request path, chosen as a consumer not already known to fail it. T05 established by trying what this register can verify: cluster yes, OpenBao 403. T06 puts regulatory records on the findings ladder. T01 stays in progress: the procedure, make due and make checked exist, but arming something that runs them on schedule is a standing compute commitment and the operator's to make. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| audit-retention-basis.md | ||
| README.md | ||
Regulatory intake
Moved here from policy-nexus on 2026-08-17: deciding what an external rule
demands of the estate is a judgement about risk, not an act of publishing.
One file per question. Each record states what a source says and when, and
what the estate therefore relies on. What the estate must consequently do is
the owning repo's decision, not this repo's — INTENT.md.
A record carries sources_read, determined, external_review (usually
none, and it must say so rather than implying otherwise), and review_by.
A regulatory answer expires; that is why it is dated and reviewed rather than
consulted once and discarded, which is the failure that moved this remit here.
These records are not legal advice and this repo cannot make them into any. Where a position is weak, the record says which part and why.
| Record | Question | Finding |
|---|---|---|
audit-retention-basis.md |
On what basis are audit records retained against an erasure request? | RISK-F-0008 |