diff --git a/docs/design-decisions.md b/docs/design-decisions.md
index b89197b..5f1c3c3 100644
--- a/docs/design-decisions.md
+++ b/docs/design-decisions.md
@@ -5999,6 +5999,39 @@
 itself is an operator-gated live MAAS mutation across 12 subnets and is not batched with
 the tool's delivery.
 
+### ANNOTATION 2026-08-06 (Roosevelt-delta OBSERVATION, operator-requested; NOT a ruling)
+
+**What this band scheme pins, and what it deliberately does not: LXD CONTAINER addresses
+are auto-picked, not carved.** D-134 pins two address classes to specific, plane-aligned
+octets -- NODE statics (per-role bands, e.g. control .100-.102) and the VIP band (.50-.99,
+reserved so MAAS never auto-allocates into it; the bundle/hacluster own it, `lib-net`'s
+matching-octet rule keeps a VIP's host-part identical across planes). The OpenStack control
+plane, however, runs in Juju-provisioned LXD containers, and those container addresses are
+NOT in either pinned class.
+
+MEASURED 2026-08-06 (dc0, via the region API): the container `juju-d4f45a-0-lxd-5` (a
+designate unit) is a MAAS **device** whose three plane interfaces are each `mode=static`
+(fixed, not DHCP) -- but the addresses sit in the **.100-.200 auto pool** (outside the
+`.4-.49`+`.50-.99` reserved bands and the `.201-.254` metal-admin dynamic/DHCP range) and
+were **auto-picked by MAAS independently per subnet**: `10.12.4.141 / 10.12.8.198 /
+10.12.12.110` -- three unrelated host-parts. Consequence: **container octets float across
+planes and are not guaranteed stable across a full teardown/redeploy** (MAAS re-allocates
+next-free from the pool), whereas node and VIP octets survive a rebuild because they are
+explicitly pinned. This is correct and harmless for VR1: clients use the VIPs (the catalog
+endpoints), haproxy proxies to whatever the backend addresses are, and the vault cert is
+reissued to cover whatever a unit holds (observed live when BUNDLEFIX-056 rebound designate
+-- the new provider-public leg was picked up automatically).
+
+**Roosevelt-delta:** a bare-metal build that wants PREDICTABLE / pinned control-plane
+container addressing (the property nodes and VIPs already have here) would add a
+per-container-per-plane MAAS static RESERVATION -- a "container carve" analogous to the node
+carve this decision enforces. VR1 deliberately does not do this: it pins nodes (D-134) and
+VIPs (`lib-net`) and lets MAAS auto-pick container statics. Whether Roosevelt should pin them
+is the open question; nothing in VR1 depends on the answer. GA-R3: OBSERVATION, no new
+D-number -- annotated onto D-134 (the decision a Roosevelt build session greps for the
+addressing scheme). Evidence: this session's phase-03 core-verify thread; MAAS `ipranges` +
+device interface `mode` captured live, no secrets.
+
 ## D-135: ADOPTED (AMENDED 2026-07-24) -- VR1 per-DC artifact mirror realization (D-107 build-out, staged) [ARCH]
 
 **Status:** ADOPTED 2026-07-23 (Stage 4, branch dc-dc-stage4-phase3-maas-deploy). Two