risk-nexus/docs/method/check-procedure.md

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:

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 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.