# Pass 4 -- Worker W4.4: the owed [ARCH] decision framing (container-elim + layered module workflow)

**Author:** W4.4 (Phase 4, `SCOPE-AND-EXECUTION-PLAN.md` Section 4). **Date:** 2026-08-09.
**Inputs read in full:** `SCOPE-AND-EXECUTION-PLAN.md`, `pass0-admin-report.md`,
`pass1-admin-report.md`, `pass2-admin-report.md`, `pass3-admin-report.md`; `docs/design-decisions.md`
entries D-122, D-123 (+ both amendments), D-124 (+ 3 amendments), D-125, D-126, D-127, D-128,
D-131, D-132 (+ 2026-07-30 amendment + addendum), D-134 (+ 5 amendments), D-138, D-143; the GA-R3
admission test (`SKILL.md:406-410`). **READ-ONLY.** This document FRAMES a decision package for the
operator (GA-R5); it rules nothing. Every recommendation below is graded "recommend," never "ruled."

---

## 0. What this pass confirmed is already SETTLED and is not re-opened here

Per pass0 Section 7a (operator-confirmed at the Phase-0 gate, a DIRECTIONAL PLANNING
CONFIRMATION -- explicitly **not** a GA-R5 [ARCH] ruling): target topology = **Option 1** (flat
node VMs on vcloud libvirt + one small non-hypervisor `vr1-dcN-client` VM per DC); cross-DC
adjacency handling = **(a)** (accept co-residency + a new vcloud-level host isolation control);
MAAS region stays on `vr1-dcN-maas-01`. Phases 1-3 planned, tooled, and tested against this. **The
formal [ARCH] ruling this document frames is the one thing the Phase-0 gate explicitly deferred**
(SCOPE Section 7: "the container-elim itself is an OWED [ARCH] decision... Phase 4 FRAMES it...
it is ruled by the OPERATOR").

---

## 1. THE CORE QUESTION: D-123 amendment, or a new D-number?

### 1.1 Apply the GA-R3 admission test verbatim (`SKILL.md:406-410`)

> "a new D-number needs architectural consequence beyond the stage, a Roosevelt-delta (the A1
> test: a Roosevelt build session would grep it before touching a built surface), or
> supersession. Everything else is OPERATIONAL... doubt resolves DOWN to OPS."

All three admission triggers fire, independently:

- **Architectural consequence beyond the stage.** Confirmed across every phase: the change
  restructures Stage 3 wholesale (pass1 Section 2.2), amends D-128's own definition (pass1
  check 6), voids/re-causes a D-124 clause (pass0 row 6, Section 6 item 8), terminates D-125
  (Section 3 below), reopens D-131's standing-pattern status (pass2 4.2(ii)), touches D-132's
  addendum premise (pass2 4.2(i)), forces a D-134 map addition (pass2 4.3), and changes D-138's
  concrete host (pass0 check 3). No single existing entry's scope contains all of that.
- **Roosevelt-delta (A1 test).** Explicit and operator-stated: SCOPE Section 1 quotes the
  operator directly -- the redeploy is "a good test of the module deployment project we are
  developing during the teardown and redeploy," and SCOPE Section 7 names the layered module
  workflow a "Roosevelt deliverable... design it to transfer to the pre-Roosevelt bare-metal
  test." A future Roosevelt-adjacent session would grep this decision before laying out any
  future site's substrate shape or module structure -- textbook A1.
- **Supersession.** D-123's core adopted ruling -- Model B, 4-level nesting, node VMs live
  INSIDE `vvr1-dcN`, single-`virsh-destroy` site-down (`design-decisions.md:4929-4939`) -- is
  directly reversed. Option 1 does the opposite of what D-123 rules: nodes return to being flat
  vcloud-level siblings (D-123's own rejected "Model A" shape, now readopted with 2026-07-30+
  rulings layered on).

### 1.2 The load-bearing precedent already in this ledger: D-143

D-143 is the closest analog and it is a **directly on-point precedent, not an analogy**: D-143
"AMENDS D-115 premise" and "TERMINATES D-101... clause" (`design-decisions.md:8083`) -- exactly
the shape of relationship the container-elim has with D-123/D-124/D-125/D-128 -- **and it was
minted as its OWN new D-number**, not appended as a D-115 or D-101 amendment. D-143's
Reconciliation section (`:8124-8147`) is the template this document's Section 3 follows: a new
entry states its verb (SUPERSEDES / AMENDS / TERMINATES / CONSISTENT-WITH / PRESERVES) against
each affected decision, rather than the affected decision being edited to absorb the reversal.

### 1.3 Why "D-123 amendment" under-fits

D-123 already carries two prior AMENDMENT entries: the 2026-07-16 ruling that ADOPTED Model B
over the recommended Model A, and the 2026-07-20 correction that Model B's virsh-pod MECHANISM
was refuted (per-machine power replaces it) while Model B's SHAPE stood. A third amendment that
reverses D-123's own central ruling -- the shape itself, the thing the decision exists to answer
-- would have D-123 amend itself out of existence: a future reader grepping "D-123" for "what
shape is a DC site" would need to read three superseding layers to reach a NO that contradicts
the entry's own header. GA-R1's append-only discipline is better served by leaving D-123's history
intact (Model A recommended -> Model B ruled -> mechanism refuted) and recording the reversal as a
fresh, separately-dated decision that names D-123 as SUPERSEDED -- exactly D-143's pattern against
D-101/D-115.

### 1.4 RECOMMENDATION

**Mint a new D-number** (next-free = **D-144**, per `ledger-scan.sh` run this session inside
pass3 -- `pass3-admin-report.md` Section 1 item 6: "D next-free=144" -- re-verify at mint time per
repo numbering discipline, do not assign here). Title shape (for the operator's edit, not a
pre-write): *"D-144: VR1 container-layer elimination -- flat per-DC substrate + per-DC client VM,
layered module workflow (SUPERSEDES D-123 Model B)"*. This is a **recommendation**, presented
alongside the D-123-amendment alternative below for the operator to weigh; GA-R5 forbids the pass
from picking.

**Alternative presented for completeness (not recommended): amend D-123 in place.** Would keep
one canonical "DC site shape" entry instead of a reader needing D-123 -> D-144 to reach current
truth. Weighed against: it fights the D-143 precedent, and D-123's entry would need heavy internal
surgery (its own "Model A" section would need to become "Model A, re-adopted under D-144" --
essentially rewriting the entry to point at a new one anyway, which is the same reader cost with
none of the whole-history discoverability of a fresh entry).

---

## 2. RIDE-ALONG DECISIONS -- each framed ([ARCH]/[OPS], reconciliation, Roosevelt-delta)

Seven items, per the assignment; doubt resolves DOWN to OPS (GA-R3).

### (1) D-128 amendment -- the Plane-1/Plane-2 execution-host split

**[ARCH].** D-128 is itself tagged [OPS] in the ledger, but this specific edit meets the GA-R3
bar on its own: it changes a RULED decision's own DEFINITION (pass1 check 6, verified direct
read `design-decisions.md:5354-5364`) -- Plane 2 currently includes "the INNER `tofu` root
(`opentofu/vr1-dc0-substrate/`, `qemu+ssh` FROM Office1 into `vvr1-dc0`)"; under Option 1 that
object ceases to exist, so the substrate build becomes wholly Plane 1 (vcloud-local) and Plane 2
shrinks to MAAS/NetBox (juju/openstack already moved off Plane 2 by D-138). **Reconciliation:**
AMENDS D-128 -- narrow, single-entry scope change, not a reopening of the two-plane MODEL itself
(Claude-stays-on-jumphost, workstation-is-human-path all stand unchanged). **Roosevelt-delta:**
indirect -- D-128 states explicitly it has "No Roosevelt analog" for Plane 1 (throwaway simulation
scaffolding); the amendment doesn't change that, it only shrinks what Plane 2 covers.
**Recommendation:** own dated "D-128 -- AMENDMENT" entry, riding the same operator exchange as the
core ruling (it is a direct, mechanical consequence of Option 1, not an independent question) but
recorded against D-128, not folded into D-144's body.

### (2) D-125 bridge-in retirement -- within the core ruling, or its own note?

**[ARCH]** (D-125 is itself [ARCH]) **but with no independent architectural surface once
separated from the core question.** D-125 exists SOLELY to solve OBS-3 -- the egress-dead-end
created by Model B's WAN NAT living inside a nested containment VM with no direct route out
(`design-decisions.md:5091-5096`). Remove the nesting and OBS-3's precondition disappears; there
is nothing left for D-125 to fix. This is not a parallel decision riding alongside the core
ruling -- it is a direct, total consequence OF it (pass2 Section 3.1: `wan-bridge` "collapses,"
edge WAN reattaches to the vcloud-level NAT directly -- literally D-122's ORIGINAL pre-D-125
intent, restored). **Roosevelt-delta:** none of its own -- D-125's bridge-in mechanism was always
VR1-only rehearsal scaffolding for a nesting pattern that itself has no Roosevelt analog.
**Recommendation:** do NOT mint or independently amend D-125 as a ride-along item; record its
TERMINATION as a named consequence inside the core new entry's reconciliation ledger (Section 3
below), the same way D-143 named D-101's clause TERMINATED inside D-143's own body rather than as
a separate D-101 amendment entry.

### (3) The D-134 `.8` octet addition for `vr1-dcN-client`

**[ARCH]-adjacent by D-134's own established pattern, but narrow.** D-134 is tagged [ARCH] and
has FIVE prior dated amendments, three of which are single-slot octet-map extensions with the
identical shape to this one (`.5` juju 2026-07-29, `.6` MAAS region via the D-132 addendum,
`.7` tailscale 2026-08-07 -- `design-decisions.md:5947-6007`). Each was minted as its own dated
"D-134 -- AMENDMENT" entry, never folded into the decision that motivated the new host class
(D-104 for juju, D-132 for MAAS, D-129(iii) for tailscale). The client VM is `.8`, next free slot
(pass2 Section 4.3, W2.2 verified against the standing table which enumerates through `.7`).
**Reconciliation:** AMENDS D-134 (adds one row; does not touch the CIDR/band structure itself).
**Roosevelt-delta:** real and explicit -- D-134's own amendment text states "A future DC standup
carves `.N` for its [service] by this standard" (`:6006`); a Roosevelt build session greps D-134
for the utility-band map before assigning any new per-DC service an address, exactly the A1 test.
**Recommendation:** own dated "D-134 -- AMENDMENT" entry, following the established pattern
exactly (motivated by/cited from the core ruling, minted separately) -- consistent, not a new
D-number, not folded into D-144's body.

### (4) Root-topology (B) + root naming

**[OPS].** Shared-outer + per-DC-flat tofu roots vs a single merged root is a **tofu-state
organization choice**: both alternatives deploy the identical physical/network topology (pass2
check 3, verified: "root-shape (B) mitigates NONE of" the three isolation concerns -- it is about
state blast radius, destroy scoping, and apply ordering, not what gets built). It does not change
what exists on the wire or in the hypervisor; it changes how the tofu STATE that describes it is
partitioned. Root NAMING (`-flat` vs reserving `-substrate`) is purely a repo convention.
**Reconciliation:** none against an existing D-number -- no prior decision rules tofu root
topology at this granularity. **Roosevelt-delta:** weak/indirect -- Roosevelt has no "tofu roots"
concept for physical hardware it doesn't create; the delta that DOES transfer (module composition,
`dc-site` as a reusable unit) is captured by the module-workflow design itself, not by the root
split. **Recommendation:** ratify as part of the Phase-4 module-workflow design / delivery
change-set (an OPS-graded record: changelog entry + `docs/dc-dc-deployment-workflow.md` Stage-3
Build-line text), not a D-number.

### (5) The three isolation controls' SEC rows -- power-key mitigation especially

Three distinct controls (pass2 Section 2, verified this session's cross-reads); each graded
separately:

- **(i) cross-DC plane-bridge network adjacency (the "(a)" control) and (ii) the SEC-010
  transit-leg successor: [OPS].** Both are new/re-authored SECURITY MITIGATIONS -- nftables
  artifacts with `--check` gates and SEC-NNN ledger rows -- of the same kind SEC-010 itself was,
  and SEC-010 was never a D-number (D-125 only cross-references it). GA-R3's OPS bucket is
  precisely "runbook edit / session-changelog line / as-built row" for this class of work; a SEC
  row plus a harness is the established mechanical pattern (pass3 confirms next-free is
  **SEC-034**, computed by direct ledger grep since `ledger-scan.sh` does not compute SEC numbers).
  **Recommendation:** SEC-ledger rows, not D-numbers; the REQUIREMENT that they exist and their
  ordering invariant (installed before any flat apply) is recorded as an owed artifact inside the
  core new entry's execution notes, mirroring how D-125 recorded SEC-010's constraint without
  itself being a SEC entry.

- **(iii) the MAAS power-key blast radius -- the hardest of the three, argued in detail.** This
  is the item the prompt specifically asks whether it "also warrants a D-number given it makes
  SEC-012/016 per-DC separation vacuous" (pass2 Section 2.3, verified this session's citations:
  `maas-region-power-key.sh` installs a per-DC key SEC-012/SEC-016 assume stays scoped;
  `maas-node-power.sh:28-30` confirms the REGION dials power; `opentofu/main.tf:175` confirms
  voffice1 is a sibling domain on the SAME outer libvirtd that will also hold every flattened DC
  node -- so under Option 1, each DC's region-resident power key opens a `qemu:///system`
  connection with virsh control over EVERY domain vcloud manages, not just its own DC). **Grading
  reasoning:** the mechanism CHOICE (restricted key / wrapper / polkit ACL) is squarely OPS -- a
  SEC-NNN mitigation like (i)/(ii). But the FINDING itself -- that flattening (the core ruling's
  own structural consequence) silently VOIDS a previously-relied-upon per-DC credential-isolation
  guarantee that SEC-012/SEC-016 were written to provide -- is architectural framing content: it
  is a tradeoff the operator is accepting BY ruling the core question, not an independent decision
  with its own Roosevelt-delta or supersession target. It has no existence apart from the core
  ruling (unlike D-125, above, it doesn't supersede or terminate any EXISTING decision by name --
  SEC-012/016 aren't D-numbers to supersede -- it just makes them functionally moot). **Net
  classification: [ARCH]-adjacent finding, [OPS] mitigation.** **Recommendation:** do NOT mint a
  separate D-number for this. Record the finding and the accepted tradeoff explicitly INSIDE the
  core new entry's body (so a future reader sees "flattening was known to weaken per-DC power-key
  scoping, mitigated by SEC-034[+1]" in the same place they see the topology ruling) -- this is
  the one item where recommending "fold into the core entry's text, not its own line-item" matters
  most, because burying it only in a SEC row (which nobody greps before touching architecture)
  would repeat exactly the failure class GA-R3's A1 test exists to prevent.

### (6) The rack-controller retirement + D-131 retire-with-evidence

**Split, two different triggers, two different answers -- do not conflate them.**

- **Rack-controller retirement itself: [OPS].** Both DCs' `region+rack` MAAS controllers already
  measurably run all rackd duty (pass2 check 2, direct reads: `changelog-20260807-dc1-region-
  sequence.md:80-89` dc1 transcript-grade; `changelog-20260730-dc0-region-migration.md:~532-549`
  dc0 process-measured, `pgrep -c dhcpd`=0 on the rack). Retiring `vvr1-dcN`'s vestigial Office1
  rack registration is a decommission step (a `maas rack-controller delete` + runbook note) -- it
  does not change any RULED architecture, it cleans up a registration nobody is using. This is the
  MAAS machine-record release/delete class of work already scoped as owed artifact #5.
- **D-131 retire-with-evidence: [ARCH]-touching, but AMENDS D-131, does not need a new D and is
  NOT itself created by the container-elim.** D-131 sub-decision 1 explicitly RULED the forwarder
  as "the STANDING per-DC pattern... applied to dc0 and part of every future DC standup's
  definition-of-done" (`design-decisions.md:5658-5661`) -- retiring that changes an ARCH decision's
  forward applicability, which is a real edit, not a nit. But the TRIGGER is D-132's already-ruled
  per-DC-region architecture (2026-07-30) removing D-131's own stated precondition ("rack-only
  controller, remote region") -- container-elim did not create this fact, it merely removes the
  vestigial host that made the asymmetry easy to miss (dc0 already proves the end state; dc1's
  forwarder is still load-bearing today, pass2 check 4 -- a real, unequal-grade asymmetry, not
  assumed equal). **Reconciliation:** AMENDS D-131 sub-decision 1 (own dated entry, D-131's
  existing amendment-free structure notwithstanding -- this would be its first). **Roosevelt-
  delta:** real -- D-131 sub-decision 4 is explicitly "PINNED... to be executed at next-deployment
  design time," i.e. this retirement IS that next-deployment design point arriving early.
  **Recommendation:** own dated "D-131 -- AMENDMENT" entry, gated on the owed live re-measure
  (current-day `primary_rack` state, both DCs) landing BEFORE the ruling is asked for, not a
  D-144 ride-along and not folded into D-144's body (its trigger is independent of container-elim).

### (7) Artifact-service re-homing/sizing

**[OPS].** A capacity/placement decision resolved by measurement (the FIT-calculator extension,
owed artifact #7/#13 amendment) against two concrete VM sizings that are both too small for dc0's
full mirror as authored (pass2 Section 3.3, verified sizing cites: `vr1-dc0-substrate/main.tf:
176-181` maas-01's 150 GiB earmarked "no spare"; client VM ~80 GiB). No architectural principle is
at stake -- it is "which host gets a bigger disk," decided with numbers, not a ruling about shape.
**Reconciliation:** none against an existing D-number. **Roosevelt-delta:** none identified --
mirror/cache sizing is a per-deployment capacity fact (D-135 already owns the dc0-full-mirror /
dc1-cache-proxy split as an ARCH decision; this ride-along is purely which HOST realizes it here).
**Recommendation:** resolved via the FIT-calculator numbers at delivery, recorded as a changelog
entry, no D-number.

### Ride-along count / [ARCH]-[OPS] split

**7 ride-along items.** Classification: **2 carry [ARCH] weight** (item 1, D-128 amendment;
item 3, D-134 amendment) that get their OWN dated amendment entries against existing D-numbers;
**1 is [ARCH]-in-substance but has no independent existence apart from the core ruling** (item 2,
D-125 -- folds into D-144's reconciliation ledger, not its own entry) **plus a second such item**
(item 5-iii, the power-key finding -- folds into D-144's BODY as an accepted tradeoff, its
mitigation MECHANISM graded OPS/SEC-row); **1 splits into an [OPS] cleanup + a separate [ARCH]
amendment** (item 6: rack retirement OPS, D-131 amendment ARCH but independently triggered);
**2 are cleanly [OPS]** (item 4 root-topology, item 7 artifact-service sizing); item 5-i/5-ii (the
two network isolation controls) are OPS/SEC-row work referenced from D-144's text. **Net: 0 new
D-numbers beyond the core D-144; 3 existing-decision amendments (D-128, D-134, D-131) filed
separately; 2 findings folded into D-144's own body; the remainder is SEC-ledger/changelog/runbook
work.**

---

## 3. THE RECONCILIATION LEDGER -- what the container-elim (D-144, proposed) does to each existing decision

Verb vocabulary matches D-143's own precedent (`design-decisions.md:8124-8147`): **SUPERSEDES**
(replaces the cited ruling outright), **AMENDS** (a factual premise or scoped clause changes, the
rest of the ruling holds), **TERMINATES** (a clause/mechanism is retired with no successor),
**PRESERVES** (the ruling's principle stands unchanged; at most its concrete realization updates),
**CONSISTENT-WITH** (untouched, cited for completeness).

| D-number | Verb | What changes / what does not |
|---|---|---|
| **D-122** (site shape) | **AMENDS** | Intent preserved (each site still has a distinct containment/entry-point identity -- now the client VM); the "single `virsh destroy <site-vm>` = site-down" LITERAL claim regresses to a root/module-scoped group-destroy (pass0 row 9) -- a real capability loss D-144 must state honestly, not silently drop. Dark-fiber/per-site-ISP/edge-shape clauses: untouched. |
| **D-123** (Model B containment) | **SUPERSEDED** | The core ruling -- nodes nested inside `vvr1-dcN`, depth-4, single-VM destroy -- is reversed. D-123's own history (Model A recommended -> Model B ruled 2026-07-16 -> mechanism refuted 2026-07-20) stays intact, append-only; D-144 records the supersession rather than editing D-123. |
| **D-124** (region<->rack transit addressing) | **AMENDS** (a clause reverses again) | The Scheme-A transit addressing (`172.31.0.0/24`, region/rack `/30`s) SURVIVES -- the client VM keeps the transit leg. The 2026-07-16 "sizing VOID under Model B" amendment (rack must hold a full node fleet, ~416/480 GiB) itself gets RE-CAUSED: under Option 1 the client VM is NOT a node-fleet host, so sizing returns toward something near D-124's small original proposal (4 vCPU/8192 MiB/80 GiB) -- exact figure OWED, not re-derived here (pass0 Section 6 item 8, "D-124 sizing-void re-cause"). |
| **D-125** (bridge-in egress) | **TERMINATES** | Its sole reason to exist (OBS-3, nested-WAN-NAT-with-no-egress) disappears with the nesting. `modules/wan-bridge` retires; edge WAN reattaches directly to the vcloud-level per-DC uplink NAT -- D-122's ORIGINAL pre-D-125 realization, restored (see item (2) above; folded into D-144's body, not filed separately). |
| **D-125's `wan-bridge` fallback note (double-NAT)** | moot alongside D-125 | Never adopted; moot with the primary mechanism gone. |
| **D-126** (rootless SSH access convention) | **PRESERVES** | The general decision (Option A, systemd --user local-forward, per-env key convention) is a reusable ACCESS PATTERN used by multiple site-service VMs, not solely the qemu+ssh dial into `vvr1-dcN`. Only ONE consumer of the pattern retires: the qemu+ssh dial's per-env key, which has "no successor" (pass1 Section 4, Part A step 3) because its object (the inner root's cross-host provider) is gone. D-126 itself is unchanged; note the retired consumer as a changelog line, not a D-126 edit. |
| **D-127** (VM autostart policy) | **AMENDS** | The explicit classification row "`vvr1-dc0` (and future vr1-dc1 containment) -> MANUAL" (`:5307-5311`, itself cross-referencing D-123) has no successor object. The client VM needs its OWN classification against D-127's stated rule of thumb (foundational/no-fragile-boot = autostart; deliberate/gated/resource-heavy = manual) -- pass3 confirms this is an OWED ruling, not inferable (A1's new test case cannot be written until it lands). Recommend a short D-127 amendment adding the client-VM row once ruled; the POLICY framework itself is unchanged. |
| **D-128** (two-plane operating model) | **AMENDS** | Real, substantive (item (1) above): Plane 2's own definition shrinks (loses the inner-root qemu+ssh object); the two-plane MODEL and Claude's-jumphost-residency are unaffected. |
| **D-131** (node-facing DNS strategy) | **AMENDS** (independently triggered, rides alongside) | Sub-decision 1's "standing per-DC pattern" status is reopened by D-132's already-ruled per-DC regions removing D-131's own stated precondition; container-elim only removes the vestigial host, it doesn't create the trigger. Filed as its own D-131 amendment (item (6) above), gated on the owed live re-measure. |
| **D-132 addendum** (region in own VM at `.6`) | **PRESERVES; premise-note only** | No change -- MAAS region stays on `vr1-dcN-maas-01` (operator-confirmed at the Phase-0 gate). Flag only: the addendum's original "hypervisor-fate" rationale (why the region got its own VM rather than co-locating) becomes MOOT under Option 1 (nothing is co-locating with a hypervisor anymore) -- a premise-currency note inside D-144's text, not a reversal (pass2 4.2(i)). |
| **D-134** (octet bands / standing cross-DC map) | **AMENDS** (new row, existing pattern) | Existing bands/CIDRs unchanged; adds `.8` = client VM, following the identical amendment shape as `.5`/`.6`/`.7` (item (3) above). Filed separately, per D-134's own established convention. |
| **D-138** (client lives IN the DC) | **PRESERVES; concrete host updates** | The PRINCIPLE -- cloud-facing tools (Juju, `openstack` CLI) dial the cloud from inside the DC, not from `voffice1` -- is UNCHANGED and is exactly what Option 1's client VM realizes. Only the CONCRETE HOST changes: from `vvr1-dcN` (a DC-node-fleet-containing hypervisor) to the new small non-hypervisor `vr1-dcN-client`. Credential-residency consequences (SEC-026/028/029 migration, pass0 row 8) are a direct, named consequence to record in D-144's reconciliation, not a D-138 rewrite. |

**Not superseded/amended by this change (verified, named to prevent scope creep):** D-114
(Office1's OWN containment VM, `voffice1` -- a structurally distinct, KEPT pattern; pass1 check 1
is explicit that Stage 2 is untouched and the two "containment VM" patterns must be named as
DIFFERENT going forward so name-similarity doesn't sweep D-114 in); D-133 (flat per-NIC plane
carve); D-139 (IPv6-only east-west); D-140 (Juju-as-tofu, pinned for a LATER redeploy, explicitly
not this one); D-143 (the re-IP this pass rides -- additive, kept distinguishable per axis
throughout Phases 1-3, `[D-143]`/`[CE]`/`[both]` tagging).

---

## 4. Summary for the operator (what D-144, if ruled, would need to say)

If the operator adopts the "new D-number" recommendation, D-144's body would need, at minimum:
(a) the core supersession of D-123's Model B; (b) the D-125 termination and D-124 sizing
re-cause, stated as direct consequences, not separate rulings; (c) the accepted power-key
blast-radius tradeoff (Section 2 item 5-iii) named explicitly, with its SEC-row mitigation as the
mitigating control, not the whole answer; (d) pointers to the three amendments filed alongside it
(D-128, D-134, D-131) so a reader lands on the complete picture from one grep. This document does
not draft that text -- GA-R5 reserves the ruling, and the ruling's exact wording, to the operator.
