History

tegwick a05ca6822b RISK-WP-0005 finished: the seven gaps closed T01 fix tracking now reads the owner's workplan file and found two findings the register should have known about. T02 incident and external report intake, the latter routed since the address is not ours to create. T03 the production transition defined by what is held rather than what was announced. T04 the README stops claiming a surface. T05 escalation carries a delivery state and is raised once when unacknowledged. T06 checked_by and a heartbeat, so a 1q rung cannot silently mean nobody looked. T07 coverage: 7 of 117 repos have ever appeared in a finding. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-08-21 08:34:30 +02:00
..
README.md	Adaptive check cadence: the interval is earned, not assigned	2026-08-20 07:43:51 +02:00
RISK-F-0001-flex-auth-unauthenticated-check.md	RISK-WP-0005 finished: the seven gaps closed	2026-08-21 08:34:30 +02:00
RISK-F-0002-ops-warden-sign-ungated.md	RISK-WP-0005-T01: read the fix records, and two findings moved	2026-08-21 08:29:38 +02:00
RISK-F-0003-ops-warden-read-boundary-ungraded-lanes.md	RISK-WP-0005 finished: the seven gaps closed	2026-08-21 08:34:30 +02:00
RISK-F-0004-tenant-engine-unfiltered-event-read.md	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +02:00
RISK-F-0005-audit-core-unfiltered-read-path.md	RISK-WP-0005 finished: the seven gaps closed	2026-08-21 08:34:30 +02:00
RISK-F-0006-apps-pg-no-backup-configured.md	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +02:00
RISK-F-0007-unverified-tenant-boundary.md	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +02:00
RISK-F-0008-audit-retention-legal-basis-assumed.md	RISK-F-0008 accepted: no external determination, policy set instead	2026-08-20 23:36:44 +02:00
RISK-F-0009-openbao-deny-set-covers-a-third-of-high-risk-lanes.md	RISK-F-0009: live verification, and a correction to my own count	2026-08-21 00:50:25 +02:00

README.md

Filing a finding

One file per finding: findings/RISK-F-NNNN-<slug>.md, YAML front-matter, then prose.

Ids are allocated by risk-nexus. Take the next id past the highest you can see and file — that is the right thing to do — but if two reporters take the same one, the earlier commit keeps it and the newcomer is renumbered here, with the original id recorded as filed_as. This happened on 2026-08-20 (RISK-F-0009, filed as RISK-F-0004), which is why it is written down. Do not renumber your own finding after filing; the register does it and tells you.

What the reporter fills in

id: RISK-F-0004
type: finding
title: "one line, what is true — not what should be done"
status: open                  # open | fixed | accepted | withdrawn
reported_by: <repo>           # who found it
reported_via: <repo>          # who routed it here, if different
date_reported: "YYYY-MM-DD"
system: <repo>                # the system the defect is in
environment: production       # production | build | both
fix_owner: <repo>             # who owns the fix — never risk-nexus
fix_tracking: <WP-ID or unset>
related: [RISK-F-0001]        # optional

What risk-nexus fills in — leave these out

severity, severity_at_production, impact, likelihood, fidelity_modifier, production_rescore, disclosure, embargo_*, escalation*, constraint*, last_checked, next_check, cadence, clean_streak, graded_by, ruling.

cadence is the check-frequency rung, and it is earned rather than assigned: a clean check climbs one rung (instant → 1h → 8h → 24h → 48h → 96h → 7d → 14d → 1mo → 1q), and anything moving drops it straight back to instant. So the rung on your finding is a public statement about how settled the matter has been — which is why it is not yours to set.

Setting them yourself is not an error to be corrected — it is a boundary this repo would rather keep. The reporter says what is true; this repo says how bad it is and who hears about it (INTENT.md). Leaving them out, or writing unset, both work; the nag reports either way until they are graded.

What makes a good finding here

State exposure only as far as you can support it. "Not established" is a complete answer and grades better than a guess. RISK-F-0001 declining to assume a NetworkPolicy is the model.
Say how it was found. Provenance is a grading input.
Suggest a direction if you have one, marked as a suggestion. The fix is yours; the grade is ours.
A note is fine. If it would not change anyone's decision, it belongs in notes/ — see the floor in docs/method/severity.md.

Asking for a tenant-boundary verification

Separate from filing. The estate carries RISK-F-0007 — no consumer's tenant boundary is verified anywhere — as an accepted risk until production, on the operator's ruling of 2026-08-19, with verification available on request.

Message risk-nexus naming one consumer boundary and what would have to be true of it. The owning repo of that consumer does the verification; this repo scopes and records it and verifies nothing itself. A boundary that holds is evidence; one that does not is a finding with its own owner.

After filing: make check. Then this repo grades it.