diff --git a/docs/re/mission-arrival-watch.md b/docs/re/mission-arrival-watch.md
index 4e906da..e3d2d48 100644
--- a/docs/re/mission-arrival-watch.md
+++ b/docs/re/mission-arrival-watch.md
@@ -1,8 +1,19 @@
 # Six runs, no arrival — and an accidental control
 
+> 🔴 **SUPERSEDED 2026-08-25 — the premise was an instrument limit, not a fact
+> about the game.** Arrivals *do* happen and are directly observable in the
+> script VM's per-unit table: ADN110/111/112 flip from "not deployed" to
+> "active" at ~143 s, matching their routes' `t=170` timetable entry, while the
+> count of active records climbs 24 → 35 in four minutes. Everything below
+> remains accurate about **craft counting**, which conflates deployment with
+> attrition and cannot see an arrival. See
+> [script-runtime-probe](script-runtime-probe.md) and
+> [mission-wave-arrivals](mission-wave-arrivals.md).
+
 Status: ✅ the deployment structure reproduces exactly; ✅ losses require the
-player; 🔴 **no arrival has ever been observed**, across six runs; ❔ whether
-mission/phase time is advancing at all is now the prime suspect and is untested.
+player; ~~🔴 no arrival has ever been observed~~ — **superseded, see the banner above**;
+the "is mission time advancing at all?" suspicion is also answered: it is, and
+the timetable is in seconds.
 
 ## ✅ The deployment structure reproduces byte-for-byte
 
diff --git a/docs/re/mission-wave-arrivals.md b/docs/re/mission-wave-arrivals.md
index 00c3084..518fc12 100644
--- a/docs/re/mission-wave-arrivals.md
+++ b/docs/re/mission-wave-arrivals.md
@@ -1,9 +1,14 @@
 # The arrival timetable, and what the entity table is really counting
 
-Status: ✅ the static arrival timetable is in `Route_S<NN>.tbl`; 🟡 the runtime
-entity table appears to be one record per roster member, pre-allocated (n = 1);
-🔴 counting entity records does **not** show wave arrivals; ❔ the timetable's
-time unit is still unmeasured.
+Status: ✅ the static arrival timetable is in `Route_S<NN>.tbl`;
+✅ **arrivals ARE observable — and the time unit is SECONDS** (2026-08-25, see
+below); 🔴 counting *entity records* does not show them, which is what the
+original negative measured.
+
+> ✅ **CORRECTION 2026-08-25.** "Counting entity records does not show wave
+> arrivals" is still true, but the conclusion drawn from it — that arrivals
+> could not be seen — was wrong. The **script VM's own unit table** shows them
+> directly. See [script-runtime-probe](script-runtime-probe.md).
 
 ## ✅ The arrival timetable is the routes' first keyframe time
 
@@ -23,6 +28,33 @@ is measured **from the start of its phase**, not from the start of the mission.
 Entering a phase releases that phase's t = 0 group, and the rest arrive on the
 offsets above.
 
+## ✅ The timetable is confirmed live, and `t` is in SECONDS
+
+The three squadrons the phase-1 clear condition polls — ADN110, ADN111, ADN112 —
+all have **first-keyframe time `170`** on their `_p1F` routes:
+
+```
+Route_ADN110_p1F  FrameCount=3  first field: 170
+Route_ADN111_p1F  FrameCount=3  first field: 170
+Route_ADN112_p1F  FrameCount=2  first field: 170
+```
+
+In a live run (`data/phase-watch-s02.txt`) all three flipped from
+state 1 (not deployed) to state 2 (active) at **~143 s on the probe's clock**.
+The probe starts after flight entry and after the pilot bind, so its zero sits
+roughly 10–20 s into the mission — putting the arrival at about **155–165 s of
+mission time against a predicted 170**.
+
+**That pins the unit as seconds.** The alternatives are not close: 170 *frames*
+at 30 fps is 5.7 s, so those squadrons would have been active at the first
+sample, and they demonstrably were not. Three squadrons sharing one timetable
+entry all changing state in the same 5 s sampling window is not coincidence.
+
+⚠️ It is a **match, not an exact measurement** — the probe clock is not aligned
+to phase start, so this bounds the unit rather than verifying the value to the
+second. Logging mission start and phase start in the same stream would close
+that.
+
 That is the "algorithm with parameters" this line of work was after: the
 schedule is data — squadron, phase, arrival time, and the path flown in — spread
 across `UnitGroup` (who) and `Route` (when and from where). Stage 02 phase 1