History

tegwick ba3b3f686d RISK-WP-0005-T01: read the fix records, and two findings moved fix_tracker.py resolves fix_tracking against the owning repo's workplan file — the ADR-001 source of truth — and uses the file's last commit date as the honest answer to 'has this moved', independent of whether the register looked. Archived workplans are searched too, so a finished fix that was filed away does not read as missing. First run, three findings it should have known about: RISK-F-0005 — AUDIT-WP-0008-T04 has read done since 2026-08-18. The fix this finding asked for has landed and the register spent three days not knowing. Now mitigated, embargo lifted, disclosure public. Not fixed: that needs a probe, and T05's adversarial evidence artifact still reads wait. RISK-F-0002 — both tracked records were closed before the finding was filed: WARDEN-WP-0007 archived 2026-07-08, FLEX-WP-0007 finished 2026-06-29, against a finding of 2026-08-18 that names FLEX-WP-0007 as the blocker. Routed as a question, not a conclusion. Four findings carry no fix tracking at all, which the report now says out loud rather than leaving as an empty field. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-08-21 08:29:38 +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	Type the publication handover as a wait like any other	2026-08-20 22:44:46 +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	Work the register due list, and add the one-check-per-sitting rule	2026-08-20 12:03:12 +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-T01: read the fix records, and two findings moved	2026-08-21 08:29:38 +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.