diff --git a/persistent-memory.d/2026-08-17-fleet-ipv6-mesh.md b/persistent-memory.d/2026-08-17-fleet-ipv6-mesh.md
index b248c49..188c5ef 100644
--- a/persistent-memory.d/2026-08-17-fleet-ipv6-mesh.md
+++ b/persistent-memory.d/2026-08-17-fleet-ipv6-mesh.md
@@ -127,3 +127,41 @@ Cloudflare DNS-edit token, so this is self-serve.
   WireGuard holds keys in kernel memory, so no restart was needed. The parent
   `/etc/wireguard` was already 700, which capped the real exposure to root-capable
   contexts inside the LXC — but the modes were still wrong.
+
+---
+
+## CORRECTION (recorded 2026-08-24): "AT&T delegates exactly ONE /64" is the
+## per-REQUEST truth, not the total — eight /64s exist and are unclaimed
+
+The section above concludes AT&T hands out a single `/64` and that the
+`c110`/`c11f` pattern reading as a `/60` was a misread. **That conclusion was
+itself superseded later in the same session, and the correction never made it
+into memory** — it survived only in the session transcript, and was recovered
+2026-08-24 while assessing a proposal to grab more prefixes.
+
+Reading the **BGW's own LAN statistics page** gave the whole picture:
+
+```
+BGW WAN v6   2001:506:70b2:8958::1      <- AT&T's transit prefix
+BGW LAN v6   2600:1700:b25:c110::/64    <- the BGW keeps this for itself
+Delegated    2600:1700:b25:c11f::/64    <- what the UDM got
+```
+
+**The BGW holds the `/60` and rations it**, keeping `c110`–`c117` for itself and
+delegating from the top down — the UDM got `c11f`, the last one. So
+`c118`–`c11f` are **eight delegatable /64s that genuinely exist and are yours**,
+sitting unclaimed.
+
+Both observations are compatible, which is why the first one looked conclusive:
+the prefix-ID test only carves *within* a delegation already held, so a UDM
+holding one `/64` cannot move it no matter what prefix-ID you set. The BGW
+issues **one `/64` per IA_PD request**, and **UniFi solicits exactly once**.
+
+**Consequence — the ceiling is the requester, not the carrier.** More prefixes
+need more IA_PD requests (multiple IAIDs, or multiple client DUIDs), which the
+UDM will not do. That is what makes a separate DHCPv6-PD client viable, and it
+is why "ask AT&T for a bigger delegation" may be aimed at the wrong party: this
+looks like BGW rationing rather than a provisioning-profile limit.
+
+Live state at correction time: `wan_dhcpv6_pd_size: 64`, `wan1 v6
+2600:1700:b25:c110::48`, all 5 NH3 LANs still `ipv6_interface_type: none`.