diff --git a/docs/re/mission-freeze-signin-dialog.md b/docs/re/mission-freeze-signin-dialog.md
index c5ebed1c..d6f37f4b 100644
--- a/docs/re/mission-freeze-signin-dialog.md
+++ b/docs/re/mission-freeze-signin-dialog.md
@@ -203,3 +203,53 @@ under `lavapipe`.
 **Status of the oracle overall: boot, menus and take-off are now reliable and
 reproducible; only the cutscene→mission step is unsolved.** That is a much
 smaller and better-defined gap than the freeze it replaced.
+
+---
+
+# ✅✅ The mission **does** load — and `DEF_VTABLE = 0` was a stale constant, not an empty game
+
+**2026-08-26.** Three iterations concluded "no units are loaded" from
+`gworld.scan_vtable(DEF_VTABLE)` returning 0. That inference is **withdrawn**.
+The scan was measuring the wrong thing.
+
+Counting unit-name strings in guest memory, with the **title screen as a
+control** (same boot recipe, no mission loaded):
+
+| string | title (control) | after take-off |
+|---|---|---|
+| **`DeltaSaber`** | **0** | **81** |
+| `rou_` | 1 981 | **7 680** |
+| `UN_` | 19 | **167** |
+| `e010` | 67 | 134 |
+| `ADAN` | 1 450 | 1 921 |
+
+`DeltaSaber` is the **player's craft**, and it is **absent** at the title and
+present 81 times after take-off. Every other count rises several-fold. The stage
+content is unambiguously in memory.
+
+⚠️ The control is what makes this a result. Raw counts alone prove nothing —
+`rou_` and `ADAN` are numerous at the title too, because the unit *tables* load at
+boot. Only the title-vs-mission **difference**, and `DeltaSaber`'s 0 → 81 in
+particular, separates "the tables are loaded" from "the mission is loaded". My
+first reading of these counts skipped the control and over-claimed; the control
+was run before publishing.
+
+## 🔴 What this withdraws
+
+* **"No units are loaded"** — wrong. The mission loads.
+* **"The take-off sequence lands in a cutscene that never ends"** — the movie
+  accesses are real, but the conclusion drawn from `DEF_VTABLE = 0` alongside them
+  does not follow. The game may well be *in* the mission.
+* By extension, `gworld.py`'s `DEF_VTABLE = 0x820AF844` / `INST_VTABLE =
+  0x820AF030` do **not** locate entities in this build/state, even though both are
+  genuine vtables in `sylpheed.db`. They are the wrong ones, or entities are
+  reached another way.
+
+## ❔ Next, and it is now concrete
+
+Derive the **correct** entity vtable rather than trusting the stored constant:
+the `UN_` strings reachable this way turned out to be `UN_NOSE` / `UN_MOUNT`
+attachment names living in the **XEX image** (`0x820A…`), not runtime definition
+records — so the route in is a name that only exists at mission time.
+**`DeltaSaber` is exactly that name**: find its occurrences in the heap, find what
+points at them, and read the vtable pointer of the referencing object.