tegwick 4daff5503f RISK-WP-0001-T07: rule on what was waiting outside the register

Four in as findings — tenant-engine unfiltered event read (high),
audit-core read path bounded by a flag not by code (medium), apps-pg with
no backup at all (high, escalated on spend), and the unverified tenant
boundary itself (high now, critical at production, escalated on
ownership, fix_owner deliberately unset). Two out as notes — noisy
neighbours and erasure-versus-audit, both real, neither changing a
decision this month, both carrying an event to be re-read at.

The round amended the scale twice: build mode lowers impact as well as
likelihood, and non-adversarial findings get their own likelihood
reading. The escalation rule gained a ratio test that distinguishes a
first sweep from steady-state intake, and a batching rule.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-19 23:33:08 +02:00

4.8 KiB

Raw Blame History

id	type	title	status	owner	date	workplan
RISK-RULING-2026-08-19-B	ruling	What was waiting outside the register: four findings, two notes	recorded	risk-nexus	2026-08-19	RISK-WP-0001-T07

What was waiting outside the register — 2026-08-19

INTENT.md named six things as visible but unfiled, held back "pending this repo setting the precedent for what warrants a record of its own". The precedent now exists (docs/method/severity.md), so each is ruled here. "Still waiting on the precedent" is no longer an available answer.

Item	Ruling	Why
`tenant-engine` unfiltered event read	`RISK-F-0004`, high	Live cross-tenant read, owner can act, ordering changes
`audit-core` unfiltered read path	`RISK-F-0005`, medium	Bounded by a deployment flag, not by code
`apps-pg` no backup	`RISK-F-0006`, high, escalated	Unrecoverable loss; needs spend nobody can self-authorise
Unverified tenant boundary	`RISK-F-0007`, high, escalated	Estate-wide, unowned, two confirmed instances
Noisy neighbours uncharacterised	`RISK-N-0001`, note	Measurement work, no decision changes today
Erasure versus audit	`RISK-N-0002`, note	No obligation exists yet; regulatory-intake work

Four in, two out. If everything had cleared the floor, the floor would not be one.

The three from RISK-F-0001's unfiled list

They were recorded inside another finding "so they are visible, not filed as findings, because filing them was not asked for". Filing is now asked for.

Each is filed on the owning repo's own self-report, unverified by this repo, and says so in its own text. risk-nexus reads from everywhere and is downstream by construction; the system remains authoritative about itself. Each owner has been asked to confirm or correct, and two of the three (RISK-F-0004, RISK-F-0006) have fix_tracking: unset, which is a question put to the owner rather than a criticism.

RISK-F-0006 is the surprise of the round. It is the least dramatic item on the list — a missing configuration block — and it grades highest of the three, because it is the only one where nothing comes back afterwards. It also escalates, on spend, which is the trigger that most needed a real case to prove it is not decorative.

The unverified tenant boundary

RISK-F-0007, and the one this register was arguably built to hold. INTENT.md calls it the estate's largest known gap and complains that it lives as open question 3 of an unratified draft, with no owner, no severity and no date. It now has three of the four; fix_owner stays unset deliberately, because the escalation is precisely about who owns it.

Two design points, both deliberate:

It is not a duplicate of RISK-F-0004 and RISK-F-0005. Those are two instances; this is the absence of anything that would have found them. The instances get fixed by their owners and this one does not go away when they do.
It grades high today and critical at production, which is the first real use of production_rescore. Today's consequence is bounded because the estate holds no real tenant data. That bound is a fact about the calendar, so it belongs in the build-mode column and not in a comfortable headline.

What the notes are for

RISK-N-0001 and RISK-N-0002 are the floor doing its job: both are real, both are known, neither changes a decision this month. The note keeps "we saw it" without inflating a register that has to stay small enough to read.

Both carry a revisit condition that is an event rather than a date, and both events are ones the estate cannot miss — two tenants sharing a saturating workload, and the first real person's data. Neither note is a promise to remember; both are promises to be re-read when the condition arrives.

What this round did to the instruments

Two amendments, both dated in docs/method/severity.md:

Build mode lowers impact as well as likelihood. The original text said it was a likelihood input and never an impact one. RISK-F-0007 broke that in one sentence: what build mode changes for an unverified boundary is the consequence of an occurrence, not the reach of it. Corrected rather than worked around.
Non-adversarial findings get their own likelihood reading. RISK-F-0006 has no attacker in it, and reading likelihood as "reach" produced nonsense. Likelihood there is the chance of the triggering event inside one review interval.

An instrument that survives its first hard use unchanged has probably not been used hard.

Register size

Seven findings, six open, two notes. INTENT.md requires the register stay small enough to read, and REGISTER.md is still one screen. The next thing that would break it is a batch — a review round producing ten entries at once. When that happens the answer is a harder floor, not a wider table.

4.8 KiB Raw Blame History