Draft RISK-WP-0002, RISK-WP-0003, RISK-WP-0004
Publication handover (two findings ready, three tasks, one of which is a paragraph); regulatory intake as a working remit rather than one record, carrying RISK-REG-0001's open items; and running the register, where every task traces to something that actually went wrong in week one — grading before reading the inbox, a status the tooling did not know, an id collision, two gradings resting on file comparison because a token expired, and an on-request path nobody has walked. All three are status: proposed. The custodian decides which become active and in what order. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
a1961a8f6f
commit
a798a4c771
3 changed files with 404 additions and 0 deletions
169
workplans/RISK-WP-0004-run-the-register.md
Normal file
169
workplans/RISK-WP-0004-run-the-register.md
Normal file
|
|
@ -0,0 +1,169 @@
|
|||
---
|
||||
id: RISK-WP-0004
|
||||
type: workplan
|
||||
title: "Run the register: make the cadence actually happen, and close the gaps the first week found"
|
||||
domain: infotech
|
||||
repo: risk-nexus
|
||||
status: proposed
|
||||
owner: the-custodian
|
||||
topic_slug: risk-nexus
|
||||
created: "2026-08-20"
|
||||
updated: "2026-08-20"
|
||||
depends_on_workplans:
|
||||
- RISK-WP-0001
|
||||
---
|
||||
|
||||
# RISK-WP-0004 — run the register
|
||||
|
||||
**Draft.** `RISK-WP-0001` built the instruments. This one is about the register
|
||||
being *operated*, which is a different thing and the one that fails quietly.
|
||||
|
||||
## Goal
|
||||
|
||||
Nine findings, two notes, a regulatory record and an adaptive cadence exist.
|
||||
**Nothing currently performs a check.** `make check` says what is due; a person
|
||||
or an agent has to read the finding, ask the five questions, and record the
|
||||
outcome. If that does not happen, every finding sits at `instant` forever and
|
||||
the ladder becomes decoration.
|
||||
|
||||
Done means: checks happen on their own schedule without the operator
|
||||
remembering, the register's own known gaps are closed, and the failure modes
|
||||
found in the first week cannot recur silently.
|
||||
|
||||
## What the first week actually found
|
||||
|
||||
Every task below traces to something that happened, not something imagined.
|
||||
|
||||
| What happened | Task |
|
||||
| --- | --- |
|
||||
| Graded `RISK-F-0001` `critical` while its fix notice sat unread in the inbox | T02 |
|
||||
| `RISK-F-0003` returned as `mitigated`, a word the tooling did not know, and vanished from the nag | fixed ad hoc; T03 generalises it |
|
||||
| `ops-warden` and this register both used `RISK-F-0004` | fixed ad hoc; duplicate check now in `make check` |
|
||||
| Two gradings rest on file comparison because an operator token is expired | T05 |
|
||||
| `RISK-F-0007` accepted with an on-request path nobody has exercised | T04 |
|
||||
|
||||
## Tasks
|
||||
|
||||
### T01 — Something performs the checks
|
||||
|
||||
```task
|
||||
id: RISK-WP-0004-T01
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
`tools/record_check.py` moves a finding along the ladder and writes the dated
|
||||
line. What is missing is the thing that *calls* it on schedule.
|
||||
|
||||
Options, in ascending order of how much this repo should want them: a scheduled
|
||||
agent session that runs `make check`, works the due list, and records outcomes;
|
||||
a cron that only reports; a human habit. The first is the only one that
|
||||
survives the operator being busy, which is the condition the whole ladder is
|
||||
designed for.
|
||||
|
||||
Whatever it is, the check must remain a **judgement** — re-read the grade,
|
||||
re-check every stated blocker, read the owner's tracking record. A job that
|
||||
stamps `clean` without doing that is worse than no job, because it manufactures
|
||||
a stability signal that is false. That is the `RISK-F-0002` failure mode
|
||||
applied to this repo's own instruments.
|
||||
|
||||
### T02 — Inbox before grading, as a check rather than a habit
|
||||
|
||||
```task
|
||||
id: RISK-WP-0004-T02
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
`RISK-WP-0001`'s residual says: if it slips again, make it a check. It has
|
||||
slipped once, on the register's first day, and cost a wrong grade and a nearly
|
||||
sent escalation.
|
||||
|
||||
`make check` should compare each finding's `last_checked` against the newest
|
||||
message this repo has received about that system, and report any finding whose
|
||||
inbox has spoken more recently than its register has. That is mechanical and
|
||||
does not require the tooling to understand the message.
|
||||
|
||||
### T03 — Fail loud everywhere else too
|
||||
|
||||
```task
|
||||
id: RISK-WP-0004-T03
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
The `mitigated` defect was one instance of a class: the tooling quietly
|
||||
tolerating something it did not expect. Sweep for the rest — unknown disclosure
|
||||
states, unparseable dates, a `constraint_on` pointing at a finding that does
|
||||
not exist, an `embargo_condition` on a finding that is not embargoed.
|
||||
|
||||
Every one of them should be reported by name and keep the finding watched.
|
||||
|
||||
### T04 — Exercise the on-request verification path once
|
||||
|
||||
```task
|
||||
id: RISK-WP-0004-T04
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
`RISK-F-0007` is accepted until production on the strength of a path nobody has
|
||||
used. A route that has never been walked is a plan, not a route.
|
||||
|
||||
Pick one named consumer boundary, request verification through the documented
|
||||
path, and see what actually happens: who answers, what evidence comes back,
|
||||
whether the finding's likelihood moves for that consumer, and what the record
|
||||
looks like. The value is in the friction it exposes.
|
||||
|
||||
### T05 — The verification credential
|
||||
|
||||
```task
|
||||
id: RISK-WP-0004-T05
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
`RISK-F-0009` and `RISK-F-0003`'s mitigation both rest on comparing files
|
||||
because `ops-warden`'s operator token is expired and `bao policy read` cannot
|
||||
be run.
|
||||
|
||||
That is not a finding — nothing is wrong with the estate because a token
|
||||
expired — but it means the register is grading deployed controls from their
|
||||
source. Establish what this repo can legitimately verify itself, and what it
|
||||
must always take from owners. **If the answer is "nothing", that is worth
|
||||
knowing and writing down**, because it bounds every grade in the register.
|
||||
|
||||
### T06 — Regulatory records on the same ladder
|
||||
|
||||
```task
|
||||
id: RISK-WP-0004-T06
|
||||
status: todo
|
||||
priority: low
|
||||
```
|
||||
|
||||
Duplicate of `RISK-WP-0003-T04`, kept here as a pointer rather than a second
|
||||
copy. Whichever workplan reaches it first does it; the other closes with a
|
||||
reference.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- **No dashboard.** `REGISTER.md` and `make check` are the surface, and the
|
||||
register is supposed to stay small enough to read.
|
||||
- **No automated grading.** A machine may schedule, list and record. Severity,
|
||||
disclosure and escalation stay judgements this repo makes.
|
||||
- **No monitoring of other systems.** `RISK-N-0003` records that everything
|
||||
here was found by reading rather than watching; this workplan does not
|
||||
attempt to change that, and a register that grows probes becomes a second
|
||||
engineering team.
|
||||
|
||||
## Risks
|
||||
|
||||
**A scheduled check becomes a rubber stamp.** The whole value of the ladder is
|
||||
that a `1q` rung means something. Mitigation: T01 treats stamping without
|
||||
judgement as a defect, and `clean_streak` makes a suspiciously smooth climb
|
||||
visible.
|
||||
|
||||
**The register spends its attention on itself.** Six tasks about the register's
|
||||
own machinery, none of which fix a defect in the estate. Mitigation: T01, T02
|
||||
and T05 all exist because the register got something wrong in week one; if
|
||||
week two produces no such items, this workplan should shrink rather than grow.
|
||||
Loading…
Add table
Add a link
Reference in a new issue