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>
This commit is contained in:
parent
97fcc56a4d
commit
36b707f0c3
10 changed files with 296 additions and 9 deletions
87
docs/method/check-procedure.md
Normal file
87
docs/method/check-procedure.md
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue