diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md
index ce510b2..4cc4ce6 100644
--- a/docs/plan/level-assets.md
+++ b/docs/plan/level-assets.md
@@ -2240,3 +2240,31 @@ even its use, say nothing about what it means. Six rounds of counting produced o
 robust fact -- `0xc0` is used far more than adjacent constants -- and not one
 identified function. A single disassembly settled in twelve instructions what six
 counting passes could not, and immediately complicated the answer.
+
+### Provenance: r2 is never written, and the enclosing function has no callers
+
+The trace `eca1a16` asked for. The call site `0x3a7d88` sits inside the function
+at `0x3a7c30`, 580 bytes, 145 instructions.
+
+**`r2` is never written in that function.** Scanning every instruction for one
+that stores into `r2` (`sw` or `sb` with `rs == 2`) finds none across all 580
+bytes. So `r2` at the `jal 0x3a8060` is not defined anywhere in the enclosing
+function -- it arrives from outside.
+
+**And `0x3a7c30` has no `jal` callers.** Scanning the whole of level-0 `.text`
+for `jal` instructions targeting it finds zero. It is also **not** a `lvl.vtbl`
+handler: level 0's vtbl has 233 records and 185 distinct handler addresses, and
+neither `0x3a7c30` nor `0x3a8060` is among them.
+
+That rules out the tidy story -- "the vtbl dispatcher calls it with the class
+pointer in `v0`" -- which was the obvious guess given `r2` arrives unexplained.
+The remaining possibilities are an indirect call through a pointer (`jalr`), a
+dispatch table in data rather than in the vtbl, or code that is not called at all.
+
+Not distinguished. The immediate question for anyone continuing is whether
+`0x3a7c30` is a target of any `jalr` in the level, and if so from where.
+
+**This is the end of what counting can do here.** The chain is now:
+`? -> 0x3a7c30 (no static caller) -> 0x3a8060 -> addiu r17, r18, 0xc0`, with `r2`
+supplied by whatever reaches `0x3a7c30`. Every remaining question is about
+control flow and register provenance, not about counts.