diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index 7d93f34..efcbf9d 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -2076,7 +2076,20 @@
   governing D-NNN; caught by reading the in-bundle comment before applying. Five flags verified
   NON-issues (D-072 dashboard; octavia:ovsdb-cms dangling; ceph-radosgw gateway endpoints). **ONLY
   ovn-central changes.** APPLIED to `bundle.yaml` (default -> metal-internal, provider-bundle-check
-  PASS); NEXT: re-stage + live `juju bind ovn-central`, verify server cert + OVN cluster forms.
+  PASS) AND live (`juju bind ovn-central metal-internal`, EXIT 0; bundle re-staged).
+  **>>> THE FIX DID NOT WORK, AND MY ROOT-CAUSE HYPOTHESIS WAS WRONG. OWNED. <<<** Post-bind
+  (20:49-20:50) ovn-central re-ran its cert handler and the SAME skip warnings persist --
+  "Skipping request for certificate for ip in internal/admin/public space, no local address
+  found" -- vault still issues only ca + client.cert, no server cert, ovn-central still
+  "awaiting server certificate data". Moving the default binding to metal-internal did NOT make
+  internal/admin/public resolve: those endpoint spaces are NOT tied to the default binding (they
+  need `os-*-network` config or dedicated bindings ovn-central lacks). So default-on-metal-admin
+  was NOT the cause; the real fault is the server-cert request/response itself (the core of
+  LP #2044324), which the binding does not touch. **The D-052 amendment ruling was taken on a
+  wrong premise I supplied.** Keep-or-revert the ovn-central binding is now an open operator call
+  (harmless either way -- ovn-central was already broken). The actual cert remedy is unresolved:
+  candidates are bounce ovn-central units; investigate the server-cert request format vs the vault
+  charm; escalate LP #2044324 / accept degraded. AWAITING OPERATOR DIRECTION.
   **>>> 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