risk-nexus/docs/method/check-procedure.md
tegwick a05ca6822b RISK-WP-0005 finished: the seven gaps closed
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>
2026-08-21 08:34:30 +02:00

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:

  1. 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.
  2. Is the grade still right? Re-read impact and likelihood against what has changed. New facts move grades in both directions.
  3. 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.
  4. 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.
  5. 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.