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>
1.6 KiB
| id | type | title | date | source | floor_reason | revisit | ruling |
|---|---|---|---|---|---|---|---|
| RISK-N-0001 | note | Noisy-neighbour behaviour is uncharacterised | 2026-08-19 | NetKingdom Tenancy Posture (draft), open question | no decision changes today — no tenant shares a saturating workload, and what is missing is measurement work, not a defect to route | when two tenants first share a saturating workload, or at the production transition | 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.