RISK-WP-0004: five of six tasks done; the executor is the operator's call

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>

workplans/RISK-WP-0004-run-the-register.md

@@ -48,7 +48,7 @@ Every task below traces to something that happened, not something imagined.
 
 ```task
 id: RISK-WP-0004-T01
-status: todo
+status: progress
 priority: high
 ```
 
@@ -67,11 +67,13 @@ stamps `clean` without doing that is worse than no job, because it manufactures
 a stability signal that is false. That is the `RISK-F-0002` failure mode
 applied to this repo's own instruments.
 
+In progress 2026-08-20. The procedure exists (`docs/method/check-procedure.md`), `make due` prints the work list, and `make checked` records an outcome. **What does not exist is the thing that runs it on schedule**, and this register does not get to arm a standing compute commitment on the operator's behalf. The doc names the three options and says which survives the operator being busy. Stays open until that decision is made; until then, every finding sitting at `instant` is telling the truth about how often `make check` is run.
+
 ### T02 — Inbox before grading, as a check rather than a habit
 
 ```task
 id: RISK-WP-0004-T02
-status: todo
+status: done
 priority: high
 ```
 
@@ -84,11 +86,13 @@ message this repo has received about that system, and report any finding whose
 inbox has spoken more recently than its register has. That is mechanical and
 does not require the tooling to understand the message.
 
+Completed 2026-08-20. `tools/inbox_check.py`, wired into `make check`. Compares each finding's `last_checked` against messages this repo has received about that system, and reports any finding whose inbox has spoken since the register last looked. Mechanical: it matches timestamps and names, reads nothing, decides nothing. Verified against the actual failure — replayed at the moment of the 2026-08-19 grading it surfaces all three flex-auth/rapp-postgres messages that were already waiting. An unreachable hub reports UNREACHABLE rather than silently passing, because a check that cannot see the inbox cannot be certified current.
+
 ### T03 — Fail loud everywhere else too
 
 ```task
 id: RISK-WP-0004-T03
-status: todo
+status: done
 priority: medium
 ```
 
@@ -99,11 +103,13 @@ not exist, an `embargo_condition` on a finding that is not embargoed.
 
 Every one of them should be reported by name and keep the finding watched.
 
+Completed 2026-08-20. `make check` now reports, by name and without ever silently ignoring: unparseable dates, a cadence that is not a rung, an undefined disclosure state, a severity off the scale, a `constraint_on` or `related` pointing at a finding that does not exist, an embargo condition on a finding that is not embargoed, an embargo with no condition, and an escalation with no trigger. Nothing is malformed today, which is the answer that only means something because the check exists.
+
 ### T04 — Exercise the on-request verification path once
 
 ```task
 id: RISK-WP-0004-T04
-status: todo
+status: done
 priority: medium
 ```
 
@@ -115,11 +121,13 @@ path, and see what actually happens: who answers, what evidence comes back,
 whether the finding's likelihood moves for that consumer, and what the record
 looks like. The value is in the friction it exposes.
 
+Completed 2026-08-20 as far as this repo can complete it. `RISK-V-0002`: verification of `user-engine`'s tenant boundary requested through the documented path. `user-engine` was chosen because they are a consumer with a boundary and *not* already carrying a finding about one — using `tenant-engine` or `audit-core` would have tested the path against systems already known to fail it. The outcome is pending and all three outcomes are useful, including silence, which would tell the estate that `RISK-F-0007` is being carried on an assumption that asking works.
+
 ### T05 — The verification credential
 
 ```task
 id: RISK-WP-0004-T05
-status: todo
+status: done
 priority: medium
 ```
 
@@ -133,11 +141,13 @@ source. Establish what this repo can legitimately verify itself, and what it
 must always take from owners. **If the answer is "nothing", that is worth
 knowing and writing down**, because it bounds every grade in the register.
 
+Completed 2026-08-20, by trying rather than reasoning. `docs/method/verification.md`. **Cluster reads work from this host; OpenBao returns 403**, the same wall `ops-warden` hit. So the register can check what the cluster admits and cannot check what the secret store permits, and every grade touching an OpenBao policy is a grade on a document. That asymmetry is recorded rather than closed — a risk register holding production secret-store credentials would have traded a verification problem for a worse one. First use produced `RISK-V-0001`, which confirmed `RISK-F-0001`'s ingress claim against the live cluster, contradicted the `egress: []` claim in the same message, and surfaced a third NetworkPolicy with no ingress rules that bears on whether `ops-warden` enabling its gate would fail closed.
+
 ### T06 — Regulatory records on the same ladder
 
 ```task
 id: RISK-WP-0004-T06
-status: todo
+status: done
 priority: low
 ```
 
@@ -145,6 +155,8 @@ Duplicate of `RISK-WP-0003-T04`, kept here as a pointer rather than a second
 copy. Whichever workplan reaches it first does it; the other closes with a
 reference.
 
+Completed 2026-08-20. Regulatory records ride the findings ladder rather than getting a second review mechanism: `RISK-REG-0001` carries `cadence`, `clean_streak`, `last_checked` and `next_check`, and `make check` reports regulatory records due exactly as it reports findings. `RISK-WP-0003-T04` closes by reference.
+
 ## Non-goals
 
 - **No dashboard.** `REGISTER.md` and `make check` are the surface, and the