diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index 4cd1f84..c579a6f 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -2097,8 +2097,34 @@
   cert failure is `charm-ovn-central` LP #2044324 (server-cert request/response), independent of
   which plane ovn-central lives on. So the D-052 amendment STANDS on architectural grounds and the
   binding is retained. The cert bug is now attacked on its own, against the correct single-plane
-  baseline -- NEXT: bounce the certificates relation to force a fresh exchange (LP #2044324 is
-  "inconsistent"); if that fails, escalate + accept degraded.
+  baseline.
+  **>>> BOUNCE DONE, DID NOT WORK -- DEFERRED TO A NEW SESSION 2026-08-03. <<<** Three remedies
+  now exhausted, ALL deterministic (this is NOT the "inconsistent" race the LP title suggests):
+  (1) vault `reissue-certificates` action; (2) `juju bind ovn-central metal-internal`; (3) full
+  `remove-relation` + `integrate` of `ovn-central:certificates - vault:certificates` (fresh id
+  **certificates:142**, live now). Every one leaves ovn-central with `ca` + `client.cert` only,
+  NO server cert; ovn-central/0-2 still `waiting` "awaiting server certificate data"; OVN NB/SB
+  cluster still not formed, 6641/6642 not listening.
+  **PRECISE DEFECT, for the LP escalation:** post-bind ovn-central/0 publishes to the certificates
+  relation `sans:["10.12.12.122"]`, `private-address`, `ingress-address`, `unit_name` -- **and NO
+  `common_name`.** The tls-certificates interface needs a `common_name` for the provider to sign a
+  SERVER cert; without it vault issues only the global client cert + CA. The missing CN traces to
+  "Skipping ... internal/admin/public, no local address found" -- where charm-ovn-central derives
+  the CN, and it skips all three (**LP #2044324**, deterministic on this multi-space model).
+  **RESUME POINT (next session):** escalate LP #2044324 with the above characterization and DECIDE:
+  accept ovn-central degraded and continue the rest of the deploy (only OVN/tenant-networking is
+  gated; all control-plane services are otherwise up -- 25+ units active), OR try the UNVERIFIED
+  avenue of setting an `os-*-network` config on ovn-central so internal/admin/public resolve and
+  the CN populates (NOT attempted; flagged unverified because my two prior ovn-central root-cause
+  calls this session were both wrong). **LIVE STATE carried forward:** ovn-central `""` default is
+  metal-internal (bundle + live, architecturally correct, STAYS); certificates relation is
+  certificates:142; v4 VIPs live; vault initialised+unsealed+root-CA; mysql cluster ONLINE.
+  **PROCESS-DEFECT NOTE (operator-flagged, owned):** this session I twice asserted an ovn-central
+  root cause the evidence did not support (the binding), and once flagged a binding deviation
+  (openstack-dashboard) that was a ruled exception I'd have applied without grepping the governing
+  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.
   **>>> PRE-VAULT-INIT END STATE REACHED; VAULT PREFLIGHT PASSES `PROCEED` 2026-08-03. <<<**
   After the stall fix, the model converged: `scripts/phase-02-vault-preflight.sh vr1-dc0`
   (staged + sha256-verified on the rack, `90910dfb`) reports **PROCEED** -- mysql cluster 3/3