diff --git a/docs/re/mission-freeze-heap-exhaustion.md b/docs/re/mission-freeze-heap-exhaustion.md
index eb8d8746..2695c246 100644
--- a/docs/re/mission-freeze-heap-exhaustion.md
+++ b/docs/re/mission-freeze-heap-exhaustion.md
@@ -617,3 +617,59 @@ The next thing to vary is therefore the **boot inputs**: profile, save data and
 `xenia-canary.config.toml`. `B50C0000`'s request is `0x070D28B0` — an odd,
 computed size, not a round reservation — so it plausibly depends on something
 configurable.
+
+---
+
+# 🔴 The allocation failure is definitively **not** the cause
+
+Four runs now freeze at the same point — the first content load after the main
+menu — with three different allocation outcomes:
+
+| run | change | allocation outcome | froze? |
+|---|---|---|---|
+| stock | — | **fails** at 128 MB, guest throws | yes |
+| GPU writeback 16 MB → 1 MB | emulator patch | none, stops at 32 MB | yes |
+| heavy XMA debug logging | logging | none, stops at 16 MB | yes |
+| **no game save** (`--content_root` to a profile-only tree) | boot input | **none, no throw** | yes |
+
+The memory account on this page is accurate and still worth having, but it
+describes a **symptom**. Everything above that treats the 128 MB refusal as the
+freeze is superseded by this table.
+
+## 🔴 The savegame is not the variable either
+
+`--content_root=/tmp/content-nosave-a`, containing a copy of the profile and no
+game save (the real content tree untouched), boots to the **identical** pools:
+`BC220000 Size: 03A80000` and `B50C0000 Size: 070E0000`, same addresses, same
+sizes, same 43 allocations by the menu. Then freezes at the same press, with
+**zero** allocation failures and **zero** throws.
+
+## ✅ It is not slow shader compilation either
+
+Every earlier run called it frozen within ~30 s. Under lavapipe a content load
+could plausibly be compiling shaders, so this one was left for six minutes:
+
+    t+1min  liveness 0.00%   allocs 121   cpu 479%
+    t+2min  liveness 0.00%   allocs 122   cpu 461%
+    ...
+    t+6min  liveness 0.00%   allocs 124   cpu 399%
+
+No recovery, and no sign of one.
+
+## ⚠️ And a correction I made mid-measurement
+
+The allocation counter creeping (119 → 124) briefly looked like "the guest is
+running, only the display is stuck". **It is not.** A *broad* guest-memory
+sample — 400 extents, 8.2 MB — changed **18 bytes in 3 seconds**. The guest is
+stuck; one thread still allocates roughly once a minute at 400 % CPU, which is a
+spin, not progress.
+
+The earlier "8 MB slab at `0x40000000` unchanged" reading was also weak evidence
+for the opposite reason — one arbitrary region proves little either way. **Sample
+broadly before calling a guest alive or dead**, the same way the screen needed
+two frames rather than one.
+
+❔ So the oracle is still broken and the cause is unidentified. What is now
+excluded: the heap failure, the leak, allocation rounding, `MmQueryStatistics`,
+a heap-size knob, the exception cvar, a kernel-object wait, a build regression,
+the navigation route, the savegame, and slow shader compilation.