# The arrival timetable, and what the entity table is really counting Status: βœ… the static arrival timetable is in `Route_S.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 Each record in `Route_S.tbl` starts with a time ([structures/stage-mission-tables.md](structures/stage-mission-tables.md)), and that time is **not** always zero. For Stage 02, grouping the 120 route records by phase and by first-frame time gives a timetable: | phase | t=0 | 50 | 60 | 90 | 120 | 150 | 170 | 210 | 240 | |---|---|---|---|---|---|---|---|---|---| | 1 | 25 | | | 3 | 3 | | 3 | 2 | 1 | | 2 | 37 | | | | | | | | | | 3 | 36 | 1 | 1 | 3 | | 1 | | 4 | | Phase 2 has **every** route at t = 0, which is the useful detail: it means `t` 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 spawn points span x ∈ [-47371, 20800], y ∈ [-18856, 27395], z ∈ [-25349, 25036]. ❔ **The time unit is not measured.** At 30 Hz, t = 240 is 8 s; as seconds it is 4 min. Distinguishing them was the point of the run below, and the run did not manage it. ## πŸ”΄ Counting entity records does not show arrivals One Stage 02 flight, 210 s sampled every 15 s, counting aligned occurrences of the spawned-entity vtable `0x820af030` ([structures/unit-struct-runtime.md](structures/unit-struct-runtime.md)) in an 8.3 MB span of guest RAM: ``` t=0s 116 t=45s 116 t=90s 116 t=135s 116 t=180s 116 t=210s 116 ``` Perfectly flat. No steps at 90, 120, 170, 210 or anywhere else. The hypothesis that a live entity count would step up at the timetable's offsets is **refuted for this proxy** β€” but the reason matters more than the refutation. ## βœ… 116 records, 116 roster members β€” confirmed by composition (2026-08-24) **Promoted from 🟑 to βœ….** The section below argued from a single number, 116 = 116, and explicitly refused to promote it on that. It is now confirmed on a far stronger test: with the records labelled (see the labelling section at the end of this file), the **multiset of unit types** matches the static roster exactly, not just the total. | unit | static roster | live records | |---|---|---| | `UN_e007_ADAN_Turret` | 21 | 21 | | `UN_e106_ADAN_Destroyer` | 19 | 19 | | `UN_f106_TCAF_Destroyer` | 14 | 14 | | `UN_f105_TCAF_Cruiser` | 11 | 11 | | `UN_e108_ADAN_ASFrigate` | 9 | 9 | | `UN_e201_ADAN_ISCMissile` | 9 | 9 | | `UN_e010_ADAN_Attacker_S` | 9 | 9 | | `UN_e105_ADAN_Cruiser` | 7 | 7 | | `UN_f001_TCAF_DeltaSaber_T` | 7 | 7 | | `UN_f003_TCAF_ArrowHead` | 6 | 6 | 10 of 10 exact, across counts from 21 down to 6. A coincidental total can happen; a coincidental *distribution* over ten unit types cannot. The game allocates one entity record per `UnitGroup` roster member at mission load, and every one of them exists from the first sample β€” long before the member could have "arrived". ## 🟑 116 records, 116 roster members (original argument, superseded above) `UnitGroup_S02.tbl` has 111 squadrons whose `Count` fields sum to **116** members. The entity table holds **116** records, from the first sample onwards. The natural reading is that the game allocates **one entity record per roster member when the mission loads**, and that arriving on a route makes an existing record active rather than creating a new one. That would explain the flat count exactly, and it would mean `0x820af030` records are a *roster*, not a live population β€” consistent with the existing note in `unit-struct-runtime.md` that these records are "not live state". **This is one data point and must not be promoted on it.** 116 = 116 is a striking match but n = 1, and the obvious refutation has not been run: load a *different* stage and check the record count against that stage's member sum (S01 = 42, S10 = 14, S16 = 2, S29 = 95). S16 with 2 members would be decisive and cheap if a save for it existed β€” the only save slot available is Stage 02, which is the blocker. ## What this run did not settle * The timetable's time unit (frames vs seconds). * Whether arrivals are visible at all from memory, and where. The live/dead flag is presumably a field *inside* the 116 records; diffing those records over a mission is the obvious next probe, and it is well scoped now that the record set is bounded and located. * Whether the 116↔116 match generalises. ## Operational note Cold, the boot spent **204 s** in the title movie before the first β’Ά β€” the `wait_screen` oracle correctly refused to tap through it. A 300 s probe plus that boot exceeded a 580 s turn budget and the first attempt was killed with its output still in the pipe. Log runs to a file (`> /tmp/x.log 2>&1`) rather than piping to `tail`, or a timeout loses the evidence as well as the run. --- # Follow-up: diffing inside the 116 records (2026-08-24) Status: 🟑 supporting evidence for the pre-allocated-roster reading; πŸ”΄ the arrival flag was **not** found; πŸ”΄ two defects in my own probe recorded. The count being flat meant an arrival must flip a field *inside* a record, so this diffed all 116 records (0x200 bytes each) every 5 s for 170 s of Stage 02 flight, under the pilot. `tools/re-capture/wave2_probe.py`. ## 🟑 Only 10 of 116 records are dynamic Across the whole run, **10 distinct records** ever changed a byte. The other **106 never changed at all** β€” not one word, over 170 s of live mission. 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. **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 The prediction under test was groups of 3, 3, 3, 2, 1 records changing state at t = 90, 120, 170, 210, 240 s. Nothing of the sort appeared. Field-change events are spread evenly across ticks (1–7 words per 5 s tick, 1052 in total), with no cluster at any predicted time and no field that transitions once for exactly three records. So one of these is true, and this run cannot say which: * the timetable's `t` is **not** seconds (at 30 Hz the whole phase-1 schedule finishes inside the first 8 s, before the probe's first sample); * arrival is not marked in the `0x820af030` record at all; * phase 1 was not where the mission actually was during the run. ## πŸ”΄ Two defects in this probe * **`label()` failed for all 116 records** β€” every one resolved to `?`. The `object+0x04 β†’ name_record+0x10 β†’ char*` chain from [structures/unit-struct-runtime.md](structures/unit-struct-runtime.md) did not resolve here. Without labels the records cannot be tied back to squadrons, which is exactly what would have made the result decisive: "these three records that changed at t=90 are `ADN110`, `ADN111`, `ADN112`" is evidence, "records 18, 32, 99" is not. `unit_discover.py` already solves this association and should be reused rather than re-derived. * **`RECLEN = 0x200` is probably too wide.** The busiest fields by far are `+0x1e0 … +0x1fc` β€” the last eight words of the window β€” which is what spilling into the *next* object looks like. The record's true size was assumed, not measured. * **A method error worth keeping:** the first attempt deferred all analysis to the end of the run, and the turn's timeout killed it with 240 s of collected data still in memory and nothing written. The probe now streams every transition to `/tmp/wave2-trans.tsv` and prints a partial ranking every 60 s. Combined with the 219 s cold-boot title movie, a run that only reports at the end has perhaps 300 s of usable budget and one bad estimate loses everything. ## Next 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)). ### ❌ WITHDRAWN (2026-08-26) β€” the p β‰ˆ 0.02 does not survive the clustering The caution above was right and did not go far enough. Breaking the same cross-tab down **by stage** destroys the result: | stage | No, t=0 | No, t>0 | **Yes, t=0** | **Yes, t>0** | |---|---|---|---|---| | S04 | 42 | 5 | **10** | 0 | | S14 | 22 | 0 | **45** | 0 | | the other 9 stages with delayed routes | 836 | 63 | 0 | 0 | All 55 `DisableInterval = Yes` routes live in **two** stages, and **45 of them are in S14, which has no delayed route at all** β€” no squadron there is delayed whether it sets the flag or not, so those 45 cannot be evidence of anything. Only **one** stage, S04, contains both a `Yes` squadron and a delayed route. The pooled p β‰ˆ 0.02 treated 1 023 routes as independent draws when they are really two clusters. The test that actually bears on the hypothesis is within S04, and there it is: P(none of S04's 5 delayed routes belongs to one of its 10 Yes squadrons) = C(47,5) / C(57,5) = 0.37 Expected count under independence: **0.88**, observed **0**. That is entirely unremarkable. **The association is not supported by the data**, and the "`DisableInterval` finally has a plausible referent" reading above rests on the name alone, not on this table. 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. --- # Labelling the records, and the real stride (2026-08-24) Status: βœ… both defects from the previous section are fixed and measured. ## βœ… The id chain: `record+0x04` β†’ pointer β†’ `+0x00` The previous probe assumed `object+0x04 β†’ name_record+0x10 β†’ char*` and resolved **0 of 116**. `tools/re-capture/wave3_probe.py` searches for the chain instead of assuming one β€” for each record it walks the first 24 words, treats any guest-range word as a pointer, chases it, and accepts the result only if it lands on a `UN_`/`NP_`-prefixed string, optionally through one more indirection. Result: **116 of 116 resolved**, every one by the same chain β€” pointer at `+0x04`, string at delta **`0x00`**, not `0x10`. The `0x10` in [structures/unit-struct-runtime.md](structures/unit-struct-runtime.md) is the delta for the *definition* object (vtable `0x820af844`); the spawned-entity record (`0x820af030`) uses `0x00`. Assuming one from the other is what cost the previous run. ## βœ… The stride is variable β€” `0x200` was wrong Measured gaps between consecutive record addresses: **min 32, median 800**, with common values 800, 640, 608, 576, 416 and 32. There is no fixed record size, so the previous probe's `RECLEN = 0x200` window both truncated large records and ran past small ones into their neighbours β€” which is exactly why its busiest "fields" were the last words of the window. Any future diff must bound each record by the *next* record's address rather than by a constant. ## ❔ `REMAINING OB` at `0xbdb59668` did not read as a counter this run It held `95748078` for the whole run, unchanging. That address is known to be run-dependent ([structures/mission-objective-counter.md](structures/mission-objective-counter.md) records it recurring in about 5 runs of 7), and this was one of the misses, so the run cannot say whether the pilot killed anything. Re-hunting the counter with `ob_hunt.py` is a precondition for the kill-versus-no-kill test, not an optional extra. --- # Hunting run (2026-08-24) β€” and a withdrawal Status: βœ… a hunting pilot exists and engages; πŸ”΄ the "10 of 116 records are dynamic" result is **withdrawn**; ❔ the wave question is still open, and the entity scan is too noisy to settle it. The user asked for an actively hunting pilot, with attention to the objectives, because the two previous runs used the *survival* pilot and a player who kills nothing cannot trigger an event-gated wave. ## βœ… `SYLPH_HUNT=1` `pilot.py` gained a hunt mode. The change that matters is which contacts ENGAGE is allowed to shoot: it previously skipped every "hard" target with the comment *"turrets and hulls are not the objective"*, and kept 2500 units away from turrets. That was written on the assumption that an `e007` "Turret" is an anti-aircraft mount on a capital ship. It is not β€” it is a craft, one of the main enemy types of the first six missions (`AI_ADAN_CraftSquadron_*`, `Type = Squad`), and at 100 HP the cheapest kill on the field. Under `SYLPH_HUNT=1` turrets are targets and the keep-out drops to 600. The run confirms it flies and shoots: steady `ENGAGE`, `fire=1`, committed to `e010_ADAN_Attacker_S` at ~2.2 km, hull 1500/1500 and escorted asset at 100 % throughout 160 s. ## πŸ”΄ Withdrawn: "only 10 of 116 records are dynamic" The previous section reported that 10 of 116 records ever changed a byte in 170 s, and used it as supporting evidence for the pre-allocated roster. **This run measured 41–56 records changing in every single 10 s tick.** The earlier figure does not reproduce and is withdrawn. I cannot say why, because I changed two things at once β€” the record bound (fixed `0x200` β†’ bounded by the next record's address, capped at `0x400`) *and* the pilot (survival β†’ hunting). Either could explain it: the old window mis-framed every record whose true size is not `0x200`, and a hunting pilot flies into traffic that an evading one avoids. **That is a design error on my part**: a run that changes two variables cannot attribute its own result, and the honest outcome is that the old number is retracted without a replacement explanation. The conclusion the retracted number was supporting is unaffected β€” the roster identity now rests on the exact 10-of-10 unit-composition match, which is far stronger evidence and was measured independently. ## ❔ The entity scan is too noisy to answer the wave question `pilot.py`'s own scanner reports a live entity count each tick. Over the run: ``` t=0s 168 (147 ADAN) t=56s 147 (131) t=101s 145 (129) t=20s 171 (147) t=76s 155 (131) t=137s 151 (129) t=30s 148 (132) t=86s 147 (131) t=157s 166 (142) ``` ADAN drifts 147 β†’ 129 and back to 142. The late rise is the shape an arrival would have, but the sample-to-sample swing is Β±10 or more, which is the same size as the effect. This is exactly the trap `docker/agent/AGENT.md` warns about β€” polling faster than the guest updates manufactures a curve out of noise β€” so **no wave conclusion is drawn from it.** Two things are needed before this run type can settle the question: 1. A *stable* liveness signal β€” a per-record field that means alive/dead, read from the 116 labelled records, rather than a re-scan whose population changes between samples. 2. A kill count. `fc=0` in the pilot's telemetry and the asset at 100 % suggest the hunt did not actually destroy anything in 160 s, in which case this run does not test the event-gated model either. `REMAINING OB` at `0xbdb59668` still did not read as a counter, so that check remains unavailable. ## βœ… The timetable's `t` is SECONDS (2026-08-26) This was recorded as "❔ still unmeasured: whether the timetable's `t` is frames or seconds". It is seconds, and the evidence is a physical one rather than an argument from plausibility. **The method.** A route record is a list of `(time, quatΓ—4, posΓ—3)` keyframes, so each consecutive pair gives a distance and a time delta β€” an implied speed. The flight-speed law was measured **live, against a real-time clock** ([flight-speed-law.md](flight-speed-law.md)): the player's craft cruises at ~420 world units/s and tops out at **~1530** under `RT`. That is an independent yardstick in known units, so the two readings of `t` can simply be checked against it. **The result.** `Route_*` records across all 28 stage tables β€” 331 records with two or more keyframes, **1 104** consecutive pairs: | reading of `t` | median | p99 | max | pairs above 1 530 | |---|---|---|---|---| | **seconds** | 147 | 959 | **1 310** | **0 of 1 104 (0.0 %)** | | frames @30 fps | 4 422 | 28 758 | 39 309 | 984 (89.1 %) | | frames @60 fps | 8 844 | 57 516 | 78 617 | 1 037 (93.9 %) | Under **seconds** not one keyframe pair in the game requires a craft to exceed the measured player maximum, and the median 147 sits comfortably below cruise β€” which is what waypoint-to-waypoint averages should look like once turns are included. Under either **frames** reading, ~90 % of the game's routes would demand impossible speeds. There is no overlap to argue about. ### ⚠️ Two corrections made while measuring this Both are the same kind of mistake and worth recording: 1. **A first pass silently skipped non-numeric fields** while flattening a record, which shifts every subsequent value and corrupts the frame split. It produced a median implied speed of 65 534 β€” suspiciously exactly 2^16, which is what gave it away. Fixed by rejecting a record outright rather than dropping a field from it. 2. **The remaining outliers were not routes at all.** Seven stage tables gave maxima in the tens of thousands; every offending record was named `Frame_S_Asteroid`. The corpus already records that the 8-value frame is not universal, and these are the cases. The final measurement therefore filters on the record name (`Route_*`, 1 389 of the 1 477 records; the rest are 60 `Frame_*` and 28 `Enumeration_*`) rather than excluding whole stages β€” a filter by kind, not a filter that removes inconvenient numbers. ### What this does not settle * **331 of the 1 389 `Route_*` records** carry two or more keyframes and pass the `FrameCount*8` length identity; the rest are single-keyframe (arrival only) or do not fit the 8-value frame. The conclusion rests on those 331. * The **~1.25Γ— world-unit factor** noted in `flight-speed-law.md` is not applied here; it would move the ceiling, not the 30Γ— and 60Γ— gaps, so it cannot change the answer. * Whether `t` is measured from **phase start** (as the arrival schedule reads it) or from mission start is unchanged by this β€” that was already settled separately. ## βœ… The entity-count proxy was not just refuted β€” there was nothing to see **2026-08-26.** A live count of `0x820af030` entity records stayed **flat at 116 for 210 s**, spanning Stage 02's scheduled arrivals at t = 90/120/170, and was recorded above as refuting the proxy. It is worth saying *why* it was flat, because the reason is now established and it is not "the proxy is broken". **Arrivals are not spawns.** Built-in 12 `activate_unit`, read from the disassembly (`sub_822659F0`, see [structures/isl-builtins.md](structures/isl-builtins.md)), **returns 0 immediately when the live object `[record+4]` is NULL** β€” it registers an object that already exists and sets its state to *active*. It cannot create one. So the mission's craft are instantiated up front and a "wave arrival" is a craft reaching a place along its route, not a new record appearing. **The count matches the roster exactly, and the number is distinctive.** Stage 02's `UnitGroup` table holds **111 squadron records totalling `Count` = 116 members** β€” the same 116 the live probe saw and never left. The obvious objection is that 116 might be an unremarkable number that matches by accident. It is not: roster member totals, all 28 stages: 2 4 4 9 11 12 14 17 32 36 37 42 43 45 48 50 53 54 54 62 64 66 69 70 87 90 95 116 **116 is the maximum across the whole game and Stage 02 is the only stage with it** β€” no other stage is within Β±5. The save we have is a Stage 02 save. So three independent things line up: the handler cannot spawn, the roster totals 116, and the live count sits at 116 and never moves while 22 of Stage 02's 113 routed squadrons have a route beginning after t = 0. ### What this does and does not settle * βœ… **Arrivals are not spawns**, and the flat count is the expected behaviour rather than a failed measurement. Read from the code, not inferred. * 🟑 **One pre-allocated record per roster member.** Strong β€” the mechanism explains it and the matching number is unique to this stage β€” but still **n = 1**: only a Stage 02 save exists, so the identity has been checked on one mission. The previous entry's "n=1, NOT promoted" caution still applies; what has changed is that there is now a mechanism behind the number. * ❌ **It does not settle timetable versus event.** Knowing that craft are pre-allocated says nothing about *what* starts a route β€” a clock or a trigger. That test still needs a live run, and the entity count can never perform it, because there are no spawns for it to count. A different probe is required: watch a delayed squadron's **position**, not the record count.