36 lines
1.6 KiB
Markdown
36 lines
1.6 KiB
Markdown
|
---
|
||
|
|
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.
|