coulomb/risk-nexus
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

RISK-WP-0001-T07: rule on what was waiting outside the register

Browse source 
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>
This commit is contained in:
tegwick 2026-08-19 23:33:08 +02:00
parent d5a3953f2e
commit 4daff5503f
10 changed files with 612 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

35
notes/RISK-N-0001-noisy-neighbour-uncharacterised.md Normal file
View file

@ -0,0 +1,35 @@
---
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.