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

The inbox round: two grades corrected, one note promoted

Browse source 
Read the repo inbox after grading, which is the wrong order and is now
recorded as such. flex-auth had answered the NetworkPolicy question on
2026-08-18 (narrow ingress, not default-deny — L3 becomes L2, critical
becomes high) and reported RISK-F-0001 fixed at 12:35 today with live 401
probes. F-0001 closes fixed and public; its escalation is withdrawn
before it was ever sent. RISK-F-0002's ordering constraint lifts with it
and its trigger-6 escalation is withdrawn.

audit-core had routed the erasure-versus-audit legal question here on
2026-08-18 asking for an owner. RISK-N-0002 was wrong to call it a note:
the remedy is not retrofittable, so the decision can only be taken early.
Promoted to RISK-F-0008, owned by this repo as regulatory intake,
escalated on trigger 2.

Accepted rapp-postgres's record format and ops-warden's typed-act
escalation vocabulary. Reading the inbox is now question zero of every
review.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-19 23:38:07 +02:00
parent 37906c3a22
commit 7d6ded5743
10 changed files with 431 additions and 67 deletions
Download patch file Download diff file Expand all files Collapse all files

38
notes/RISK-N-0002-erasure-versus-audit.md
View file

@ -1,38 +0,0 @@
---
id: RISK-N-0002
type: note
title: "Erasure duty and audit immutability have not been reconciled"
date: "2026-08-19"
source: "NetKingdom Tenancy Posture (draft), open question"
floor_reason: "no obligation exists yet — the estate holds no real person's data, so there is nothing to erase and no counterparty to owe it to"
revisit: "on the day the estate first holds a real person's data; belongs to the regulatory-intake workplan, not this one"
ruling: RISK-RULING-2026-08-19-B
---
# RISK-N-0002 — erasure versus audit
Named in `INTENT.md` as waiting: an audit trail that must be immutable and an
erasure obligation that may require destroying what is in it cannot both be
satisfied naively, and the estate has not reconciled them.
**Ruled a note, not a finding, on 2026-08-19.**
This is a real design tension and it will need a real answer — whether key
destruction satisfies an erasure obligation is exactly the question
`INTENT.md` says was researched, used once, and discarded.
It is a note today for one reason: there is no obligation. The estate holds no
real person's data, so nothing is owed to anyone. Escalation trigger 2 reads
"creates or reveals an obligation with an outside counterparty", and this
creates none yet. A finding needs a decision that changes, and today the
decision is "not yet".
It is also not shaped like this register's work. It is a regulatory question
first and an architecture question second, and `INTENT.md` puts regulatory
intake in this repo but keeps "what the estate must therefore do" with the
owning repo. Reconciling it belongs to the regulatory-intake workplan
(`RISK-WP-0001` residual), not to finding triage.
It comes back on the day the estate first holds a real person's data. That day
is also when it stops being a note, because from then on the obligation is real
and trigger 2 fires.

34
notes/RISK-N-0003-defects-found-by-reading-not-monitoring.md Normal file
View file

@ -0,0 +1,34 @@
---
id: RISK-N-0003
type: note
title: "Every defect in this register was found by reading, none by monitoring"
date: "2026-08-19"
source: "rapp-postgres, routing RISK-F-0001; restated in RISK-F-0002"
floor_reason: "no owner and no defect — it is an argument about where to invest detection, and the register cannot route an argument"
revisit: "when a finding arrives that monitoring plausibly should have caught and did not"
ruling: RISK-RULING-2026-08-19-C
---
# RISK-N-0003 — found by reading, not by watching
`rapp-postgres` raised it when routing `RISK-F-0001` and left the call here:
all four defects in that round were found by repos reading their own code
against a ladder, within a day of each other, and none by monitoring.
`RISK-F-0002` is a fifth, found by re-reading an answer this estate had just
given. `RISK-F-0003` is a sixth, found while counting fields for a zone model.
**Ruled a note, not a finding, on 2026-08-19.**
It is true, it is worth knowing, and it clears neither floor test cleanly. No
repo owns "the estate's ability to notice its own defects", and there is no
defect to route — the observation is an argument for investing in detection,
and the register that files arguments as findings stops being readable.
There is also a reading of it that is not alarming. Reading code against a
ladder *is* a detection method, it worked six times in a week, and the estate
has been doing it deliberately. What is unproven is whether it would find
anything nobody thought to look at.
It comes back the first time a finding arrives that monitoring plausibly should
have caught and did not. That is the evidence this note is missing, and until
then filing it would be the register asserting a conclusion it cannot support.