T01 fix tracking now reads the owner's workplan file and found two findings the register should have known about. T02 incident and external report intake, the latter routed since the address is not ours to create. T03 the production transition defined by what is held rather than what was announced. T04 the README stops claiming a surface. T05 escalation carries a delivery state and is raised once when unacknowledged. T06 checked_by and a heartbeat, so a 1q rung cannot silently mean nobody looked. T07 coverage: 7 of 117 repos have ever appeared in a finding. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.8 KiB
| id | type | title | status | owner | adopted | workplan | review_interval |
|---|---|---|---|---|---|---|---|
| RISK-METHOD-CHECK | method | How a check is actually performed | adopted | risk-nexus | 2026-08-20 | RISK-WP-0004-T01 | 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:
- Read the inbox first.
make checkends 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. - Is the grade still right? Re-read impact and likelihood against what has changed. New facts move grades in both directions.
- 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.
- 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.
- 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:
RISK_CHECKED_BY=<who-or-what-you-are> \
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.
One check per sitting
A finding you recorded as moved is not clean-checked in the same sitting.
The ladder says instant means "now, and again immediately until a check comes
back clean". The temptation is to record the movement, re-read what you just
wrote, find it consistent, and climb — which produces a 1h rung seconds after
a change, on the evidence of your own keystrokes.
That is self-certification, and the rung is supposed to carry information about
how long the world has held still, not about how quickly the register can agree
with itself. A finding that moved stays at instant until a later pass finds
nothing new. It costs one extra check and it keeps the signal honest.
Applied on 2026-08-20: RISK-F-0002, RISK-F-0007 and RISK-F-0008 all moved
and were left due rather than climbed.
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 was chosen by the operator on 2026-08-20 and is built on
activity-core:
| Definition | When | Fires |
|---|---|---|
hourly-register-inbox-watch |
hourly, :05 Berlin | only when an unread message waits for risk-nexus |
daily-register-check-sweep |
daily, 07:15 Berlin | unconditionally — the floor |
Hourly is the finest granularity worth having, because the ladder's shortest rung is one hour and anything faster reports work that cannot be due yet.
What the schedule does and does not do. It makes sure somebody looks. It
does not grade, close, publish, escalate or record an outcome — those stay with
whoever or whatever performs the check, exercising the judgement above. An
activity that could stamp clean on its own would be manufacturing the
stability signal the ladder exists to carry.