diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md
index b2fa364..ce6aa1d 100644
--- a/docs/plan/level-assets.md
+++ b/docs/plan/level-assets.md
@@ -2541,3 +2541,50 @@ and reported every one with the same confidence as the kind that does.
 are a legitimate shortlist -- but the disassembly that would consume them must go
 through `tools/overlay-anchors`, whose output has now been checked against a word
 the build pins.
+
+### The shortlist points at VU microcode, not CPU code
+
+391 candidates on correct bytes, 73 with fewer than 16 immediates. The densest is
+`0x2dca20` -- 164 bytes, **three** distinct immediates, one of which is `0xc0`.
+
+Disassembled through `tools/overlay-anchors`:
+
+    0x2dca20: bnel   $a1, $fp, 0x2dca38
+    0x2dca24: lbu    $a2, ($s7)
+    0x2dca28: xori.b $w0, $w0, 0xa2          <-- VU
+    0x2dca2c: ext    $v0, $s0, 0, 1          <-- VU
+    0x2dca30: b      0x2dcac8
+    0x2dca38: sll    $a1, $a1, 4
+    0x2dca40: .word  0x0200202d
+    0x2dca48: addu   $a2, $v0, $a2          <-- 3-operand: MIPS-III, not MIPS32
+
+`xori.b` and `ext` are VU1 mnemonics and the three-operand `addu` is not MIPS32 at
+all. **Capstone is decoding COP2.** So `0x2dca20` is VU microcode, not a CPU
+function.
+
+That is the same answer `0x2ee138` gave. Two of the densest candidates in the
+"moby_classes offset" shortlist are vector-unit code.
+
+**This calls the frequency result into question again, and more seriously than
+the displacement did.** The enrichment measured 391 CPU functions carrying
+immediate `0x00c0` at 11x-45x over neighbours, and that measurement filtered on
+opcodes 0x09/0x0d/0x0f/0x0c/0x05/0x06 -- which **excludes COP2**. So VU code
+cannot explain those counts directly. But the *function extents* come from the
+decomp's CPU analysis, and if any extent spans a VU region then the window being
+scanned is mixed, and the immediate set attributed to that "function" is not a
+function's.
+
+**Honest status:** the enrichment is real as a measurement of those windows. What
+those windows are is now doubtful, because the decomp's extents have not been
+verified to land on CPU code, and two independent spot-checks of the densest
+candidates landed in VU microcode.
+
+**What this needs before it can be used:** verify that a known CPU function's decomp
+extent actually contains CPU instructions -- same shape as the `cd16485` check.
+Decode a handful of extents and require them to begin with a plausible prologue
+(`addiu $sp, $sp, -N` or `lui $gp`). Any extent that does not is a mis-bound or
+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.