diff --git a/docs/design-decisions.md b/docs/design-decisions.md
index bbe5ab0..cd1e75f 100644
--- a/docs/design-decisions.md
+++ b/docs/design-decisions.md
@@ -7197,3 +7197,44 @@
 **VPN (`:e0`) IS THE SAME OMISSION AND IS NOT RULED HERE.** VR0 and Willamette both carry
 `:e0::/60` with role `vpn`; VR1 has none. It was surfaced alongside OOB and the operator's direction
 named OOB only, so it stays OPEN rather than being folded in silently.
+
+### AMENDMENT 2026-08-01 (b) -- OOB's IPv4 per-DC allocation: dc0 `10.12.40.0/22`, dc1 `10.12.88.0/22`
+
+**Operator answer, exact utterance: "dc0 10.12.40.0/22, dc1 10.12.88.0/22 (Recommended)"**, given
+after asking for "an oob recommendation that has a similar pattern" to the existing per-DC carve.
+
+**THIS SUPERSEDES `10.12.60.0/22`** from amendment 2026-08-01 (a) above. That value came from
+D-058 (itself SUPERSEDED by D-060) and was ruled back into force before the allocation pattern
+had been measured. D-058 remains superseded in full; `10.12.60.0/22` now carries NO VR1 role and
+returns to the free pool.
+
+**THE MEASURED PATTERN, because the obvious rule is not the real one.** Per-DC v4 today:
+
+    dc0:  4,  8, 12, 16, [20 24 28 FREE], 32, 36
+    dc1: 64, 68, 72, 76,                  80, 84     <- contiguous, no gap
+    offset: +60 +60 +60 +60               +48 +48
+
+**The dc0->dc1 offset is a CONSEQUENCE, not a rule:** dc0 skipped 20-28 (historical, D-052/D-058
+era), dc1 never reproduced the skip, so the last two planes drifted from +60 to +48. The only
+uniform property is that each DC appends in ascending order and dc1 has stayed contiguous.
+
+**dc0's 20-28 gap is UNUSABLE for a symmetric pair, measured rather than assumed:** `20+60 = 80`
+and `20+48 = 68` are both allocated, so no free counterpart exists for it in either offset.
+
+**WHY THIS PAIR.** `40` and `88` are each the next free `/22` immediately after their own DC's
+highest plane (36 -> 40; 84 -> 88), so both runs stay contiguous and dc0's historical gap is left
+alone. The offset is **+48, exactly what storage and replication already use** -- it continues the
+current relationship instead of reverting to the older +60. Against the superseded `10.12.60.0/22`:
+`60` covers 60-63 and abuts dc1's block at 64, which would make it the only dc0 plane touching
+dc1's range, and its +60 partner `120` sits far outside dc1's contiguous 64-88 run.
+
+**RULED, completing the OOB row of D-139 ruling A's family matrix:**
+
+| Plane | dc0 IPv4 | dc1 IPv4 | dc0 IPv6 | dc1 IPv6 | Family |
+|---|---|---|---|---|---|
+| `oob` | `10.12.40.0/22` | `10.12.88.0/22` | `2602:f3e2:f02:f0::/64` | `2602:f3e2:f03:f0::/64` | dual-stack |
+
+**STATE: the v6 half is BUILT** (apex push 2026-08-01, `f02:f0::/60` + `f02:f0::/64` live for dc0;
+dc1 not yet pushed). **The v4 half is RULED AND NOT BUILT** -- neither `/22` exists in the apex or
+in MAAS. `netbox/d139-gua-carve.py` cannot create them: it is v6-prefixes-only by construction.
+The v4 rows are OWED and gate nothing in D-139 or the Stage-5 deploy.