diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md
index d9ed3f9..d711c33 100644
--- a/docs/plan/level-assets.md
+++ b/docs/plan/level-assets.md
@@ -2356,3 +2356,47 @@ The chain as far as it is established, with nothing inferred beyond it:
 
 Everything above that is verified; what `0x2ee138` returns is **unknown**, and it
 is the single remaining link between the program and `moby_classes.offset`.
+
+### d97e7df's conclusion was wrong: my section offset was wrong, not the bytes
+
+Ran `tools/overlay-anchors --disasm` on `0x2ee138` as `d97e7df` said to. It
+reports "6 of 12 words did not decode" -- but compare the *words*:
+
+    tool:    0x2ee138  0x4bc00083
+    my read: 0x2ee138  0xd8a10000
+
+Different bytes at the same address. **My offset into the section is wrong**, so
+the "opcode 0x36 is not a valid MIPS opcode" finding was about bytes that were
+never at that address. That invalidates the conclusion in `d97e7df` as well as the
+"second decode error" framing in it -- the decoder was never the problem.
+
+The tool's words are `0x4bc00083` and friends, which are **COP2** (opcode 0x12),
+i.e. VU1 vector-unit instructions, which capstone will not render under a plain
+MIPS32 configuration. So capstone's "did not decode" is expected for VU code and
+carries no information either.
+
+Four separate bugs in this one investigation now, all mine:
+
+1. un-masked J-type branch target -> false negative on callers
+2. transposed hex address -> disassembled the wrong place
+3. concluded "invalid opcode" from bytes that were not at that address
+4. the section-offset mapping itself is wrong
+
+**The one lesson, and it is the same one four times over:** every one of these was
+a self-consistent probe reporting a clean number. The discipline that would have
+caught all four is the one `d97e7df` recommended and I then skipped -- verify the
+tool against a known-correct case *before* using it to generate a finding. The
+known-correct case was sitting in the decomp's own extents, and I used my own
+arithmetic instead.
+
+**Nothing about `0x2ee138` is now known.** Not that it is VU code, not that it is
+data, not that it is a function. The address `0x2ee138` is the correctly decoded
+`jal` target from `0x3a3d70`; what is at that address is unestablished.
+
+The correct next step is to fix the address-to-overlay mapping in `gc-formats`
+(`OverlaySection` gives `dest` and `data`, and the mapping between them is what
+has been wrong all along), verify it against a section whose contents are
+independently known, and only then re-read `0x2ee138`. Until that mapping is
+verified, **no address in this investigation that I computed by hand is
+trustworthy** -- including the `0x3a8060` walk, which happened to decode but may
+have been read from the wrong bytes.