diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md
index c96ccec..a79e140 100644
--- a/docs/re/BACKLOG.md
+++ b/docs/re/BACKLOG.md
@@ -519,6 +519,18 @@ search cannot find a *schedule*.
   directly observable (deployed would jump), did not happen in 435 s with 42
   kills, and `SUBObjectiveSettings` names 9 objectives but carries no trigger.
   Unsearched: `StageMessageSet_S02.tbl` (never resolved) and the PE in guest RAM.
+* ✅🔴 **(2026-08-24) Message tables searched; trigger NOT there.**
+  ✅ `StageMessageSet_S02.tbl` **resolved — prefix is `message\`**, not `stage\`
+  (closes a long-standing ❔). ✅ `message\UnitMessageSet_S02.tbl` has
+  `CrewCount` + **`PresetMessage_Phase1/2/3`** — a THIRD independent table family
+  organised around phases, after the stage record and route names.
+  🔴 **Refuted:** `ScriptMessage_S02_msg.tbl`'s promising third field is a radio
+  *delivery category* (`None` 105, `Emergency` 33, `Killed` 5, `Noise` 5; arg is
+  `1` in every record), not mission control flow.
+  ❔ **No table anywhere carries a phase-advance condition** — everything found is
+  a consequence of the phase, never its cause. ⇒ the logic is in **code**, and
+  `default.xex` is encrypted on disc, so the decrypted image exists only in guest
+  RAM. That is the honest end of the static search.
   🔴 `SYLPH_HZ=3` refuted as a lever: it gave the LOWEST frame rate (8/s) with the
   most kills, so pilot polling is not the throttle.
 * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;
diff --git a/docs/re/mission-phase-deployment.md b/docs/re/mission-phase-deployment.md
index 38a67c4..cc5fd9c 100644
--- a/docs/re/mission-phase-deployment.md
+++ b/docs/re/mission-phase-deployment.md
@@ -74,3 +74,61 @@ What is now known that was not then:
 Places not yet looked: `StageMessageSet_S02.tbl` (never resolved in
 `GP_MAIN_GAME_E.pak`), and the executable, whose decrypted image is only
 available in guest RAM.
+
+---
+
+# Hunting the phase trigger in the message tables (2026-08-24)
+
+## ✅ `StageMessageSet_S<NN>.tbl` resolved — the prefix is `message\`
+
+[structures/stage-mission-tables.md](structures/stage-mission-tables.md) recorded
+this table as ❔, "not in `GP_MAIN_GAME_E.pak` under that name". It is there; the
+archive prefix is **`message\`**, not `stage\` like its siblings. Sweeping the
+prefix candidates over the full 16 630-entry TOC found it immediately.
+
+It holds three records — `VoiceID2SndID`, `UnitMessageSetTable`, and a `Files`
+list of 31 message tables: `ScriptMessage_S02_msg.tbl`,
+`ScriptMessage_S02guide_msg.tbl`, `DemoMessage_S02_msg.tbl`, and per-character
+`PresetMessage_*` sets.
+
+## ✅ Phases are a first-class runtime concept, confirmed independently
+
+`message\UnitMessageSet_S02.tbl` (26 records) has exactly four named fields:
+
+```
+CrewCount, PresetMessage_Phase1, PresetMessage_Phase2, PresetMessage_Phase3
+```
+
+Every message set carries a **different preset message table per phase**. That is
+a third, independent table family organised around `Phase_1..3`, after the stage
+record and the route names. Phases are not a quirk of one file.
+
+## 🔴 Refuted: the script-message trigger field is not a phase trigger
+
+`ScriptMessage_S02_msg.tbl` has 149 records whose third positional field looked
+promising — values like `Killed` alongside `None`. Enumerated across the corpus
+it is a small closed vocabulary:
+
+| value | S02 | S01 |
+|---|---|---|
+| `None` | 105 | 72 |
+| `Emergency` | 33 | 5 |
+| `Killed` | 5 | 2 |
+| `Noise` | 5 | 8 |
+
+These are **delivery categories for radio chatter** — how a line is played
+(urgent, over static, on a death) — not mission control flow. The fourth field is
+`1` in every single record, so it is not an argument either. Rejected.
+
+## ❔ No table carries a phase-advance condition
+
+Phases now appear in the stage record, in route names, and in message sets, and
+**not one of those files says what ends a phase.** Everything found is a
+*consequence* of the phase, never its cause.
+
+That points at the advance logic living in code rather than data. The only place
+left is the executable, and `default.xex` is encrypted on disc — the decrypted
+image exists only in guest RAM, which means a run plus function-level work.
+
+Recorded as the honest end of the static search rather than continuing to guess
+at table names.