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>

docs/method/check-procedure.md

@@ -0,0 +1,87 @@
+---
+id: RISK-METHOD-CHECK
+type: method
+title: "How a check is actually performed"
+status: adopted
+owner: risk-nexus
+adopted: "2026-08-20"
+workplan: RISK-WP-0004-T01
+review_interval: 180d
+---
+
+# Performing a check
+
+The ladder in `docs/method/review.md` says *when*. This says *what*, in order,
+so that a check is repeatable by whoever or whatever is doing it.
+
+A check takes minutes. It is not an investigation, and it is not a re-grading
+unless something moved.
+
+## The order
+
+```
+make check          # what is due, what is malformed, what the inbox has said
+```
+
+Then, per due finding:
+
+0. **Read the inbox first.** `make check` ends with the inbox report; anything
+   it lists is read before that finding is touched. This is step zero because
+   skipping it on 2026-08-19 produced a wrong grade and a nearly-sent
+   escalation.
+1. **Is the grade still right?** Re-read impact and likelihood against what has
+   changed. New facts move grades in both directions.
+2. **Is every stated blocker still true?** A blocker is a claim about the world
+   at a date. Re-check it; do not carry it forward.
+3. **Has the fix moved?** Read the owner's tracking record, not our memory of
+   it. Confirm the record still exists and still refers to this defect.
+4. **Is the disclosure state still right?** A met embargo condition publishes;
+   a condition that has not moved in two checks is a stall — and a condition can
+   be met while the embargo still holds, if a sibling finding would be exposed
+   by publishing (`RISK-F-0003`).
+
+Then record it, in the same sitting:
+
+```
+make checked ARGS="RISK-F-0002 clean"
+make checked ARGS="RISK-F-0002 moved  'ops-warden enabled the gate'"
+make checked ARGS="RISK-F-0002 defer 2026-09-01 'operator: after the migration'"
+make register
+```
+
+`record_check.py` writes the front-matter and the dated line together. **A
+check that is not written down did not happen** — the same rule this register
+applies to every repo it grades.
+
+## What must not happen
+
+**Stamping `clean` without doing the four questions.** It costs nothing, takes
+no time, and produces a `1q` rung that is a lie about stability. That is
+precisely the `RISK-F-0002` failure — a control that produces a false record is
+worse than no control — applied to this register's own instruments.
+
+`clean_streak` exists partly to make that visible: a register where everything
+climbs smoothly and nothing ever resets is either extraordinarily stable or not
+being checked, and those two look identical from the outside.
+
+## Who performs it
+
+Unresolved, and the honest state of `RISK-WP-0004-T01`.
+
+The procedure is executable and the tooling is built. What does not yet exist
+is the thing that runs it on schedule. The options, worst to best:
+
+- **A human habit.** Fails exactly when the operator is busy, which is the
+  condition the ladder was designed for.
+- **A cron that only reports.** Better: the due list arrives whether or not
+  anyone remembers. Still needs someone to act on it.
+- **A scheduled agent session** that runs `make check`, works the due list,
+  performs the four questions, and records outcomes — escalating to the
+  operator only what the escalation rule says to escalate.
+
+The third is the only one that survives the operator being busy. It is also a
+standing commitment of compute, and this register does not get to arm one on
+the operator's behalf. **Awaiting that decision.**
+
+Until it is made, checks happen when someone runs `make check`, and every
+finding sitting at `instant` is telling the truth about how often that is.

docs/regulatory/audit-retention-basis.md

@@ -8,7 +8,10 @@ determined: "2026-08-20"
 finding: RISK-F-0008
 sources_read: "GDPR Arts 5, 6, 17, 21, 32; Recitals 49, 65; HGB §257; AO §147"
 external_review: none
-review_by: "2026-11-17"
+last_checked: "2026-08-20T05:25:00Z"
+next_check: "2026-08-20T05:25:00Z"
+cadence: instant
+clean_streak: 0
 ---
 
 # RISK-REG-0001 — the retention basis, written down

docs/verifications/2026-08-20-user-engine-boundary-request.md

@@ -0,0 +1,58 @@
+---
+id: RISK-V-0002
+type: verification
+title: "Tenant boundary of user-engine — verification requested"
+date: "2026-08-20"
+requested_by: risk-nexus
+requested_of: user-engine
+status: requested
+findings: [RISK-F-0007]
+workplan: RISK-WP-0004-T04
+---
+
+# RISK-V-0002 — user-engine tenant boundary (requested)
+
+The first exercise of the on-request path the operator ruled on 2026-08-19.
+`RISK-F-0007` is `accepted` until production on the strength of that path, and
+a route nobody has walked is a plan rather than a route
+(`RISK-WP-0004-T04`).
+
+## The request
+
+One named boundary: **can a caller acting for tenant A obtain, modify or infer
+data belonging to tenant B through `user-engine`?**
+
+Asked of `user-engine` because they are a consumer with a boundary and are not
+already carrying a finding about one — `tenant-engine` (`RISK-F-0004`) and
+`audit-core` (`RISK-F-0005`) both are, and using them would have tested the
+path against systems already known to fail it.
+
+## What was asked for, and what deliberately was not
+
+Asked: whether anything **verifies** the boundary — a test, an assertion, an
+authorization check on the path — and what would have to be true for the answer
+to be yes.
+
+Not asked: a general security review, a posture ladder self-assessment, or a
+promise. `user-engine` owns the verification; this register scopes and records
+it and verifies nothing itself here.
+
+## What this exercise is really measuring
+
+Whether the path works, and where it rubs. Specifically: does the request reach
+someone who can act on it, is "one named boundary" a question a repo can
+actually answer, and does what comes back constitute evidence or reassurance.
+
+The value is in the friction it exposes, and that gets recorded here whatever
+the answer turns out to be — including if the answer never comes.
+
+## Outcome
+
+Pending. Requested 2026-08-20.
+
+- If the boundary holds with evidence: `RISK-F-0007`'s likelihood falls **for
+  this consumer**, and the record says how it was shown.
+- If it does not: a finding of its own, with `user-engine` as fix owner.
+- If nothing comes back: that is the most useful result of the three, because
+  the estate is currently carrying `RISK-F-0007` on the assumption that asking
+  works.