diff --git a/docs/audit/stage5-dc0-phase03-coreverify-20260806.txt b/docs/audit/stage5-dc0-phase03-coreverify-20260806.txt
index 8dc8855..562892f 100644
--- a/docs/audit/stage5-dc0-phase03-coreverify-20260806.txt
+++ b/docs/audit/stage5-dc0-phase03-coreverify-20260806.txt
@@ -255,6 +255,46 @@
  `:public` deferred to the operator ruling. designate is Stage-7-blocked (not serving) ->
  no urgency; do it correctly, not fast.
 
+## RESEARCH CONCLUSION 2026-08-06 (operator asked: investigate the tenant surface + charm docs)
+The `:public` OPEN question is now RESOLVED -- fix BOTH `:public` and `:internal`.
+Three independent lines of evidence, all pointing the same way:
+ 1. RULED (D-020 AMENDMENT 2026-07-27, operator GA-R5, "Both full triples ... .62 designate"):
+    designate gets the ESTABLISHED provider/admin/internal triple (.62), same shape as
+    keystone/glance. That ruling's own coherence note: dnsaas on provider-public makes
+    "DNS-as-a-service tenant-facing by design." The triple only functions if public/admin/
+    internal bind to provider-public/metal-admin/metal-internal -> the ruling IMPLIES the
+    bindings. Current bundle (public+internal on the metal-admin fallback) is a CONFORMANCE
+    DEFECT against D-020, same class as the vault-VIP repair in that same amendment.
+ 2. CHARM SUPPORTS IT (deployed metadata.yaml on designate/0, AUTHORITATIVE -- read in full):
+    `extra-bindings: {public: , admin: , internal: }` -- designate declares all three, exactly
+    like glance. (A WebFetch on the charm's MASTER metadata claimed "no extra-bindings" -- that
+    was a small-model instrument error; the DEPLOYED 2024.1 charm is the authority and juju
+    show-application confirmed the endpoints are bindable. Also hit: quoted-key grep miss +
+    subordinate-glob misread -- three metadata instrument errors, each caught by reading the
+    actual file.) The charm's own description: "Multi-tenant ... REST API for domain/record
+    management" -> the REST API is tenant-facing by design.
+ 3. EVERY SIBLING binds public->provider-public + internal->metal-internal; designate is the
+    lone deviation, with no ruled exception.
+FEASIBILITY (all confirmed read-only): all 3 designate units hold BOTH provider-public
+ (10.12.4.141/.170/.169) AND metal-internal (10.12.12.110/.144/.143) addresses -> neither
+ `juju bind` is refused, no --force. Cert already covers metal-internal SANs; will REISSUE to
+ add provider-public on the public bind (currently absent -- expected, verify after).
+
+## FINAL PROPOSED FIX (gated; bundle + live together, per the D-072/BUNDLEFIX-011 precedent):
+ BUNDLE (config-of-record): add to designate's bindings in bundle.yaml:
+     internal: metal-internal
+     public: provider-public
+   (admin correctly stays on the '' = metal-admin default; dnsaas stays provider-public.)
+ LIVE (individually gated): juju bind designate public=provider-public internal=metal-internal
+ VERIFY (assert the artifact, not rc=0 -- D-072 method + appendix-A ladder): haproxy backend
+   readback shows the _admin/_internal backends on served addresses and UP; re-read the issued
+   cert SANs (now include provider-public + metal-internal); re-run the haproxy sweep (designate
+   0 DOWN); designate endpoint list shows public on provider-public, internal on metal-internal.
+ Also owed: a BUNDLEFIX number + update network-space-binding-reference.md's designate row
+   (it is "generated from bundle.yaml" so it re-generates once the bundle is fixed).
+ SEQUENCING: designate is Stage-7-blocked -> no urgency; do bundle+live together so a redeploy
+   is correct and live is not left divergent.
+
 ## Step 3.4 keystone domain-manager policy -- NOT RUN this session
   Deferred with the openstack-client-dependent verification depth; the PO: stage-1 check +
   the C.4 G3 behavioral probe (which mutates -- creates user/project) are owed. Recorded as