tegwick
4daff5503f
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>
35 lines
1.6 KiB
Markdown
35 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.
|