diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index a44b96a..fc59bce 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -2125,6 +2125,39 @@
   D-NNN. Both are the measure/grep-before-concluding discipline. The next session should treat any
   ovn-central cert hypothesis of mine as UNVERIFIED until measured, and re-derive from the
   captured evidence rather than this narrative.
+  **>>> ROOT-CAUSE RE-EVALUATION 2026-08-03 (successor session; SUPERSEDES the LP #2044324 framing
+  above). Full record: `docs/audit/ovn-central-cert-reeval-20260803.md`. <<<** Fresh live
+  measurement + 3 deployed-source agents + an adversarial review. CORRECTED root cause (MEASURED at
+  every hop): ovn-central derives its cert CN from a REVERSE lookup of its metal-internal address;
+  `get_hostname("10.12.12.122")` returns None because the metal-internal plane has NO reverse-DNS
+  PTRs, so it publishes an EMPTY common_name; vault (by design, provides.py:179) issues a server
+  cert ONLY for a truthy common_name or a cert_requests map, so ovn-central gets client-cert-only and
+  blocks. **LP #2044324 is NO MATCH** (different status string / binding-absent vs -present /
+  inconsistent vs our deterministic); no upstream fix and no channel bump changes the cert-request
+  construction. mysql-innodb-cluster publishes the IDENTICAL CN-less shape, gets the IDENTICAL
+  response, and is healthy (self-signs) -- proving vault's behavior generic, not a bug. `ovn-chassis`
+  works because it OVERRIDES the CN with the OVS hostname. REMEDY (gated, drafted in
+  `docs/audit/ovn-central-cert-remediation-plan-20260803.md`): enable `rdns_mode` on the
+  metal-internal subnet in MAAS so PTRs auto-populate, then re-fire; vault signs any non-empty CN
+  (`allow_any_name=True`), CN content near-irrelevant. Acceptance is NOT "unit active" (false green):
+  require server cert in databag -> /etc/ovn/* written on all 3 -> raft cluster formed -> 6641/6642
+  listening. CORRECTIONS OWNED this re-eval: my interim "metal-admin-only DNS" was wrong
+  (metal-internal is the OUTLIER; 5 of 6 planes have reverse DNS) and my interim "default binding is
+  not the lever" was over-claimed (the CN derives from private-address, which follows the default
+  binding; deploy-time state is UNKNOWN, logs rotated).
+  **>>> STAGE-5 SWEEP FOR OTHER MISSES 2026-08-03. Full record: `docs/audit/stage5-sweep-misses-20260803.md`. <<<**
+  Live census: 55 active / 6 blocked / 4 waiting / 1 unknown / 1 error. THREE unrecorded findings:
+  (F1) metal-internal is the ONLY plane of six without reverse DNS; `phase-00-maas-standup.sh` sets
+  managed/gateway/dns_servers per subnet but NEVER `rdns_mode` -- a tooling gap + Roosevelt-delta
+  (every DC inherits it). (F2) FOUR hacluster subordinates (barbican/designate/magnum/placement)
+  BLOCKED on `res_<svc>_None_ipv6addr_vip not running` -- stale IPv6 VIP pacemaker resources
+  (`2602:f3e2:f02:21::N`, one malformed with nic=None) left over from the pre-D-141 dual-stack
+  deploy while the principals' vip config is now v4-only; SAME incomplete-D-141-transition family as
+  the provider-bundle-check reconcile. (F3) octavia/0 ERROR on certificates-relation-changed is
+  DOWNSTREAM: its hook fails an SSL call to neutron-api's VIP `10.12.4.55:9696`, which presents no
+  server cert (neutron VIP TLS unhealthy, plausibly tied to the OVN outage). F2/F3 being dug into;
+  in-place-vs-redeploy strategy under discussion. SEC-033 noted (relation databag exposes vault's
+  global-client private key to any juju model reader).
   **>>> SESSION CLOSE 2026-08-03 (GA-R4 bookend). Stage 5 remains OPEN; this is a session
   bookend, NOT a stage close. <<<** DEPLOY IS MID-STAGE-5: bundle deployed + mostly converged
   (9 machines started, mysql ONLINE, vault init+unseal+root-CA, ~25 units active, 0 error),