diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index 45a90bf..c9d8424 100644
--- a/docs/re/BACKLOG.md
+++ b/docs/re/BACKLOG.md
@@ -322,8 +322,11 @@ search cannot find a *schedule*.
   ❔ Still unmeasured: whether the timetable's `t` is frames or seconds.
 * 🔴 **Diffing inside the 116 records did not find the arrival flag**
   (2026-08-24, same doc). 10 of 116 records are dynamic, 106 never change a byte
-  in 170 s — more support for the pre-allocated roster, though turret-heavy S02
-  means "inert" ≠ "not arrived". No field transitions in groups of 3 at the
+  in 170 s — more support for the pre-allocated roster — and STRONGER than
+  first written: the "turrets don't move" hedge was withdrawn after the user
+  pointed out that early-mission "Turret" is a craft type, which the data
+  confirms (`UN_e007_ADAN_Turret` flies under `AI_ADAN_CraftSquadron_*`, never
+  `AI_Structure`). Lesson: check a unit's `AIID`, not its English name. No field transitions in groups of 3 at the
   predicted times. **Blocked on two of my own defects**: the record→unit-ID
   label resolved to `?` for all 116 (reuse `unit_discover.py`, do not re-derive),
   and `RECLEN=0x200` was assumed, not measured — the busiest fields sit at the
diff --git a/docs/re/mission-wave-arrivals.md b/docs/re/mission-wave-arrivals.md
index a5689f5..fbf81fc 100644
--- a/docs/re/mission-wave-arrivals.md
+++ b/docs/re/mission-wave-arrivals.md
@@ -103,10 +103,38 @@ That is a second, independent line of support for the reading in the section
 above: if all 116 were live entities they would be moving, and position words
 would churn in most of them every tick. Instead the overwhelming majority are
 inert, which is what a pre-allocated roster of not-yet-activated members looks
-like. It is still not proof — Stage 02's roster is heavy with
-`UN_e007_ADAN_Turret` entries, and a turret does not move even when it is very
-much alive, so "inert" and "not yet arrived" are not distinguishable from this
-run alone.
+like.
+
+**Correction (2026-08-24, from the user).** The first version of this paragraph
+hedged the conclusion by saying Stage 02's roster is heavy with
+`UN_e007_ADAN_Turret` and "a turret does not move even when it is very much
+alive", so inert and not-yet-arrived could not be told apart. **That hedge was
+wrong, and it was wrong because I read the unit's English name instead of its
+data.** "Turret" in the early missions is a *craft* — a distinct enemy type — not
+an anti-aircraft mount on a capital ship. The tables say so plainly:
+
+| | |
+|---|---|
+| `UN_e007_ADAN_Turret` | `AI_ADAN_CraftSquadron_Rookie` ×70, `AI_ADAN_CraftSquadron_Veteran` ×19 |
+| `UN_e007_ADAN_Turret_EX4` | `AI_ADAN_CraftSquadron_Ace` ×4 |
+| `AI_Structure` is used by | asteroids, `UN_mn500_ADAN_FloatingMine`, `UN_bf001_TCAF_SchlosBase`, `UN_bf002_TCAF_TransitPlatform`, `UN_be005_ADAN_SpaceFortress` |
+
+`AI_ADAN_CraftSquadron_*` is `Type = Squad` in
+[`AIParams`](structures/stage-mission-tables.md), with the full manoeuvre-weight
+block — these things fly. `AI_Structure` exists precisely for the units that do
+not, and no `*_Turret` unit ever uses it. The type also matches "an enemy of the
+first few missions": 93 turret members in total, in S01 (20), S02 (21), S03 (11),
+S04 (6), S05 (12), S06 (19), and then nothing until S27 (4).
+
+So the caveat is withdrawn, and removing it makes the evidence **stronger**, not
+weaker: the 106 inert records cannot be explained away as immobile scenery,
+because Stage 02's turrets are craft that should be manoeuvring. The reading
+that they are pre-allocated, not-yet-activated roster entries survives a test it
+would otherwise have dodged.
+
+The general lesson, which cost a wrong hedge: **do not infer a unit's behaviour
+from its English name — check its `AIID`.** The roster is self-describing and
+the answer was already in the committed dump.
 
 ## 🔴 No transition matching the arrival timetable