diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index efcbf9d..4cd1f84 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -2085,11 +2085,20 @@
   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.
+  LP #2044324), which the binding does not touch. **CORRECTED FRAMING (operator, 2026-08-03): the binding change is ARCHITECTURALLY
+  CORRECT and STAYS -- it is NOT a wrong ruling.** By the plane's intended purpose ovn-central IS
+  a metal-internal service: D-052 explicitly categorizes "OVN NB/SB DB (ovsdb*)" under
+  metal-internal, ovn-central has NO public or admin API endpoint (nothing it legitimately serves
+  on metal-admin), and all its functional endpoints (ovsdb*, certificates, coordinator) already
+  bind metal-internal. The `""`->metal-admin default is an API-charm convention (the admin API
+  endpoint lives on metal-admin) mechanically inherited by a non-API service; metal-internal is
+  ovn-central's correct home. **What was wrong was only my premise that the rebind would FIX the
+  cert bug** -- it does not. The two are SEPARATE: the binding is the right categorization; the
+  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.
   **>>> 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
diff --git a/docs/design-decisions.md b/docs/design-decisions.md
index ae65c9c..89c2335 100644
--- a/docs/design-decisions.md
+++ b/docs/design-decisions.md
@@ -902,6 +902,18 @@
 metal-internal from the start; a charm that resolves endpoint addresses via the default binding
 needs that default on the plane its certs live on, or it hits LP #2044324 on any multi-space DC.
 
+**CLARIFICATION 2026-08-03 (after the live rebind did NOT fix the cert issue): this amendment
+is CORRECT ON ARCHITECTURAL GROUNDS and STANDS regardless of the cert bug.** ovn-central IS a
+metal-internal service by D-052's own categorization ("OVN NB/SB DB (ovsdb*)" is listed under
+metal-internal) -- it has no public/admin API endpoint and every functional endpoint already
+binds metal-internal, so the `""` default belongs there too; metal-admin was the API-charm
+convention mis-inherited by a non-API service. **What did NOT hold was the expectation that this
+rebind would resolve LP #2044324.** It did not: post-bind the charm still skips its
+internal/admin/public cert requests ("no local address found") and vault still issues no server
+cert. Those endpoint address-types are not driven by the default binding; the cert failure is a
+separate charm/interface defect (LP #2044324, server-cert request/response) and is tracked as its
+own item. The binding is retained because it is the right categorization, not as a cert fix.
+
 ## D-053 -- Rename network space `fabric-data` -> `data-tenant` (2026-06-25)
 
 **Status:** ADOPTED. Naming-only change to the D-052 plane set; no architectural change.