diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index f350b837..35b38210 100644
--- a/docs/re/BACKLOG.md
+++ b/docs/re/BACKLOG.md
@@ -494,6 +494,19 @@ search cannot find a *schedule*.
   at TAKE-OFF**, not a schedule unfolding in-mission (different runs, so
   suggestive only). **Next: one ~400 s run spanning ready room → take-off →
   flight** to catch the 39→41 step in one continuous series.
+* ✅🔴 **(2026-08-24) DEPLOYMENT IS RESOLVED AT MISSION LOAD.** One continuous
+  series, 64 samples over ~380 s from roster-appearance through the ready room,
+  take-off (`IN FLIGHT` at +47 s) and flight: **`deployed=41, craft=292`, zero
+  changes throughout.** 🔴 **My own "deployment happens at take-off" is withdrawn**
+  — the 39/276 vs 41/300 gap was cross-run variance; within one run there is no
+  step. ⇒ **Stage 02 phase 1 has NO observable in-mission arrival**: 41 of 116
+  records are deployed before the ready room ends, and nothing changes in the
+  ready room, at take-off, or in up to 435 s of verified-live flight with 42
+  kills. Route times most likely encode **fly-in animation timing applied at
+  load**, not release times (frames reading: S01's t=2100 → 70 s at 30 Hz).
+  ❔ **Phases 2 and 3 are entirely untested** — every run has stayed in phase 1,
+  and phase advance was never located; a phase transition is now the most likely
+  place an arrival could exist.
   🔴 `SYLPH_HZ=3` refuted as a lever: it gave the LOWEST frame rate (8/s) with the
   most kills, so pilot polling is not the throttle.
 * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;
diff --git a/docs/re/mission-arrival-watch.md b/docs/re/mission-arrival-watch.md
index 7442cebb..4e906dae 100644
--- a/docs/re/mission-arrival-watch.md
+++ b/docs/re/mission-arrival-watch.md
@@ -612,3 +612,57 @@ unfolding during the mission.
 **Next:** one run with the probe waiting for the roster and sampling for ~400 s,
 long enough to span ready room → take-off → flight in a single continuous
 series. That would show the 39 → 41 step directly, or refute it.
+
+---
+
+# ✅ Deployment is resolved at mission LOAD (2026-08-24)
+
+The run that was supposed to catch a take-off step instead removed the
+hypothesis. One continuous series, 64 samples over ~380 s, started when the
+roster appeared and running through the ready room, take-off (`IN FLIGHT` at
++47 s) and the whole flight:
+
+```
++    0.3s  deployed= 41  craft=292
+   … 64 samples, ZERO changes …
+last     deployed= 41  craft=292
+```
+
+**Not one change in either number**, across the ready room, the transition, and
+several minutes of flight.
+
+## 🔴 Refuted: my own "deployment happens at take-off"
+
+The previous entry noted ready room 39/276 against flight 41/300 and suggested
+deployment was a single step at take-off, flagged 🟡 because the numbers came
+from *different runs*. Measured within one run, there is no step: the values are
+identical before and after take-off. **That was cross-run variance and the
+hypothesis is withdrawn.**
+
+## What this establishes
+
+**The roster is already deployed when the roster first exists** — 41 of 116
+records hold craft before the ready room ends, and nothing changes afterwards.
+Combined with everything else in this file:
+
+* every participant is allocated at mission load (roster identity, two stages);
+* 41 of 116 records are deployed from the first observable instant;
+* no `0 → n` transition occurs in the ready room, at take-off, or in up to 435 s
+  of verified-live flight with 42 kills.
+
+So **Stage 02 phase 1 has no observable in-mission arrival at all.** Whatever the
+route table's first-keyframe times do, they do not release squadrons on a clock
+that this instrumentation can see, and they do not respond to the player
+destroying 42 craft.
+
+## What remains open
+
+* The route times still mean *something* — the values 0/90/120/170/210/240 and
+  S01's 1500/1800/2100 are structured, not noise. The frames reading
+  (t = 2100 → 70 s at 30 Hz) remains the best fit, in which case they are most
+  likely **fly-in animation timings applied at load**, not release times.
+* Phases 2 and 3 are entirely untested. Every run has stayed in phase 1, and
+  phase advance was never located. If arrivals exist, a phase transition is the
+  most likely place to see one.
+* This run had **no pilot**, so it says nothing new about event-gating; the
+  piloted 435 s run already covers that.