diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index c9d8424..663694f 100644
--- a/docs/re/BACKLOG.md
+++ b/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
diff --git a/docs/re/mission-wave-arrivals.md b/docs/re/mission-wave-arrivals.md
index fbf81fc..0b6e74d 100644
--- a/docs/re/mission-wave-arrivals.md
+++ b/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.