tegwick
5b9a0e98fe
Two activity definitions, in the shape activity-core's own definitions use. hourly-register-inbox-watch fires only when an unread message waits for risk-nexus — the inbox is the trigger rather than the clock, because an unread message is by construction a claim that something may have moved, and 2026-08-19 proved the register will otherwise grade without looking. daily-register-check-sweep is the unconditional floor at 07:15. Both emit an instruction to a session that can exercise judgement, and both say in their own text that they must never grow the ability to record an outcome: stamping clean without doing the five questions produces a 1q rung that is a lie about stability. RISK-WP-0004 is finished. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
97 lines
3.9 KiB
Markdown
97 lines
3.9 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:
|
|
|
|
```
|
|
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.
|