diff --git a/docs/re/mission-phase-advance.md b/docs/re/mission-phase-advance.md
index 935d294..1e9f962 100644
--- a/docs/re/mission-phase-advance.md
+++ b/docs/re/mission-phase-advance.md
@@ -164,10 +164,48 @@ hashes** — `MISSION1..33` and the five `MISSION_*_PRT`, each under the prefixe
 the suffixes `.prt`, `.PRT`, `.scr`, `.bin` and none — across **all 35 paks** in
 `dat/` and `hidden/`. **Zero hits.**
 
-❔ What is left: the payload is in the XEX's compressed/encrypted region (this
-file notes the retail `default.xex` was never decrypted), or under a name none of
-those 616 guesses covered. The `GP_SCRIPT` string is the strongest remaining
-thread — a pak of that name is referenced by the code but absent from the disc.
+### The pak route is now properly closed, and the loader's own code read
+
+**All 41 paks, not 35.** The first sweep missed `hidden/resource3d/` and
+`dat/movie/`. Redone across every `*.pak` on the disc — **41 archives, 26 443
+indexed records, 768 distinct name hashes** — still **zero hits**. The scripts are
+not a pak record under any of those names.
+
+**The loader compares names; it does not build a path.** The three strings live at
+known VAs (the `.pe` is a flat VA dump, so `VA = 0x82000000 + offset`):
+
+| string | VA | referenced from |
+|---|---|---|
+| `SCRIPTS` | `0x820a823c` | `0x8225f1b8`, `0x82262374` |
+| `GP_SCRIPT` | `0x820a8244` | `0x8225f168`, `0x822622bc` |
+| `MISSION1` | `0x820a8264` | `0x8225eed8` |
+
+All three references inside `sub_8225EE20` disassemble to the same shape:
+
+```
+8225F160  addis r11, r0, 0x820B
+8225F164  lwz   r3, 80(r31)          ; an object
+8225F168  addi  r4, r11, -32188      ; = 0x820A8244  "GP_SCRIPT"
+8225F16C  bl    0x82448AA0
+...
+8225F1B0  addis r11, r0, 0x820B
+8225F1B4  lwz   r3, 0(r25)
+8225F1B8  addi  r4, r11, -32196      ; = 0x820A823C  "SCRIPTS"
+8225F1BC  bl    0x82448AA0
+8225F1C0  cmpi  cr6, 0, r3, 0        ; result tested as a comparison
+```
+
+Both call **the same routine `0x82448AA0`** with `(object, string)` and test the
+result — so this is a *name comparison* against an already-open archive, not the
+construction of `dat\GP_SCRIPT.pak`. That is consistent with `GP_SCRIPT` being
+the name the engine expects an archive to *report*, which is why no file of that
+name exists to be found.
+
+❔ Still open, with the next concrete steps: identify `0x82448AA0` (strcmp vs
+strstr vs a hash-compare) and `0x82448C50`/`0x8216F218` around it, and follow
+`[r31+80]` — the object whose name is being tested — back to whoever opened it.
+That names the container. The XEX's compressed/encrypted region remains the other
+candidate; the retail `default.xex` has never been decrypted here.
 
 ## ✅ Tooling correction: the `.pe` is NOT stale