tegwick
4daff5503f
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>
100 lines
4.8 KiB
Markdown
100 lines
4.8 KiB
Markdown
---
|
|
id: RISK-RULING-2026-08-19-B
|
|
type: ruling
|
|
title: "What was waiting outside the register: four findings, two notes"
|
|
status: recorded
|
|
owner: risk-nexus
|
|
date: "2026-08-19"
|
|
workplan: 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`:
|
|
|
|
1. **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.
|
|
2. **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.
|