tegwick
a05ca6822b
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>
115 lines
4.8 KiB
Markdown
115 lines
4.8 KiB
Markdown
---
|
|
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:
|
|
|
|
```
|
|
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.
|