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>

notes/RISK-N-0001-noisy-neighbour-uncharacterised.md

@@ -0,0 +1,35 @@
+---
+id: RISK-N-0001
+type: note
+title: "Noisy-neighbour behaviour is uncharacterised"
+date: "2026-08-19"
+source: "NetKingdom Tenancy Posture (draft), open question"
+floor_reason: "no decision changes today — no tenant shares a saturating workload, and what is missing is measurement work, not a defect to route"
+revisit: "when two tenants first share a saturating workload, or at the production transition"
+ruling: RISK-RULING-2026-08-19-B
+---
+
+# RISK-N-0001 — noisy neighbours, uncharacterised
+
+Named in `INTENT.md` as waiting: NetKingdom's *Tenancy Posture* leaves the
+noisy-neighbour behaviour of shared components uncharacterised — how one
+tenant's load degrades another's service is not measured anywhere.
+
+**Ruled a note, not a finding, on 2026-08-19.**
+
+The floor asks two questions. *Could an owner act?* Yes —
+`railiance-platform` could characterise it. *Does recording it change a
+decision?* Today, no. Nothing in the estate currently has two tenants sharing a
+workload heavy enough for the answer to matter, so a register entry would
+change nobody's ordering and would sit there being read past.
+
+What is missing here is measurement, not remediation. That is work someone
+schedules, not a defect the register routes — and the register is explicitly
+not the place where undone work is logged.
+
+It comes back the day two tenants first share a saturating workload, or at the
+production transition, whichever is first. If characterisation then shows one
+tenant can degrade another, that is a finding with a severity, and this note is
+its provenance.
+
+Filed as a note so that "we saw it" survives without inflating the register.

notes/RISK-N-0002-erasure-versus-audit.md

@@ -0,0 +1,38 @@
+---
+id: RISK-N-0002
+type: note
+title: "Erasure duty and audit immutability have not been reconciled"
+date: "2026-08-19"
+source: "NetKingdom Tenancy Posture (draft), open question"
+floor_reason: "no obligation exists yet — the estate holds no real person's data, so there is nothing to erase and no counterparty to owe it to"
+revisit: "on the day the estate first holds a real person's data; belongs to the regulatory-intake workplan, not this one"
+ruling: RISK-RULING-2026-08-19-B
+---
+
+# RISK-N-0002 — erasure versus audit
+
+Named in `INTENT.md` as waiting: an audit trail that must be immutable and an
+erasure obligation that may require destroying what is in it cannot both be
+satisfied naively, and the estate has not reconciled them.
+
+**Ruled a note, not a finding, on 2026-08-19.**
+
+This is a real design tension and it will need a real answer — whether key
+destruction satisfies an erasure obligation is exactly the question
+`INTENT.md` says was researched, used once, and discarded.
+
+It is a note today for one reason: there is no obligation. The estate holds no
+real person's data, so nothing is owed to anyone. Escalation trigger 2 reads
+"creates or reveals an obligation with an outside counterparty", and this
+creates none yet. A finding needs a decision that changes, and today the
+decision is "not yet".
+
+It is also not shaped like this register's work. It is a regulatory question
+first and an architecture question second, and `INTENT.md` puts regulatory
+intake in this repo but keeps "what the estate must therefore do" with the
+owning repo. Reconciling it belongs to the regulatory-intake workplan
+(`RISK-WP-0001` residual), not to finding triage.
+
+It comes back on the day the estate first holds a real person's data. That day
+is also when it stops being a note, because from then on the obligation is real
+and trigger 2 fires.