re: record the event-gated wave model as a competing hypothesis

The user proposed that a wave may be released by an event -- enemies destroyed,
an objective completed -- rather than at a fixed time, with the route's
first-keyframe time being a delay after the trigger. It fits the evidence better
than the clock model I had been assuming, and it explains a result I had left as
an open puzzle.

Both probe runs used the survival pilot, whose job is to stay alive rather than
shoot, and both saw no arrivals at all. A clock model says arrivals at
t = 90/120/170 happen regardless of what the player does. An event model says a
player who kills nothing triggers nothing, which is what was measured.
DisableInterval also gains a plausible referent: a pure timetable in the route
table would not need a per-squadron flag to switch a gating interval off.

Supporting evidence, cross-tabulated across all stages: no squadron with
DisableInterval=Yes has a delayed route (55 of 55 at t=0), while all 68 delayed
routes belong to squadrons with DisableInterval=No. If independent, about 3.7
such routes would be expected; P(zero) is roughly 0.02.

Kept at 🟡 and explicitly not promoted. A p ~ 0.02 association on a single
derived statistic is the same shape of near-fit as the "109 of 111" squadron
name base that already misled this corpus once. Name matching itself is sound --
for Stage 02, 108 of 111 squadrons have routes.

Records the test that separates the models: the same stage flown twice, killing
nothing versus killing aggressively, with REMAINING OB at 0xbdb59668 as the
cheap precondition check since it needs no new decoding. That test still depends
on the record-to-squadron labelling defect noted in the previous commit.

docs/re/BACKLOG.md

@@ -320,6 +320,16 @@ search cannot find a *schedule*.
   record per member (n=1, NOT promoted; the refutation needs another stage's
   save, which we do not have — only slot 01 / Stage 02 exists).
   ❔ Still unmeasured: whether the timetable's `t` is frames or seconds.
+* 🟡 **COMPETING MODEL (user, 2026-08-24): waves are event-gated, not
+  clock-driven** — released by kills/objectives rather than at a fixed time, with
+  the route's start time being a post-trigger delay. Fits the evidence better:
+  both probe runs used the *survival* pilot (kills nothing) and saw no arrivals,
+  which a clock model does not explain. `DisableInterval` also gains a referent.
+  🟡 Supporting: no `DisableInterval=Yes` squadron has a delayed route (55/55 at
+  t=0, vs ~3.7 expected if independent, p≈0.02) — suggestive, NOT conclusive,
+  deliberately not promoted. **Test:** same stage twice, kill nothing vs kill
+  aggressively; cheapest precondition is whether `REMAINING OB` (`0xbdb59668`)
+  moves in one and not the other.
 * 🔴 **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 — and STRONGER than

docs/re/mission-wave-arrivals.md

@@ -178,3 +178,70 @@ So one of these is true, and this run cannot say which:
 Fix the record→squadron association first (reuse `unit_discover.py`), and
 measure the record stride instead of assuming `0x200`. Until a record can be
 named, no diff of these records can confirm or refute an arrival.
+
+---
+
+# Competing model: waves are event-gated, not clock-driven (2026-08-24)
+
+Status: 🟡 plausible and partly supported; ❔ untested. **Raised by the user**,
+and it is a better fit to the evidence than the pure-clock reading I had been
+assuming.
+
+## The proposal
+
+The next wave may not arrive at a fixed time at all. It may be released when
+some condition is met — a number of enemies destroyed, an objective completed,
+or another event — with the route's first-keyframe time being a *delay after the
+trigger*, or simply the start of the fly-in animation once released.
+
+## Why it fits better than the clock model
+
+* **My two runs showed no arrivals.** Both were flown by the survival pilot,
+  whose job is to stay alive, not to shoot. Under a clock model, arrivals at
+  t = 90/120/170 should have happened regardless of what the player did, and
+  nothing appeared. Under an event model, a player who kills nothing triggers
+  nothing — which is exactly what was observed. This is weak evidence (the
+  proxy may simply not show arrivals) but it points the right way.
+* **`DisableInterval` finally has a plausible referent.** The name implies a
+  gating *interval* that squadrons can opt out of. A pure timetable in the route
+  table would not need a per-squadron flag to disable it.
+
+## 🟡 The flag and the delayed routes do not co-occur
+
+Cross-tabulating every squadron's `DisableInterval` against the start time of
+its routes, across all stages:
+
+| | route t=0 | route t>0 |
+|---|---|---|
+| `DisableInterval = No` | 876 | 68 |
+| `DisableInterval = Yes` | **55** | **0** |
+
+No squadron that disables the interval has a delayed route. If the two were
+independent we would expect about 3.7 such routes; the probability of seeing
+zero by chance is roughly **0.02**. That is suggestive, **not** conclusive, and
+it is recorded at 🟡 deliberately — a p ≈ 0.02 association on one derived
+statistic is exactly the kind of near-fit that has already misled this corpus
+once (the "109 of 111" squadron-name base in
+[structures/unit-group-table.md](structures/unit-group-table.md)).
+
+Name matching for this table is sound: for Stage 02, 108 of 111 squadrons have
+routes and 113 route names resolve, so the cross-tab is not an artefact of
+failed joins.
+
+## The test that separates the two models
+
+Two runs of the same stage, differing only in what the player does:
+
+* **Run A — kill nothing.** Evade for ~250 s. Clock model predicts arrivals
+  anyway; event model predicts none.
+* **Run B — kill aggressively.** Event model predicts arrivals that track kills,
+  not the clock.
+
+If Run B produces activity that Run A does not, the schedule is event-gated and
+the route times are post-trigger delays. This needs the record→squadron
+labelling fixed first, otherwise neither run can say *which* squadron arrived —
+the blocker already recorded above.
+
+A cheaper precondition worth checking first: whether `REMAINING OB` at
+`0xbdb59668` moves in Run B but not Run A. That is a known-good counter and
+needs no new decoding.