risk-nexus/workplans/RISK-WP-0004-run-the-register.md

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