diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index 00b49e5..a9d53ab 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -700,6 +700,22 @@
   gateway to the router it creates -- no config surface tells it to and ULA is not globally
   routable, but isolation was not proven from docs; settle by inspecting the router at
   deploy.
+  **R8a RULED 2026-07-27 -- exact utterance "Extend the existing o-hm0 verifier to compare
+  MTUs (Recommended)"**, recorded as a SUB-RULING on the D-101 MTU note. **OPS under GA-R3
+  -- a script change, doubt resolves DOWN, NO D-number assigned.** It closes the LP #2018998
+  obligation R8 carried forward. Measured basis: `scripts/phase-05-octavia-verify.sh:104`
+  ALREADY inspects o-hm0 (asserts `state != DOWN` and an `fc00::/` ULA), so the MTU
+  comparison is a natural extension of an existing check rather than new machinery -- while
+  `grep -i mtu` across `cloud-assert.sh`, `phase-05-octavia-verify.sh` and
+  `phase-04-network-verify.sh` returns NOTHING, so MTU is asserted nowhere post-deploy.
+  Pre-configuration was NOT available: the charm exposes no MTU option, so the only real
+  choice was how the mismatch is DISCOVERED. Rely-on-the-charm was refused because the
+  2025-12-31 recurrence on our exact pin shows the self-heal is unreliable and the symptom
+  (spurious failovers under load) masquerades as a Ceph/network/amphora fault; the blind
+  `mtu_request` workaround was refused because it fights the charm's fix where that fix
+  works and would MASK a regression. **Incidental corroboration of R8 from this repo's own
+  tooling: that VR0-era verifier expecting an `fc00::/` ULA on o-hm0 independently confirms
+  the charm's default lb-mgmt-subnet is an IPv6 ULA.**
   Remaining: R9-R10 blocking, R12-R15 standing.
 - Position inside Stage 3: deploy step A EXECUTED 2026-07-19 (6/0/6
   exact; convergence zero --
diff --git a/docs/design-decisions.md b/docs/design-decisions.md
index 74ea6a1..87381fa 100644
--- a/docs/design-decisions.md
+++ b/docs/design-decisions.md
@@ -2322,6 +2322,37 @@
 9000 is not proof a 9000-byte frame survives the path -- that is the assert-on-content rule
 applied to MTU.
 
+**SUB-RULING 2026-07-27 (R8a) -- the OCTAVIA arm of this verification. OPS under GA-R3 (a
+script change; doubt resolves DOWN, so no D-number is assigned).** Question as presented:
+given the octavia charm exposes NO MTU option, the failure is silent, and LP #2018998
+recurred on our exact pin, how should the `o-hm0` / `lb-mgmt-net` mismatch be caught?
+Options: (a) extend the existing o-hm0 verifier to compare MTUs; (b) deploy and rely on the
+charm's update-status fix; (c) apply the `ovs-vsctl mtu_request` workaround unconditionally.
+Operator selection, exact utterance: **"Extend the existing o-hm0 verifier to compare MTUs
+(Recommended)"**.
+
+Why it is cheap: `scripts/phase-05-octavia-verify.sh:104` ALREADY inspects o-hm0 -- it
+asserts `state != DOWN` and the presence of an `fc00::/` ULA -- so it holds the handle
+already and an MTU comparison is a natural extension, not new machinery. Measured gap:
+`grep -i mtu` across `cloud-assert.sh`, `phase-05-octavia-verify.sh` and
+`phase-04-network-verify.sh` returns NOTHING -- MTU is asserted nowhere in any post-deploy
+verifier. Upstream states the failure precisely: "The lb-mgmt-net is created by the charm
+with mtu 8942 while on o-hm0 charm sets mtu 1500."
+
+Option (b) refused: the 2025-12-31 recurrence on octavia 14.0.0 / 2024.1 stable is evidence
+the charm-side self-heal is not reliable, and the symptom -- spurious failovers under load
+-- reads as a Ceph, network or amphora fault long before anyone suspects MTU. Option (c)
+refused: a blind unconditional `mtu_request` fights the charm's own fix where that fix IS
+working, and would MASK a future regression rather than surface it.
+
+Delivery: the assertion ships in `scripts/phase-05-octavia-verify.sh` with its harness
+green, gauntlet ALL GREEN, repo-lint 0-fail and a changelog entry carrying a revert. Apply
+`ovs-vsctl set interface o-hm0 mtu_request=<match>` ONLY if the check fires.
+
+**Incidental corroboration of R8, from this repo's OWN tooling:** that verifier expects an
+`fc00::/` ULA on o-hm0 and is VR0-era, which independently confirms the octavia charm's
+default lb-mgmt-subnet is an IPv6 ULA. The as-built already assumed what R8 ruled.
+
 **What IS owed, all mechanical, no ruling required:** propagate the ratified v6 carve into
 `scripts/lib-net.sh` (a v6 arm per DC, keyed the same way the v4 `PLANE_CIDRS` arms are),
 and carve the twelve plane prefixes into MAAS as subnets on their existing fabrics. Both