diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md
index e69fba5..ce510b2 100644
--- a/docs/plan/level-assets.md
+++ b/docs/plan/level-assets.md
@@ -2207,3 +2207,36 @@ preceding instruction at this function's entry sets up a 64-byte frame and saves
 `r16`-`r20`, so the walk is over arguments rather than a global -- which is itself
 informative, because a *loader* would more likely take the chunk as an argument
 from its caller than re-derive it.
+
+### Call sites: one caller, and it does not compute base + 0xc0
+
+Traced as `cee17c9` proposed. `0x3a8060` has **exactly one call site**, at
+`0x3a7d88`:
+
+    0x3a7d70  lui    r1,  0xbf80
+    0x3a7d7c  jal    ...
+    0x3a7d84  addiu  r18, r2, 0x202d      <-- r18 = r2 + 0x202d
+    0x3a7d88  jal    0x3a8060
+
+No `0xc0` anywhere in the eight instructions before the call, and `r18` is built
+from `r2 + 0x202d` -- a different offset entirely. So the `0xc0` inside the callee
+is a **field offset applied to a pointer the caller already built**, not a chunk
+offset the caller resolved.
+
+Two readings remain, neither settled:
+
+- `r18` is `core_data`, making `r18 + 0xc0` equal `&moby_classes`. This fits,
+  because level 0's `moby_classes.offset` genuinely is `0xc0`.
+- `0xc0` is a member offset in an unrelated structure and the match is
+  coincidence.
+
+Settling it needs the provenance of `r2` at the call site. That is real dataflow,
+not counting, and it is where this stops. Six commits of immediate arithmetic
+could not answer it, and the one disassembly that could has now shown the answer
+is not as simple as "the caller loads the chunk".
+
+**The lesson, stated plainly so it is not relearned:** a constant's frequency, and
+even its use, say nothing about what it means. Six rounds of counting produced one
+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.