diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index 02a3919..9df439b 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -641,10 +641,15 @@
   concurrency works and the migration does not need the root cause to proceed. **LOGGED for
   the dc1 standup and Roosevelt: do not power on a whole rack for enlistment at once.**
   **BATCHED RE-ENROLMENT WORKS AND PINS THE ROOT CAUSE. Batch 1 (control-01/02/03) enlisted
-  in 2.3 MINUTES** against the 15-minute zero-record stall for nine, **and all three went
-  straight to `Ready` with NO `New` detour** -- because their power config was set BEFORE
-  `commission` was issued, where the canary was commissioned first and powered afterwards.
-  That supersedes the "one-off" reading: the detour is CAUSED BY ORDERING. **Revised standing
+  in 2.3 MINUTES** against the 15-minute zero-record stall for nine, **and all three reached `Ready` on the FIRST
+  commission** -- because their power config was set BEFORE `commission` was issued, where
+  the canary was commissioned first and powered afterwards. That supersedes the "one-off"
+  reading: the extra commission is CAUSED BY ORDERING. **PRECISION, because an earlier
+  wording here overstated it: batch 1 did pass THROUGH `New`** -- I aborted them there
+  deliberately to clear the enlistment-time wedge. The real distinction is not whether a
+  machine visits `New` (every one does, either by self-settling or by `abort`) but whether
+  the commission ISSUED FROM `New` succeeds first time. With `power_type` set it does; without
+  it, it passes every script and drops back to `New`. **Revised standing
   procedure: `delete -> virsh start -> self-enlist -> SET POWER -> abort -> commission`, and
   NEVER issue `commission` on a machine whose `power_type` is unset.** Enlist in batches of
   three. Region now holds **4 machines, all `Ready`** (`civil-bug` storage-04, `mint-roughy`
diff --git a/docs/changelog-20260730-dc0-region-migration.md b/docs/changelog-20260730-dc0-region-migration.md
index deec2f6..f6f748f 100644
--- a/docs/changelog-20260730-dc0-region-migration.md
+++ b/docs/changelog-20260730-dc0-region-migration.md
@@ -792,12 +792,18 @@
 **Batch of three (control-01/02/03): enlisted in 2.3 minutes** against a 15-minute stall
 with zero records for nine. Batching is the working procedure.
 
-**The more useful result: all three went straight to `Ready` with NO `New` detour.** The
-canary needed a second commission; these did not. The difference is that their power config
-was set BEFORE `commission` was issued, whereas the canary was commissioned first and had
-power set afterwards. So the canary's detour was **caused by the ordering, not by chance** --
-which is a stronger and more useful conclusion than the earlier "one-off", and it supersedes
-it.
+**The more useful result: all three reached `Ready` on the FIRST commission.** The canary
+needed a second; these did not. The difference is that their power config was set BEFORE
+`commission` was issued, whereas the canary was commissioned first and had power set
+afterwards. So the canary's extra commission was **caused by the ordering, not by chance** --
+a stronger and more useful conclusion than the earlier "one-off", and it supersedes it.
+
+**PRECISION, correcting my own first wording of this item.** I originally wrote that batch 1
+went "straight to `Ready` with no `New` detour". That is wrong: I aborted them to `New`
+myself, to clear the enlistment-time wedge. EVERY machine passes through `New` -- either by
+self-settling there (batch 2 did, before I could abort) or by an explicit `abort`. The real
+distinction is whether the commission ISSUED FROM `New` succeeds on the first try, and that
+is what `power_type` decides.
 
 **REVISED per-node procedure, now evidenced twice:**