coulomb/risk-nexus
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
risk-nexus/docs/method/check-procedure.md
tegwick 36b707f0c3 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>
2026-08-20 08:49:23 +02:00

3.5 KiB
Raw Blame History

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:

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.