---
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.