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-0001-flex-auth-unauthenticated-check.md

@@ -2,7 +2,7 @@
 id: RISK-F-0001
 type: finding
 title: "flex-auth /v1/check authenticates no caller"
-status: open
+status: fixed
 reported_by: flex-auth
 reported_via: rapp-postgres
 routed_by: rapp-postgres
@@ -10,21 +10,24 @@ date_reported: "2026-08-17"
 system: flex-auth
 environment: production
 fix_owner: flex-auth
-fix_tracking: FLEX-WP-0015-T02
+fix_tracking: FLEX-WP-0015 (finished 2026-08-19)
 # Graded by risk-nexus 2026-08-19 — docs/rulings/2026-08-19-first-grading.md
-severity: critical
-severity_at_production: critical
+severity: high
+severity_at_production: high
+severity_superseded: "critical (2026-08-19, graded on L3 before reading the inbox)"
 impact: I4
-likelihood: L3
+likelihood: L2
 fidelity_modifier: false
 production_rescore: false
-disclosure: embargoed
-embargo_condition: "FLEX-WP-0015-T02 ships to production"
+disclosure: public
+publication: pending-handover
+embargo_condition: "met 2026-08-19 — FLEX-WP-0015 finished, live probes return 401"
 embargo_since: "2026-08-19"
-embargo_review: "2026-08-26"
-escalation: required
+embargo_review: "2026-08-19"
+escalation: withdrawn
 escalation_trigger: 1
-escalation_status: pending-operator
+escalation_status: withdrawn-before-sending
+date_fixed: "2026-08-19"
 last_reviewed: "2026-08-19"
 review_by: "2026-08-26"
 graded_by: risk-nexus
@@ -153,3 +156,59 @@ Reasoning: `docs/rulings/2026-08-19-first-grading.md`.
 - **2026-08-19** — graded. Next review 2026-08-26 (`critical` → 7 days).
   Open at review: the NetworkPolicy question; whether `FLEX-WP-0015-T02` has
   moved; whether the embargo still holds.
+
+## Re-grade and close — 2026-08-19 (same day)
+
+**Corrected from `critical` to `high`, and closed as `fixed`.** Both changes
+come from messages that were already in this repo's inbox when the first grade
+was set. The register graded before it read them.
+
+**The exposure was narrower than graded.** `flex-auth` answered the
+NetworkPolicy question on 2026-08-18: both production Deployments ship a
+NetworkPolicy in the same manifest, and it is *narrower* than default-deny —
+ingress restricted to one `namespaceSelector` plus one `podSelector` on port
+8080, egress empty. In force since before the period the `A0` describes. So the
+reachable set was never "any pod in the cluster"; it was the single paired
+workload per Deployment.
+
+That is `L2`, not `L3`. Impact stays `I4` — what a forged allow reaches does
+not change — so the grade is `high`. `flex-auth` also corrected their own
+earlier phrasing to `ops-warden` in the same message, unprompted, and that
+correction is why the fact reached this register at all.
+
+Three caveats `flex-auth` asked to be recorded rather than taken from them, and
+they are why the grade did not fall further: label selectors are network
+position, not identity; the policy could not bind the asserted `resource.system`,
+which is what made cross-system impersonation possible; and enforcement depends
+on a CNI they could not verify from a cluster where `kubectl` returned
+`Unauthorized`. They said so rather than letting a manifest stand in for a probe.
+
+**It is fixed.** On 2026-08-19 `flex-auth` reported both production Deployments
+enforcing ADR-0004 TokenReview, with live unbound-request probes returning 401
+rather than a decision, on both the `user-engine` and `tenant-engine` pins.
+`FLEX-WP-0015` is finished and `tenancy.current.A` is 2. That is a probe
+against the running system, which is the standard `docs/method/review.md` sets
+for closing: something concrete read, not something been told.
+
+**Disclosure flips to `public`.** The embargo condition was "FLEX-WP-0015-T02
+ships to production" and it is met. Handover to `policy-nexus` is the next
+step and is not done yet.
+
+**The escalation is withdrawn without being sent.** It was `pending-operator`
+for roughly four hours, and the fix landed first. Withdrawing it is correct —
+escalating a fixed defect makes the operator the queue for history — but the
+register does not get to be pleased about it. The escalation would have been
+sent on facts that were already stale, and only luck put the fix on the same
+day.
+
+**What this cost, recorded because it is the register's own defect.** The
+NetworkPolicy answer arrived 2026-08-18. The fix notice arrived 2026-08-19
+at 12:35. The first grading ran at 21:14 the same day, on neither. Reading the
+inbox is now step 0 of grading and question 0 of every review — see
+`docs/method/review.md` — and this finding is the case that bought it.
+
+## Reviews
+
+- **2026-08-19** — re-graded `high`, closed `fixed`, disclosure `public`,
+  escalation withdrawn. Remaining: handover to `policy-nexus`; the CNI
+  enforcement question is `flex-auth`'s and no longer this finding's.

findings/RISK-F-0002-ops-warden-sign-ungated.md

@@ -20,15 +20,15 @@ likelihood: L2
 fidelity_modifier: false
 production_rescore: false
 constraint_on: RISK-F-0001
-constraint_severity: high
-constraint: "policy.enabled must not be turned on while flex-auth /v1/check answers unauthenticated callers — the gate would sign a false attestation"
+constraint_severity: lifted
+constraint: "LIFTED 2026-08-19 — flex-auth /v1/check now authenticates callers (RISK-F-0001 fixed). Enabling policy.enabled is now an availability question for ops-warden, no longer an attestation hazard."
 disclosure: embargoed
 embargo_condition: "FLEX-WP-0015-T02 shipped and ops-warden policy.enabled true in production"
 embargo_since: "2026-08-19"
 embargo_review: "2026-11-17"
-escalation: required
+escalation: withdrawn
 escalation_trigger: 6
-escalation_status: pending-operator
+escalation_status: withdrawn-hazard-window-closed
 last_reviewed: "2026-08-19"
 review_by: "2026-11-17"
 graded_by: risk-nexus
@@ -193,3 +193,42 @@ Reasoning: `docs/rulings/2026-08-19-first-grading.md`.
 - **2026-08-19** — graded. Next review 2026-11-17 (`medium` → 90 days).
   Open at review: has `FLEX-WP-0007` or `WARDEN-WP-0007` moved; is the stated
   blocker still true; does the ordering constraint still hold.
+
+## Constraint lifted, escalation withdrawn — 2026-08-19 (same day)
+
+`RISK-F-0001` was fixed hours after this register graded it: both `flex-auth`
+production Deployments now enforce ADR-0004 TokenReview, with live
+unbound-request probes returning 401.
+
+**The attestation hazard is gone.** The constraint recorded this morning —
+that enabling `policy.enabled` against a forgeable oracle would write a
+`policy_decision_id` asserting an authorization nobody made — required
+`/v1/check` to answer unauthenticated callers. It no longer does. Enabling the
+gate is now an ordinary availability question for `ops-warden`: does the
+calling side present its ServiceAccount token, and does signing survive a
+`fail_closed: true`. That is `ops-warden`'s sequencing to run, not a risk
+this register holds.
+
+**The trigger-6 escalation is withdrawn.** The hazard window closed before the
+operator was asked to hold the ordering. `ops-warden`'s own judgement that this
+did not need the operator was, in the end, right — and the register still holds
+that it was right for the wrong reason. The disagreement was never about the
+severity of the hazard; it was about whether "written down in both repos"
+keeps a thing held. It did not: the window closed by `flex-auth` shipping, not
+by anyone re-reading the note.
+
+**The finding stays open, unchanged at `medium`.** The gate is still off, and
+`warden sign` still proceeds with no per-request judgement. Nothing about this
+morning's news changes that.
+
+**The general point earns another instance.** This finding argued that a
+blocker is a claim about the world at a date, and that its own blocker had been
+invalidated in a day with nothing re-checking it. That has now happened twice
+to the same finding, in the same week, in the same direction. The second time,
+the thing that had gone stale was this register's own grading, four hours old.
+
+## Reviews
+
+- **2026-08-19** — constraint lifted, escalation withdrawn, severity unchanged.
+  Open at review: has `ops-warden` presented SA tokens and enabled the gate;
+  is `FLEX-WP-0007` still the stated blocker or has it too gone stale.

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.