risk-nexus/workplans/RISK-WP-0001-make-the-register-decidable.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	waiting_on
RISK-WP-0001	workplan	Make the register decidable: severity, disclosure, escalation, expiry	infotech	risk-nexus	finished	the-custodian	risk-nexus	2026-08-19	2026-08-20	who what since would_change default default_at the-custodian register finding / note / regulatory-record as canon work-record kinds, or rule that the register is a different ontology 2026-08-20 C-31 stops being a standing warning; the estate's work-record backbone gains four species it currently cannot name C-31 documented as expected noise for this repo, and the register stops treating it as a gap it can close 2026-09-17

RISK-WP-0001 — make the register decidable

Goal

Give this repo the four instruments it needs to answer a finding, and then answer the three findings already sitting here.

Done means: every open finding carries a severity from a written scale, a disclosure state from a written set, an escalation ruling from a written rule, and a review date that something checks; the register has an index a person can read in one sitting; and RISK-F-0001, RISK-F-0002 and RISK-F-0003 have none of those fields at unset.

The forcing case

Three findings are open. All three were filed correctly by their reporting repos, and all three carry the same block:

# risk-nexus's to set, not the reporter's (INTENT, "What it does not own").
severity: unset
disclosure: unset
escalation: unset

RISK-F-0002 states the ask outright — it names severity, filing shape and escalation as three decisions it is waiting on, and it declines to make them itself. That is the boundary working exactly as INTENT.md describes it. It is also a queue: the reporters have done their half, this repo has not built the half that answers.

This is the failure INTENT.md says the repo must avoid, arriving early and in its mildest form. Findings recorded, nothing decided, converts "we did not know" into "we knew and did nothing" while changing no behaviour. Three findings is the cheapest possible moment to fix it.

What this workplan produces

Four instruments, one index, and one graded register.

Instrument	Answers	Output
Severity scale	how bad, how likely, and what is not a risk at all	docs/method/severity.md
Disclosure states	publish now, hold, or restrict — and the record that a hold was deliberate	docs/method/disclosure.md
Escalation rule	what reaches the operator personally	docs/method/escalation.md
Review and expiry	when a finding must be looked at again, and what happens when it is not	docs/method/review.md
Register index	the whole register, readable at once	REGISTER.md

Each instrument is a governing document of this repo. It is written to be publishable through policy-nexus later; this workplan does not publish it.

Authority

• This repo sets severity, disclosure and escalation. Reporters do not, and the current findings correctly leave them unset.
• Owning repos keep their own account of the defect and its fix. A finding here points at that account; it does not replace it or edit it.
• the-custodian owns the escalation duty. This workplan writes the rule down; adopting it is the custodian's call, and T04 asks for it explicitly.
• Canon is the-custodian's and NetKingdom's. A severity scale is a judgement instrument, not a standard, and must not be written as one.

Non-goals

• No remediation. Not one line of another repo's fix. Findings route.
• No publication. policy-nexus is the surface; this workplan produces documents that could be published, and publishes nothing.
• No blocking gate. In build mode a finding is information. If that ever changes it is a recorded decision, not a side effect of this workplan.
• No tool before the judgement. The scale and the rule are written first and applied by hand to three findings. Automation is T06 and is deliberately the smallest thing that can nag.
• No back-filling the estate. Only findings already filed here, plus the named waiting items in T07. Sweeping every repo for undiscovered risk is not this workplan.

Tasks

T01 — Severity scale

id: RISK-WP-0001-T01
status: done
priority: high

Write the scale: impact bands, likelihood bands, how they combine, and the threshold below which something is a note rather than a register entry.

Constraints it has to satisfy, taken from the findings already here:

• It must be able to score the absence of a control and a control that lies differently. RISK-F-0002 argues the second is worse than the first and asks the register to say which it scored. A scale that cannot express that is not finished.
• It must score against build mode honestly. "No real tenant data yet" is a genuine likelihood input, not an excuse, and the scale must make the production re-score automatic rather than optional.
• It must have a floor. INTENT.md: if a finding would not change anyone's decision, it is a note. Say where that line is.

Output: docs/method/severity.md.

Completed 2026-08-19. docs/method/severity.md: impact I1-I4 x likelihood L1-L4 on a grid, the fidelity modifier (+1 impact band where the failure produces a false record rather than none), the headline-versus-constraint split, the build-mode double grade, and the floor. Amended the same day by T07 — build mode lowers impact as well as likelihood, and non-adversarial findings read likelihood as event probability.

T02 — Disclosure states

id: RISK-WP-0001-T02
status: done
priority: high

Define the disclosure states — at minimum publish-now, embargoed-until-fixed, restricted — with the entry condition for each and what is recorded when a finding is held.

Then revisit the standing deferral. INTENT.md records controlled disclosure as deferred to production, on the reasoning that build mode has no users to expose, and then records that RISK-F-0001 tested that reasoning with a live authorization bypass in the service every other service trusts. The deferral may still be right. It must be re-taken with that case in hand and the reasoning written down, because "publish or hold with nothing in between" is the state RISK-F-0001 is currently sitting in.

Whichever way it goes is a recorded decision, not a habit.

Output: docs/method/disclosure.md, including the re-taken deferral.

Completed 2026-08-19. docs/method/disclosure.md. The deferral was re-taken and narrowed: build-mode default stays publish, the live-and-reachable exception exists now and costs one front-matter field, the mechanism stays deferred as originally reasoned. All seven findings sit at embargoed with observable lift conditions.

T03 — The escalation rule

id: RISK-WP-0001-T03
status: done
priority: high

Write the rule INTENT.md says is not yet written. Settle the five candidate triggers it lists rather than restating them:

1. anything exposing real tenant data;
2. anything creating a legal or regulatory obligation;
3. anything requiring spend;
4. anything where two repos disagree about who owns the fix;
5. any finding whose remediation has stalled past a stated interval.

For each: adopt, drop, or bound it with a number. A trigger with no threshold is not a rule. Say also what escalation is — a message, a conversation, a flagged item — and what the operator is expected to do with one.

Test the draft against the three open findings before calling it done. RISK-F-0002 states its own view (it does not think it needs the operator); the rule must reach an answer there on its own terms, and if it disagrees with the reporter, that disagreement is the useful output.

The custodian adopts the rule. Ask, do not assume.

Output: docs/method/escalation.md.

In progress 2026-08-19. docs/method/escalation.md is written and status: proposed. All five INTENT triggers settled — 1 adopted and bounded, 2 adopted unbounded, 3 bounded at EUR 50/month or EUR 500 one-off, 4 bounded by one failed routing exchange, 5 bounded at twice the review interval — plus trigger 6 (ordering hazard producing a false attestation), added because RISK-F-0002 produced the case. Tested against all seven findings before proposing, and against nine by the time it was adopted. The €50/month and €500 thresholds are now the operator's numbers rather than ours — they bound nothing so far, since the only spend decision taken (RISK-F-0006) was approved without a figure.

T04 — Review dates and expiry

id: RISK-WP-0001-T04
status: done
priority: medium

Every finding gets a review date on entry, set from its severity. Define the intervals, what a review is (re-score, re-check the blocker, re-read the fix owner's account), and what happens when one is missed.

INTENT.md is explicit that a finding sitting untouched past its review date is itself a finding, and RISK-F-0002 supplies the mechanism: a blocker is a claim about the world at a date, its own blocker was invalidated in a day, and nothing would have re-checked it. Overdue review therefore has to produce something — an escalation, a severity bump, a register entry of its own — and this task picks which.

Output: docs/method/review.md; the finding front-matter contract extended with review_by and last_reviewed.

Completed 2026-08-19. docs/method/review.md: 7/30/90/180-day intervals by severity, the four questions a review answers — including RISK-F-0002's "a blocker is a claim about the world at a date" as question 2 — what a missed review produces, the production re-score as an event rather than a date, and the three ways a finding may close.

T05 — Register index

id: RISK-WP-0001-T05
status: done
priority: medium

One REGISTER.md: id, title, system, severity, disclosure, escalation, fix owner, status, review date — one row per finding, newest first.

Generate it from the finding front-matter rather than maintaining it by hand; a hand-maintained index drifts and then lies. Keep the generator small and in this repo (tools/), and keep the output legible: if the table stops being readable in one sitting, that is the "register too large to read" failure arriving, and it is worth a note in the residuals rather than a wider table.

Output: REGISTER.md, its generator, and the front-matter contract the generator relies on written down where a reporter will see it.

Completed 2026-08-19. REGISTER.md, generated by tools/register_index.py from the finding front-matter, with separate Constraints, Embargoes and Notes sections so a lower headline cannot hide a higher constraint. The filing contract is in findings/README.md, where a reporter will meet it. make check fails if the index is stale.

T06 — Grade the three open findings

id: RISK-WP-0001-T06
status: done
priority: high

Apply T01–T04 to RISK-F-0001, RISK-F-0002 and RISK-F-0003. For each: severity with its reasoning, disclosure state, escalation ruling, review date, and confirmation that the fix owner recorded in the file is still the right one.

Two specific questions are already on the table and must be answered here, not deferred:

• RISK-F-0002: peer or consequence? It is filed as a peer of RISK-F-0001 because the fix owner differs, and it offers to be carried as a dependency instead. Rule on it; ops-warden has said it will not re-file either way.
• The sequencing constraint. RISK-F-0002 states that policy.enabled must not flip anywhere while flex-auth's /v1/check answers unauthenticated callers. That is a cross-repo ordering constraint between two open findings, and the register is where it stays visible. Record it as such.

Where grading changes what an owning repo should do, that goes back as a message to that repo, not as an edit in it.

Acceptance: no unset field remains in findings/.

Completed 2026-08-19, in three rounds — the third after reading the inbox, which is recorded in docs/rulings/2026-08-19-third-grading.md as this repo's own defect: RISK-F-0001 was graded critical and escalated while two messages that changed the grade sat unread. Corrected to high and closed fixed the same day; both escalations withdrawn.

docs/rulings/2026-08-19-first-grading.md. RISK-F-0001 critical, embargoed, escalated on trigger 1 — the INTENT question about whether governing access counts as exposure is answered yes. RISK-F-0002 medium today with a high constraint on RISK-F-0001's remediation, filed as a peer, and escalated only on the ordering, against the reporter's own reading. RISK-F-0003 high, embargoed, no escalation. No unset field remains.

T07 — Rule on what is waiting outside the register

id: RISK-WP-0001-T07
status: done
priority: medium

INTENT.md names things visible but unfiled, held back pending the precedent this workplan sets. Now that the floor from T01 exists, rule on each:

• the three further defects surfaced in the same round as RISK-F-0001 and recorded inside it as visible-but-unfiled;
• the unverified tenant boundary — no consumer's tenant boundary is verified anywhere, Broken Object Level Authorization, currently open question 3 in an unratified draft;
• the absent noisy-neighbour characterisation;
• the erasure-versus-audit tension.

Each becomes a finding with a full grade, or a recorded note with the reason it is below the floor. "Still waiting on the precedent" stops being available as an answer once T01 lands.

The last three live in NetKingdom's Tenancy Posture, a draft, and filing them here does not amend it. A finding may say a standard is wrong; it cannot change one.

Completed 2026-08-19. docs/rulings/2026-08-19-second-grading.md. Four filed — RISK-F-0004 (tenant-engine), RISK-F-0005 (audit-core), RISK-F-0006 (apps-pg, escalated on spend), RISK-F-0007 (the unverified tenant boundary, escalated on ownership, fix_owner deliberately unset). Two ruled notes — RISK-N-0001 noisy neighbours, RISK-N-0002 erasure-versus-audit — each with an event to be re-read at rather than a date. Filing RISK-F-0007 does not amend Tenancy Posture.

T08 — Nag

id: RISK-WP-0001-T08
status: done
priority: low

The smallest mechanism that makes silence visible: a check over the register that reports findings past review_by, findings whose fix has not moved in the interval T03 set, and any finding still carrying an unset field.

Report only. It writes nothing, escalates nothing on its own, and blocks nothing. A human or the custodian acts on the output.

Runs from a Makefile target in this repo, in the same shape as the sibling policy-nexus make check.

Completed 2026-08-19. tools/register_check.py behind make check: ungraded fields, overdue reviews, stalls at twice the interval, embargoes overdue for re-decision, escalations awaiting the operator, and what is owed at the production transition. Report only — it writes nothing and changes no field.

Sequencing

T01 first — the floor it sets is what T02, T04, T05 and T07 lean on. T02 and T03 can run in parallel after it; T03 wants a custodian answer and should be raised early so the wait is not on the critical path. T04 after T01. T05 after T04, since the index needs the review fields. T06 after T01–T04. T07 after T01 and T06's precedent. T08 last, after T05.

Do not hold T06 for T07. Grading what is already filed is the point; deciding what else to file is the follow-on.

Risks

The instruments become a standard. A severity scale that reads like canon invites arguments about the scale instead of about the risk. Mitigation: each document states it is this repo's judgement instrument, revisable by this repo, and cites the finding that forced it.

Grading becomes re-investigation. The three findings are well-evidenced by their reporters. Mitigation: T06 scores what is in the file and asks the owner where the file is silent; it does not re-derive the defect.

The escalation rule is written and never adopted. Mitigation: T03 is not done until the custodian has ruled on it. An unadopted rule is worse than an unwritten one, because it looks like coverage.

Automation arrives before judgement and freezes a bad scale. Mitigation: T08 is last, is report-only, and has no authority to change a field.

The register grows past readability while nobody notices. Mitigation: T05 treats index length as a signal, and T07's floor is the instrument that keeps notes out.

Residuals

• Publication handover. RISK-F-0001 (fixed) and RISK-F-0008 (a question, published as a question) are disclosure: public with publication: pending-handover. Handing them to policy-nexus under its publication contract is the first item of the next workplan; nothing in this one publishes.

• Inbox before grading. Added to docs/method/review.md as question zero after this workplan graded RISK-F-0001 critical while its fix notice sat unread. The mechanism is a habit, not a check — if it slips again, the answer is a check in make check against message timestamps, and that is a task, not a residual.

• Publication of these instruments through policy-nexus is a later workplan, and only if T02 concludes anything here should be public.

• Regulatory intake — the second half of this repo's remit — is untouched here. It needs its own workplan and its own retention rule; INTENT.md records that regulation was previously "consulted and discarded", which is a different failure from the one this workplan addresses.

• Routing mechanics between this register and owning repos are done by hand at three findings. If the register reaches a size where hand-routing slips, that is the trigger for a routing workplan, not for widening T08.