tegwick
868f286c0a
Opaque subject ids preferred, agent identifiers where possible, operator credentials only where necessary, and policy decisions tracked to the responsible party so minimising the record does not cost accountability. Zone-level privacy guarantees may raise the floor later (zone-engine). Shrinks the population the legal basis has to cover, and inverts the accrual: each day's records now carry less that would need erasing. The written determination and the trigger list stay outstanding, so the escalation is partially-answered rather than closed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| README.md | ||
| RISK-F-0001-flex-auth-unauthenticated-check.md | ||
| RISK-F-0002-ops-warden-sign-ungated.md | ||
| RISK-F-0003-ops-warden-read-boundary-ungraded-lanes.md | ||
| RISK-F-0004-agent-boundary-policy-covers-a-third-of-high-risk-lanes.md | ||
| RISK-F-0004-tenant-engine-unfiltered-event-read.md | ||
| RISK-F-0005-audit-core-unfiltered-read-path.md | ||
| RISK-F-0006-apps-pg-no-backup-configured.md | ||
| RISK-F-0007-unverified-tenant-boundary.md | ||
| RISK-F-0008-audit-retention-legal-basis-assumed.md | ||
Filing a finding
One file per finding: findings/RISK-F-NNNN-<slug>.md, YAML front-matter,
then prose. Next id is one past the highest here.
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_reviewed, review_by, graded_by,
ruling.
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-0001declining 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 indocs/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.