risk-nexus/notes/RISK-N-0001-noisy-neighbour-uncharacterised.md
tegwick 4daff5503f 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>
2026-08-19 23:33:08 +02:00

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.