diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index 07f129d..b848976 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -67,8 +67,10 @@
 > encap IPs are SPLIT ACROSS FAMILIES -- the containerized control-node chassis (octavia LXD)
 > have IPv4-only data-plane addresses (`10.12.16.x`; D-134 auto-picked, not carved) so derive
 > IPv4 encap, while the carved compute METAL uses IPv6 (`2602:f3e2:f02:30::x`); cross-family
-> geneve tunnels never form (`bfd_status` empty), 100% cross-node loss. Roosevelt-delta: v6
-> builds must give containerized OVN chassis a v6 data-tenant address (candidate D-143, PROPOSED).
+> geneve tunnels never form, 100% cross-node ICMPv6 loss (encap-family split + loss are the
+> decisive evidence; `bfd_status` empty is ambiguous, not relied on). Roosevelt-delta: v6 builds
+> must give containerized OVN chassis a v6 data-tenant address (warrants a D-number, PROPOSED --
+> number assigned at ruling).
 > Fix is substantial + rebuild-relevant; NOT applied. Root-cause record:
 > `docs/audit/geneve-over-v6-rootcause-20260808.md`. Full changelog at session close.
 
diff --git a/docs/audit/geneve-over-v6-rootcause-20260808.md b/docs/audit/geneve-over-v6-rootcause-20260808.md
index 2299efb..ce5c071 100644
--- a/docs/audit/geneve-over-v6-rootcause-20260808.md
+++ b/docs/audit/geneve-over-v6-rootcause-20260808.md
@@ -26,10 +26,15 @@
 | `vr1-dc0-compute-01`   | amphora host (metal) | `[2602:f3e2:f02:30::120]` | IPv6 |
 | `vr1-dc0-compute-02`   | compute (metal) | `[2602:f3e2:f02:30::121]` | IPv6 |
 
-Corroboration on compute-02 (`ovs-vsctl list interface`): geneve tunnels to the control
-chassis carry IPv4 `remote_ip=10.12.16.{1,2,3}` while the local endpoint is IPv6; **every
-tunnel `bfd_status` is empty** (none established). Only the compute<->compute tunnel
-(`[2602:f3e2:f02:30::120]`, v6<->v6) is family-consistent.
+Corroboration on BOTH compute chassis (`ovs-vsctl list interface`) -- INCLUDING
+`vr1-dc0-compute-01`, the amphora's actual host (`ovn-chassis/1`): geneve tunnels to the three
+control chassis carry IPv4 `remote_ip=10.12.16.{1,2,3}` while the local endpoint is IPv6 ->
+cross-family, cannot encapsulate. Only the compute<->compute tunnel (`[2602:f3e2:f02:30::12x]`,
+v6<->v6) is family-consistent. NOTE on evidence weight: `bfd_status` read empty on all tunnels,
+but that is AMBIGUOUS (OVN geneve does not necessarily populate BFD) and is NOT relied on -- the
+DECISIVE evidence is the encap family split + the 100% ICMPv6 loss on the tested control->compute
+path. The v6<->v6 compute<->compute data path is UNTESTED (no second instance existed to ping),
+so it is NOT claimed healthy.
 
 ## Mechanism -- why control got v4, compute got v6
 The octavia control chassis is an **LXD container** whose data/geneve-plane interface
@@ -42,17 +47,20 @@
 underlay and names it a Phase-0 verification gate; this is the live proof that gate is not
 clean.
 
-Note: neither side matches D-101's "IPv6-only **ULA** data-tenant" literally -- compute uses
-a **GUA** `2602:f3e2:f02:30::/64` and control uses v4 `10.12.16.0/22`. The data-tenant plane
-is effectively dual-stack and encap selection diverges by node type (container vs metal).
+SAME PLANE, family-selection defect (NOT a binding error): `lib-net.sh` PLANE_CIDRS confirms
+`10.12.16.0/22` = the `data-tenant` plane, and `data-tenant` is in `SPACES6` (v6-capable); the
+v6 side is the GUA `2602:f3e2:f02:30::/64` seen on metal. Both node types bind the same
+`data-tenant` space -- the divergence is address-family SELECTION on one dual-stack plane
+(containers got a v4-only address there, metal got v6), not a mis-binding. Note also that neither
+side matches D-101's "IPv6-only **ULA** data-tenant" literally (compute uses a GUA, control v4).
 
 ## Roosevelt-delta (why this outlives throwaway dc0)
 Any v6 build with CONTAINERIZED OVN chassis (octavia/ovn-chassis-octavia, and any LXD-hosted
 ovn-chassis) must give those containers a v6 data-tenant address so geneve encap is v6 and
 matches metal. The auto-picked LXD addressing (D-134) does not currently guarantee this. This
-is the containerized-chassis-v6-underlay problem; it will recur on the 10.13 rebuild. Candidate
-for a new D-number (GA-R3: architectural + Roosevelt-delta; next-free D-143) -- PROPOSED, not
-minted (operator ruling owed).
+is the containerized-chassis-v6-underlay problem; it will recur on the 10.13 rebuild. Warrants a
+new D-number (GA-R3: architectural + Roosevelt-delta) -- PROPOSED; number to be assigned by
+grep-for-next-free AT ruling time (operator ruling owed), not pre-allocated here.
 
 ## Fix landscape (all gated; none applied)
 - **Durable (rebuild):** ensure containerized OVN chassis get a v6 address on the data-tenant