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.