The inbox round: two grades corrected, one note promoted

Read the repo inbox after grading, which is the wrong order and is now
recorded as such. flex-auth had answered the NetworkPolicy question on
2026-08-18 (narrow ingress, not default-deny — L3 becomes L2, critical
becomes high) and reported RISK-F-0001 fixed at 12:35 today with live 401
probes. F-0001 closes fixed and public; its escalation is withdrawn
before it was ever sent. RISK-F-0002's ordering constraint lifts with it
and its trigger-6 escalation is withdrawn.

audit-core had routed the erasure-versus-audit legal question here on
2026-08-18 asking for an owner. RISK-N-0002 was wrong to call it a note:
the remedy is not retrofittable, so the decision can only be taken early.
Promoted to RISK-F-0008, owned by this repo as regulatory intake,
escalated on trigger 2.

Accepted rapp-postgres's record format and ops-warden's typed-act
escalation vocabulary. Reading the inbox is now question zero of every
review.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

findings/RISK-F-0008-audit-retention-legal-basis-assumed.md

@@ -0,0 +1,128 @@
+---
+id: RISK-F-0008
+type: finding
+title: "The legal basis for retaining audit facts against an erasure request has been assumed, never established"
+status: open
+reported_by: audit-core
+reported_via: audit-core
+routed_by: audit-core
+date_reported: "2026-08-18"
+date_filed: "2026-08-19"
+system: audit-core
+environment: production
+fix_owner: risk-nexus
+fix_tracking: unset
+related: [RISK-F-0005]
+supersedes: RISK-N-0002
+# Graded by risk-nexus 2026-08-19 — docs/rulings/2026-08-19-third-grading.md
+severity: medium
+severity_at_production: high
+impact: I3
+likelihood: L2
+fidelity_modifier: false
+production_rescore: true
+disclosure: public
+publication: pending-handover
+escalation: required
+escalation_trigger: 2
+escalation_status: pending-operator
+last_reviewed: "2026-08-19"
+review_by: "2026-11-17"
+graded_by: risk-nexus
+ruling: RISK-RULING-2026-08-19-C
+---
+
+# RISK-F-0008 — the exemption nobody has established
+
+## What is true
+
+`audit-core` holds audit evidence across tenants, targets `R2` on the Tenancy
+Posture retention ladder, and has declared `R4` — verified erasure —
+unreachable by design. The technical reasoning is sound and documented
+(`audit-core/docs/erasure-and-audit.md`, framework Decision 4.5.3):
+crypto-shredding would destroy the evidence the service exists to hold, and
+their integrity chain commits to a SHA-256 of the cleartext record, which
+survives key destruction as a confirmation oracle against low-entropy audit
+rows. Destroying a key does not erase content a surviving commitment can still
+be tested against.
+
+The consequence is that if an Article 17 request arrives naming a data subject
+in the audit trail, `audit-core` has no mechanism. The answer would rest on
+audit evidence being exempt — legal obligation, or legitimate interest in fraud
+and security investigation.
+
+**Those grounds are ordinary. Nobody in this estate has actually reached them.**
+`audit-core` routed the question here on 2026-08-18 rather than absorbing it,
+saying plainly that they are not competent to answer it and that they have been
+assuming it. §19.11 of the framework says the same in its own words: the legal
+basis for retaining audit facts remains a risk/legal question outside the
+framework.
+
+## Why this repo owns it
+
+This is the first finding where `fix_owner` is `risk-nexus`.
+
+`INTENT.md` moved regulatory intake here from `policy-nexus` on 2026-08-17,
+precisely because deciding what a rule demands of us is a judgement about risk
+rather than an act of publishing. `audit-core` routed it by both available
+routes and asked for an owner rather than an opinion. Refusing it would be this
+repo declining its own remit.
+
+What this repo owns is the **record**: what the source says, when, and what
+therefore is or is not established. It does not own legal advice — `INTENT.md`
+is explicit — and it does not own the redesign. If the basis does not hold,
+`audit-core` owns encrypt-then-hash at accept time, and that is not
+retrofittable onto events already accepted.
+
+## The three questions, as asked
+
+1. On what basis does the estate retain personal data inside audit records
+   against an erasure request, and does that basis hold for the categories
+   `audit-core` stores?
+2. Does it hold across the full 30-day recoverable window and beyond, given
+   that at `P1` the real erasure horizon is the maximum across every
+   co-resident on `platform-pg`, not the value `audit-core` declares?
+3. If it does not hold, `R4` is urgent rather than theoretical, and the answer
+   is a substantial redesign with a long lead time.
+
+## Register ruling — 2026-08-19
+
+`medium` today (`I3` × `L2`), `high` at production, `public`, **escalated on
+trigger 2**.
+
+`I3`: an unmet retention obligation in the audit store crosses from a technical
+question to an obligation with an outside counterparty, and the remediation is
+a non-retrofittable redesign rather than a patch. `L2`: no request has arrived
+and the estate holds no real data subject's records yet, but the trigger is
+somebody else's to pull and needs no foothold here.
+
+`production_rescore: true`. The likelihood of an Article 17 request is a
+function of having real users; that is exactly what production means.
+
+**Escalation, trigger 2** — "creates or reveals an obligation with an outside
+counterparty". It reveals one. The estate cannot decide unilaterally that this
+obligation is small, and the operator is the only party who can commission an
+answer that is more than an assumption. The ask is narrow: authorise someone to
+establish the basis, or record that the estate knowingly runs on the assumption
+and for how long.
+
+**Disclosure `public`.** Nothing here shortens a path to a defect: it is a
+question about a legal basis, published as a question. `audit-core`'s technical
+reasoning is already written down and worth reading.
+
+## How it got here
+
+Ruled a note on 2026-08-19 (`RISK-N-0002`) on the reasoning that no obligation
+exists yet. That ruling was made without reading `audit-core`'s message, which
+had been in this repo's inbox since 2026-08-18 and asks specifically for an
+owner. The note was wrong on the second floor test: recording this *does*
+change a decision, because the redesign it might force cannot be retrofitted
+and therefore has to be decided early or not at all.
+
+`RISK-N-0002` is superseded by this record.
+
+## Reviews
+
+- **2026-08-19** — promoted from note, graded, escalated. Open at review:
+  has the basis been established or the assumption recorded; has anything
+  changed about what categories `audit-core` stores.