diff --git a/docs/re/mission-freeze-heap-exhaustion.md b/docs/re/mission-freeze-heap-exhaustion.md
index 78b726e..87240db 100644
--- a/docs/re/mission-freeze-heap-exhaustion.md
+++ b/docs/re/mission-freeze-heap-exhaustion.md
@@ -97,3 +97,53 @@ RAM, before believing an empty result means "the thing is not there".
 
 ❔ Still open: why the guest needs a single 128 MB block, whether the heap can be
 given more, and whether the failure is reachable without the mask poke at all.
+
+## ✅ It is the *emulated console's* 512 MB, and the host is not short
+
+Worth ruling out explicitly, because "allocation failed" invites blaming the box:
+
+| resource | measured at the freeze | binding? |
+|---|---|---|
+| `/dev/shm` (backs guest memory) | 2.0 G, **17 % used**, 1.7 G free | no |
+| host RAM | 15.9 G total, **12.3 G available** | no |
+| container cgroup `memory.max` | **2.9 G of 7.0 G** | no |
+| **emulated console RAM** | **113 MB free, 128 MB wanted** | **yes** |
+
+The guest memory file is 4.5 GB *apparent* but sparse — only **319 MB of real
+blocks** — so the 2 GB `tmpfs` was never close to full either.
+
+The decisive arithmetic is in the log's own numbers:
+
+    131072 pages x 4 KB = 512 MB      <- the Xbox 360's unified memory, exactly
+     28969 pages x 4 KB = 113 MB free
+              0x08000000 = 128 MB requested
+
+So `parent heap` is **the emulated console's physical memory**, not anything of
+the host's. The game runs a real 512 MB console down to 113 MB free and then asks
+for 128 MB. Nothing about the container is involved.
+
+## 🟡 The likely mechanism: a release path that leaks
+
+Immediately before the failed allocation, in **both** runs:
+
+| run | `BaseHeap::Release failed because address is not a region start` |
+|---|---|
+| poked, Stage 02 | **23** |
+| control, Stage 01 | **22** |
+
+and they are adjacent to it — in the control run they sit at lines 1115–1176 with
+the allocation failure at line 1179. A release that cannot find its region start
+returns without freeing, so each one leaves guest physical pages permanently
+claimed. Twenty-odd of those over a session is a plausible route from 512 MB down
+to 113 MB.
+
+🟡 Plausible, not shown: I have not measured free pages *over time*, only at the
+moment of failure, so "the leak causes the exhaustion" is still an inference from
+adjacency and count. The test that would settle it is to sample the heap's free
+page count through a run and see whether it falls in steps that coincide with the
+failed releases.
+
+❔ And the deeper question is why the release fails at all — `address is not a
+region start` says the guest is freeing something at an address Xenia's heap does
+not recognise as a region base, which is an **emulator-side** bug rather than a
+game one.