diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index df2098c..4114e16 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -2309,8 +2309,26 @@
   (MAAS region) and `vr1-dc0-juju-01` (juju controller) have `autostart=disable`. <<<** Only
   the edge auto-recovers; the rack's own units (`dc0-snap-proxy`, `-net`, `dc0-mirror-net`,
   `nginx`) are all `enabled` and returned unaided. Both VMs were started by hand and verified.
-  **LOGGED, NOT FIXED: a host reboot leaves dc0 with no MAAS region and no juju controller.**
-  That is a standing exposure, independent of this change.
+  **^ CORRECTED SAME DAY -- I FRAMED THIS WRONGLY AND NO AUTOSTART SETTING WAS CHANGED.**
+  Calling it an exposure implied nobody had decided. **D-127 ("VR1 host-level VM autostart
+  policy") ALREADY RULES IT**, autostart is TOFU-MANAGED, and every measured value is an
+  explicit per-instance decision with its reason in-line: `main.tf:413`/`:540` the DC
+  containment VMs `false` ("MANUAL (gated bring-up), never on host boot"), `main.tf:102`/`:178`
+  office1-opnsense and voffice1 `true` ("foundational"), the DC edges `true` ("comes up with
+  its containment VM"), and the node VMs `false` ("MAAS-power-controlled"). Nothing is
+  defaulted-by-accident -- the module variable's own description forbids relying on its
+  default. **A session told to "fix autostart" would fight a ruling, and -- now that P8
+  exists -- a `virsh autostart` change would also surface as substrate DRIFT.**
+  **WHAT SURVIVES, AND IT IS NARROWER AND REAL: `vr1-dc0-maas-01` and `vr1-dc0-juju-01` were
+  folded into the `vr1_dc0_node` `for_each`, so they inherit the NODE justification --
+  "MAAS-power-controlled".** That is TRUE for the juju controller (`subtle-grouse`, a machine
+  in the dc0 region, `power_type=virsh`). For the **MAAS region VM it is CIRCULAR**: `hot-kid`'s
+  power is owned by the **Office1** region -- the very region D-132 q1 is migrating away from.
+  **If Office1 is retired, nothing owns the dc0 region VM's power and it does not autostart.**
+  That is a genuine ordering exposure in the D-132 q1 migration, not an autostart bug, and it
+  is LOGGED NOT FIXED. The right instrument is a per-VM POWER-OWNERSHIP matrix (operator
+  proposal, 2026-08-01) asking for each domain: who owns its power, and what happens when that
+  owner goes away -- a question `autostart` alone cannot express.
   **RESULT: host used 809 -> 63 GiB, available 197 -> 944 GiB** -- the restarts also released
   the stranded RSS (vvr1-dc1 354 -> 12 GiB, its 6.6 GiB swap freed), which is F1 of the 08-01
   sweep discharged as a side effect. Recovery verified END TO END: MAAS region API
diff --git a/docs/changelog-20260731-snap-proxy-apply-ipv6.md b/docs/changelog-20260731-snap-proxy-apply-ipv6.md
index 6674a21..c52c9be 100644
--- a/docs/changelog-20260731-snap-proxy-apply-ipv6.md
+++ b/docs/changelog-20260731-snap-proxy-apply-ipv6.md
@@ -1083,3 +1083,36 @@
 **Revert.** `git checkout -- scripts/preflight.sh tests/preflight/run-tests.sh`.
 For item 21: set both variables back to `425984` and re-apply (this bounces both guests
 again); `sudo swapoff /swap2.img && sudo rm /swap2.img` and drop the fstab line.
+
+---
+
+## Item 23 -- CORRECTION to item 21's autostart finding. NO autostart setting was changed.
+
+**Operator asked directly whether I had changed any autostart setting. I had not** -- item 21
+logged it under hard rule 1 and started the two VMs by hand. Asked in order to scope a new
+session for a power-settings matrix, which prompted the check that shows **I framed the
+finding wrongly.**
+
+**D-127 ALREADY RULES THIS**, and autostart is TOFU-MANAGED with an explicit per-instance
+value and reason: containment VMs `false` ("MANUAL (gated bring-up), never on host boot"),
+voffice1 + office1-opnsense `true` ("foundational"), DC edges `true`, node VMs `false`
+("MAAS-power-controlled"). The module variable's description explicitly says not to rely on
+its default. **So the measured state is the ruled design, not an oversight** -- and a session
+told to "fix autostart" would fight a ruling AND, now that P8 exists, register as substrate
+drift.
+
+**THE NARROWER FINDING THAT SURVIVES, and it is the one worth the matrix:**
+`vr1-dc0-maas-01` and `vr1-dc0-juju-01` are created by the `vr1_dc0_node` `for_each`, so they
+inherit the NODE justification "MAAS-power-controlled". True for the juju controller
+(`subtle-grouse`, a dc0-region machine with `power_type=virsh`). **CIRCULAR for the MAAS region
+VM**: `hot-kid`'s power is owned by the **Office1** region -- the region D-132 q1 is migrating
+away from. **Retire Office1 and nothing owns the dc0 region VM's power, while it does not
+autostart.** An ordering exposure in the migration, not an autostart bug.
+
+**WHY A MATRIX IS THE RIGHT INSTRUMENT (operator proposal):** `autostart` is a boolean that
+cannot express *who owns this VM's power* or *what happens when that owner goes away*. Those
+are the questions that surface the circularity above, and they apply per-DC at every future
+standup. Seed inventory measured 2026-08-01 -- 4 outer domains, 12 dc0 inner, 11 dc1 inner;
+exactly four carry `autostart=enable` (voffice1, office1-opnsense, and the two DC edges).
+
+**Revert.** Nothing to revert -- no setting was changed and no artifact beyond this record.