diff --git a/docs/changelog-20260730-dc0-node-carve.md b/docs/changelog-20260730-dc0-node-carve.md
index 05be3fc..9bec109 100644
--- a/docs/changelog-20260730-dc0-node-carve.md
+++ b/docs/changelog-20260730-dc0-node-carve.md
@@ -300,3 +300,37 @@
 
 **Revert.** `juju kill-controller vr1-dc0-controller` (the controller API is up this time,
 so unlike attempt 3 this WILL work), then release `arfr7p` in MAAS.
+
+## Item 9 -- FINDING (logged, not fixed): `preflight.sh` is REGION-BLIND
+
+**What.** `DC=vr1-dc0 bash scripts/preflight.sh` on voffice1 reports:
+
+    PASS: MAAS reachable (profile=admin)
+    FAIL: vr1-dc0-control-01 not enrolled in MAAS      (x10, every machine)
+    FAIL: host vr1-dc0-control-01 not found in MAAS     (x9)
+
+**All nineteen are FALSE NEGATIVES from a wrong-region instrument.** `admin` is the
+OFFICE1 profile; dc0's ten machines were migrated to the per-DC region and are all `Ready`
+there -- measured minutes earlier, and confirmed by re-running with
+`MAAS_PROFILE=vr1-dc0-region`, which drops the node failures to **zero**.
+
+**Why this matters more than a wrong flag.** The message says "not enrolled in MAAS", which
+reads as a deployment-state problem. The true statement is "you are asking the wrong
+region". A session that trusted it would go looking for a broken enrolment that does not
+exist -- the same confident-well-formed-wrong-evidence class as the stale serial log.
+
+**`pre-flight-checks.sh:64` is `MAAS_PROFILE="${MAAS_PROFILE:-admin}"`.** This is the FOURTH
+consumer of that default; CURRENT-STATE already lists `dc-plane-ipam.sh`,
+`maas-role-tags.sh` and `maas-node-power.sh` as owing the same wiring, and preflight was not
+among them.
+
+**NOT FIXED, and the fix is not the obvious one (hard rule 1).** A blanket "refuse `admin`
+for `vr1-*`" would be WRONG: **dc1's nine nodes still live in Office1**, so `admin` is
+currently the CORRECT profile for `DC=vr1-dc1`. The right shape is to resolve the profile
+per-DC from a mapping and assert region identity (rack identity, per
+`maas-profile-assert.sh`) rather than to refuse a token. That needs its own change with a
+harness, and it does not block this deploy now that the profile is passed explicitly.
+
+**Workaround, and it must be carried forward:** every preflight run for dc0 needs
+`MAAS_PROFILE=vr1-dc0-region` until this is fixed. With it, preflight is RED on **P5 only** --
+the ruled-accepted credential register -- and P1-P4 + P7 all PASS.