re: the wave timetable's t is SECONDS, measured against the live speed law

Route keyframes are (time, quat x4, pos x3), so each consecutive pair gives an
implied speed. The flight-speed law was measured live against a real-time clock
(cruise ~420, max ~1530 world units/s), which makes it an independent yardstick
in known units.

Across all 28 stage tables, 331 Route_* records and 1104 keyframe pairs: under
SECONDS not one pair exceeds the 1530 ceiling (median 147); under frames at 30
or 60 fps, 89% and 94% of the game's routes would demand impossible speeds.

Two corrections recorded. A first pass silently skipped non-numeric fields while
flattening records, shifting every later value -- it reported a median implied
speed of 65534, suspiciously 2^16, which is what exposed it. And the remaining
outliers were Frame_S<NN>_Asteroid records, not routes; the final measurement
filters by record kind rather than dropping whole stages.

docs/re/BACKLOG.md

@@ -395,7 +395,10 @@ search cannot find a *schedule*.
   🟡 116 is exactly Stage 02's roster member count, suggesting one pre-allocated
   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.
+  ✅ **Settled 2026-08-26: `t` is SECONDS.** Consecutive route keyframes give an
+  implied speed; checked against the live-measured player ceiling (~1530 world
+  units/s), **0 of 1 104** pairs exceed it under seconds while 89–94 % do under
+  frames at 30/60 fps. See [`mission-wave-arrivals.md`](mission-wave-arrivals.md).
 * ✅🟡 **Motion-independent liveness probe works; `n` is probably craft-per-member**
   (2026-08-24) — [`mission-liveness-probe.md`](mission-liveness-probe.md).
   Enumerating by definition pointer instead of by motion removes the ±10 noise

docs/re/mission-wave-arrivals.md

@@ -418,3 +418,61 @@ Two things are needed before this run type can settle the question:
    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<NN>_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.