diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md
index ce6aa1d..6327683 100644
--- a/docs/plan/level-assets.md
+++ b/docs/plan/level-assets.md
@@ -2588,3 +2588,50 @@ VU-overlapping window, and the 391 has to be recomputed over the survivors.
 That check is cheap, it is the same check that would have caught this six commits
 ago, and it is the honest next step. It is also, at this point, the fourth time a
 "real shortlist" has turned out to need one more verification first.
+
+### Extent check: inconclusive, and I am not going to read a result into it
+
+Tried to answer `91b0995`'s question -- do the decomp's function extents land on
+CPU code? -- by checking whether each begins with a prologue. Counting only
+`addiu $sp, $sp, -N` and `lui $gp`:
+
+    total 3,835 | cpu prologue 29 | VU-first 66 | nop-first 243 | other 3,492
+
+**29 of 3,835 looks damning and is not.** The "other" bucket contains textbook
+prologues that my two patterns miss:
+
+    0x2a4ef0  ffb00000 ffb10008    sw $s0,0($sp); sw $s1,8($sp)
+    0x2a48f0  3c013f80 44816000    lui $1,0x3f80; bc1t   <-- valid CPU, FP branch
+    0x2a4928  0240282d 24060002    slt $v1,$s0,$s1; sltu $a2,$zero
+
+PS2 leaf functions routinely start by saving registers with no frame adjustment,
+and functions whose extent starts after the `addiu $sp` look the same. Two patterns
+cannot classify 3,835 extents.
+
+**A second thing I cannot explain, recorded rather than guessed:** `ffb00000` has
+major opcode `0x3f`, which is unused in MIPS32 -- yet `ffb00000 ffb10008` is
+unmistakably a register-save prologue, and `ffbf0020` for `sw $ra, 0x20($sp)`
+appears throughout this code. Either the EE encodes `sw` outside MIPS32, or my
+opcode field is being read wrong somewhere. **I have not resolved this**, and it
+undercuts every opcode-based check in this investigation, including the ones that
+produced the 391 and the neighbour ratios.
+
+**So the position after twenty-one commits on `moby_anim`:**
+
+- `overlay_bytes_at` mapping: verified
+- `0x2ee138`, `0x2dca20`: VU microcode, verified
+- the 391 candidates: real as a measurement of the windows scanned; what those
+  windows are remains unestablished, because the window boundaries come from the
+  decomp and those have not been shown to delimit CPU code
+- **the opcode field itself is not understood well enough for these checks to be
+  trusted**, which invalidates the last few in particular
+
+**What this needs:** a single authoritative disassembly of one extent, compared
+line by line against `tools/overlay-anchors`, to establish what the opcode field
+means for this code. Everything else is downstream of that and I have been
+reasoning upstream of it.
+
+That is the same mistake one level down from the section-indexing bug: I used a
+decoding I had never checked to produce results, and then measured the results
+with the same unverified decoding. The check existed as a tool from the first
+commit.