# ✅ Each phase carries a TIMELINE — 675 scheduled routines across the disc

The trailing data table found at the end of every phase region
([isl-stream-entry-points](../isl-stream-entry-points.md)) is decoded. It is the
mission's **scripted event schedule**.

## Layout

After the phase's code ends — at the first value of that phase's mission-level
`0x1883` record — comes a run of 8-byte typed records, tag `0x19` = int,
`0x1A` = IEEE float:

```
int   N                                     -- entry count
N x [ int offset ; float t ; int kind ]
```

`1 + 3N` matches the record count in **every** phase measured: Stage 02's three
phases hold 76, 40 and 55 records for N = 25, 13 and 18.

## ✅ The checks

| | |
|---|---|
| schedule entries disc-wide | **675** |
| `0x1A` float records disc-wide | **675** — the same number, independently counted |
| offsets landing on the instruction stream | **675 / 675 = 100.0 %** |
| control: random 4-aligned offsets | 33.3 % |

The float count and the entry count are derived by different routes and agree
exactly, and every single offset resolves. `kind` is **0** (556) or **5** (119).

## ✅ The floats are seconds

The distribution is unmistakable: 0, 0.5, 1, 4, 5, 30, 50, 60, 90, 120, 150,
170, 180, 210, 240, 270, 300, 330, 360, 420, 570, 1020, 1080, 1140, 1170 …
mission times, not fractions.

And the targets are what a schedule would point at — small one-shot coroutines:

```
002C04:  set.i  local[0] = 1
002C1C:  set.i  local[4] = 1
002C34:  set.f  local[8] = 0.4
002C50:  call   builtin106(0x1, 0x1, 0.4)
002C5C:  call   end_coroutine
```

## 🟡 A runtime cross-check — consistent, and not proof

The closed `REMAINING OB` work measured, on the emulator over n=5 runs, that
Stage 02's squadrons arrive at **t = 0, 120 and 210 s**. All three times are in
phase 1's static schedule, and **120 and 210 each appear twice**, which is what
two squadrons arriving together would look like.

⚠️ Stated as consistency rather than confirmation: these are round numbers, and
phase 1 has ~22 distinct times spread over 0–1170, so three specified round
values all being present is not by itself unlikely. The **doubling** is the
sharper detail, and it was not predicted in advance.

## Artefacts

`data/isl-stage02-schedule.txt` and `data/isl-schedule-all.txt` (all 28 stages,
675 entries), generator `isl_report.py schedule`. The four earlier artefacts
regenerate byte-identical.

## 🟡 Not settled

* **`kind` (0 or 5) is not identified.** Two behaviours, no reading.
* **This is not what starts the unreachable code.** All 675 targets are already
  reachable — **0 are unreached run-starts** — so the ~15 % gap stands.
* **Whether the schedule is per-phase-clock or mission-clock** is not
  established; each phase's table restarts at t=0, which suggests per-phase, but
  that is an inference from the layout, not a read of the consumer.
* **The consumer is unread.** Nothing here shows the engine walking this table;
  the decode rests on the structural checks above.