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>
1.8 KiB
| id | type | title | date | source | floor_reason | revisit | ruling |
|---|---|---|---|---|---|---|---|
| RISK-N-0002 | note | Erasure duty and audit immutability have not been reconciled | 2026-08-19 | NetKingdom Tenancy Posture (draft), open question | 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 | on the day the estate first holds a real person's data; belongs to the regulatory-intake workplan, not this one | 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.