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