History

tegwick d5147bfaea Typed, dated, defaulted waits — and cut the four-hop chain The register had nine waits in four days, one four hops deep: F-0003's embargo waited on F-0009, which waited on railiance-platform, which waited on live OpenBao verification, which waited on a credential nobody has. No single link was wrong, which is why it needed a rule. docs/method/dependencies.md: the register never waits to decide, it decides and revises. Every wait carries who, what, since, what it would change, what happens if nobody answers, and the date that default applies. Depth one — a record never waits on a record that is itself waiting. Defaults are dates and are pessimistic: silence costs the grade the evidence supports rather than buying a softer one, and owners are told the default in advance because a default nobody was warned about is an ambush. Applied: F-0009's embargo now lifts on railiance-platform reporting coverage, with live verification as a refinement rather than a condition, cutting the F-0003 chain from four hops to two. All eight open waits are typed with defaults. make check reports them with age, owner and default date, flags defaults come due, and catches depth-two violations. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-08-20 22:34:56 +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	Adaptive check cadence: the interval is earned, not assigned	2026-08-20 07:43:51 +02:00
RISK-F-0002-ops-warden-sign-ungated.md	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +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	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +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	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +02:00
RISK-F-0009-openbao-deny-set-covers-a-third-of-high-risk-lanes.md	Typed, dated, defaulted waits — and cut the four-hop chain	2026-08-20 22:34:56 +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.