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>

docs/method/escalation.md

@@ -134,15 +134,48 @@ Stated so the rule bites in both directions.
 
 ## Testing the rule against the register
 
-The draft was tested against all three open findings before it was proposed;
-the rulings are in `docs/rulings/2026-08-19-first-grading.md`.
+The draft was tested against the first three findings before it was proposed
+(`docs/rulings/2026-08-19-first-grading.md`) and then against the four filed
+out of the backlog the same day
+(`docs/rulings/2026-08-19-second-grading.md`).
 
-Summary: `RISK-F-0001` escalates on trigger 1. `RISK-F-0002` does not escalate
-on triggers 1-5 — agreeing with the reporter's own reading — but the
-`RISK-F-0001`/`RISK-F-0002` ordering constraint escalates once on trigger 6,
-which is the disagreement the rule was worth writing to surface. `RISK-F-0003`
-does not escalate; it is known, owned, tracked, and moving.
+| Finding | Escalates | Trigger |
+| --- | --- | --- |
+| `RISK-F-0001` flex-auth oracle | yes | 1 — governs access to tenant data |
+| `RISK-F-0002` signing gate off | yes, once | 6 — ordering hazard, jointly with `RISK-F-0001` |
+| `RISK-F-0003` ungraded lanes | no | known, owned, tracked, moving |
+| `RISK-F-0004` tenant-engine reads | no | no real tenant data yet |
+| `RISK-F-0005` audit-core reads | no | known, owned, tracked, moving |
+| `RISK-F-0006` apps-pg no backup | yes | 3 — recurring spend nobody can self-authorise |
+| `RISK-F-0007` unverified boundary | yes | 4 — estate-wide and unowned |
 
-One escalation, covering two findings, out of three findings. That ratio is
-the rule doing its job. If it ever reaches "most findings", the rule is wrong,
-not the register.
+`RISK-F-0002` is the case worth reading: `ops-warden` judged it did not need
+the operator, the register agrees on triggers 1-5, and it escalates anyway on
+6. That disagreement is the reason the rule was worth writing down.
+
+## The ratio, and what it would mean
+
+Four of seven escalate. That is more than this rule should produce in steady
+state, and it is not evidence the rule is loose — it is what a **first sweep**
+looks like. Three of the four are the backlog: items that sat outside the
+register precisely because nobody had decided them, and undecided items are
+exactly the population that needs the person who can decide.
+
+The test therefore applies to intake, not to sweeps:
+
+> If more than one in three **newly reported** findings escalates over any
+> rolling ninety days, the rule is wrong, not the register.
+
+If that trips, the first suspects are triggers 3 and 4 — spend thresholds set
+too low, and "unowned" being read where "not yet routed" is meant.
+
+## Escalations are batched
+
+Four escalations are one conversation, not four interruptions. Open items go
+to the operator together, in register order, each with its own decision and
+its own default-if-no-answer. Escalating is not the same as escalating
+separately, and a rule that produces four messages in an afternoon has made the
+operator the queue by a different route.
+
+`make check` lists everything awaiting an answer, so the batch is a report and
+not somebody's recollection.