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/severity.md

@@ -108,15 +108,37 @@ Every finding is graded twice:
 - `severity_at_production` — the same impact, with likelihood re-read for a
   system carrying real users and real tenant data.
 
-Build mode is a legitimate likelihood input. "No consumer holds real data
-here yet" genuinely lowers reach. It is *not* an impact input: what the defect
-would do on the day it is exercised does not change because the calendar has
-not reached production.
+Build mode legitimately lowers **both** axes, for different reasons:
+likelihood, where the reach itself depends on a production deployment that has
+not happened; and impact, where the data that would be exposed does not exist
+yet. What it must never lower is `severity_at_production` — the defect does
+not improve because the calendar has not reached it.
+
+> *Amended 2026-08-19 (`RISK-WP-0001-T07`).* This paragraph originally said
+> build mode was a likelihood input and never an impact one. Grading the
+> unverified tenant boundary broke that: what build mode changes there is the
+> consequence of an occurrence, not the reach of it. The instrument was wrong
+> on first hard use and is corrected rather than worked around.
 
 Where the two grades differ, the production transition is a mandatory
 re-score. `docs/method/review.md` binds the review date to it, so the re-score
 is a scheduled event and not somebody's memory.
 
+## Non-adversarial findings
+
+Likelihood is written as reach because most findings are about someone getting
+somewhere. Where a finding is about loss, corruption or outage — no backup, no
+recovery path, an eviction-prone deployment — there is no attacker to model.
+
+For those, likelihood reads as **the chance of the triggering event inside one
+review interval**: `L1` would be surprising, `L2` is an ordinary failure the
+estate has seen before, `L3` is expected in the normal course of running,
+`L4` is already happening. Impact is unchanged: what is lost, and whether it
+comes back.
+
+> *Added 2026-08-19 (`RISK-WP-0001-T07`).* Forced by `RISK-F-0006`, where the
+> defect is an absent backup and the reach reading produced nonsense.
+
 ## The floor
 
 `INTENT.md`: if a finding would not change anyone's decision, it is a note,