# 🟡 The unreached code — five mechanisms eliminated, and nothing in the file names it

Inverting the question (read what an unreached routine *does*, instead of testing
another candidate mechanism) sharpened this considerably without solving it.

## ✅ The metric was partly inflated — but only partly

Over all 28 stages: **24 901 unreached instructions (15.0 %) in 564 runs.**

| | |
|---|---|
| runs of length 1 | **458** |
| …of those, a lone `ret` (op 20) | 111 |
| **instructions in runs longer than 1** | **24 443 — 14.7 %** |

The length-1 runs are dead terminators: a `ret` stranded after an
`end_coroutine`, with the *next* routine being a properly seeded entry. Stage 02's
first two "unreached routines", `0x000D8C` and `0x002C00`, are exactly this — the
code immediately after each is the phase main entry and a timeline target.

But they are only 458 instructions. **The gap is real: 106 runs, several of them
huge** — 1526 (Stage 26), 1496 and 1481 (Stage 29), 1069, 904, 860.

## ✅ And it is live mission logic

Stage 26's 1526-instruction run:

```
004BD8: local[0] = 1 ; local[4] = 1 ; local[8] = 1
004C08: call builtin57(ADN110, 0x1)
004C44: local[16] = 0.0
004C60: call set_group_speed(ADN110, 0x2, 0)
```

Named units, named built-ins, staged arguments. Not padding, not scratch.

## 🔴 FIVE mechanisms carry code offsets — and none points at it

Every construct in the file that names a routine has now been enumerated and
tested against the unreached run-starts:

| mechanism | references | on the instruction stream | control | **unreached run-starts** |
|---|---|---|---|---|
| `start_coroutine` (built-in 1) | 1765 | 1765 (100 %) | — | **0** |
| the phase TIMELINE | 675 | 675 (100 %) | 33.3 % | **0** |
| built-in 19's trigger handler | 79 | 79 (100 %) | 27.8 % | **0** |
| **`kill_coroutine` (built-in 5)** | **150** | **150 (100 %)** | **34.0 %** | **0** |
| the `0x1883` records | 88 | 82 (93 %) | — | (they *were* the 5 exits) |

`kill_coroutine` is new this iteration and confirms the corpus's reading — its
`local[0]` is a phase-relative code offset, 150/150, values 13 740…221 048.

**Across 2 757 code references, not one lands on an unreached run-start.** That
is not a near miss; it is a categorical absence.

## ✅ Not a tool artefact

The obvious suspicion is that my entry extractor drops targets. It does not:

* **1765 of 1765** `start_coroutine` sites resolve — **0 missed**.
* **0** entries land outside their phase's region.
* **0** entries are discarded by the "must be on the instruction stream" filter.

## 🟡 Where that leaves it

Combined with the earlier result that an unreached routine's offset appears
**nowhere in the file as a word**, in any encoding (phase-relative, absolute, and
both /4 forms, all at or below their controls), the conclusion is that these
routines are **referenced by nothing inside the `.ssb`**.

Two readings remain, and this work does not choose between them:

1. they are **unused in this build** — compiled from source that the shipped
   mission never enters; or
2. they are entered from **outside the file** — a table in another pak, or engine
   code holding an offset.

⚠️ Reading (1) is not comfortable with a 1526-instruction routine that
manipulates a named squadron, but "uncomfortable" is not evidence.

## 🟡 Not settled

* Which of the two readings is right. A runtime probe — breaking on
  `sub_822737C8` and logging its third argument through a mission — would decide
  it, and no static test I have devised can.
* Whether the 106 runs are one phenomenon or several.