diff --git a/docs/re/mission-freeze-signin-dialog.md b/docs/re/mission-freeze-signin-dialog.md
index d6f37f4..51d1fd6 100644
--- a/docs/re/mission-freeze-signin-dialog.md
+++ b/docs/re/mission-freeze-signin-dialog.md
@@ -253,3 +253,37 @@ attachment names living in the **XEX image** (`0x820A…`), not runtime definiti
 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.
+
+## 🔴 The "follow the name pointer" route is structurally dead for pak strings
+
+Locating `DeltaSaber` at mission time works: **53 occurrences, every one in the
+heap** (`0xBC66…`–`0xBC6C…`), none in the XEX image —
+`DeltaSaber_T.xpr`, `_Special`, `_NoseGun`, `_Missile`, `_TwinGun`.
+
+But searching all of guest memory for a 32-bit big-endian pointer to those
+addresses returns **0 references** for every one tried.
+
+That is not a search bug, it is the format. Those strings live in the mission
+pak's **IDXD string pool**, and this corpus decoded that container long ago:
+records reference names by **offset into the pool**, never by absolute pointer
+([`structures/idxd-container.md`](structures/idxd-container.md)). So there are no
+pointers to find, and "find the name, follow what points at it" cannot work on
+pak data by construction.
+
+## 🟡 Which narrows what the string counts actually proved
+
+The title-vs-mission control stands — `DeltaSaber` really is 0 at the title and 81
+after take-off, so **mission-specific data is loaded**, which is more than "the
+unit tables load at boot". But these are **asset-table strings**, not live entity
+objects, so they do **not** show that entities have been *spawned*. The honest
+statement is:
+
+* ✅ the mission's pak data is loaded;
+* ❔ whether entity objects exist is still unmeasured, because the only two
+  probes tried — `gworld`'s vtable constants, and name-pointer following — are
+  respectively stale and structurally inapplicable.
+
+❔ Remaining routes, none tried: derive the entity vtable from the **code** (find
+the constructor that writes a vtable pointer, via `sylpheed.db`'s `vptr_writes`
+table, which exists precisely for this); or find the entity list from the mission
+update function rather than from data.