diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index 5566639..78b0c55 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -2045,8 +2045,30 @@ and `tie_classes` offsets, so there is no single function that indexes both chun tables by immediate. The moby loader, if it exists in this form, does not reach the tie table the same way. -**Next step, now concrete:** the 394 is a real shortlist. Take the ones whose -immediates also include chunk offsets that *do* look like class-table references, -or the largest ones -- the 34,316-byte outlier is the most promising single -target -- and disassemble those. That is bounded work, unlike the four probes -that produced nothing. +### Ranking by size does not narrow, and biases toward false positives + +The obvious next move was to rank the 394 largest-first and start with the +biggest. Ranked, over 2,323 functions, median candidate size 852: + + 0x2ba7d8 34,316 bytes 631 distinct immediates + 0x2cb3a8 26,432 421 + 0x300618 11,348 155 + 0x3ae900 8,440 208 + ... median 852 + +**This ranking is probably backwards.** A function with 631 distinct immediates +is far more likely to contain any given value -- including `0xc0` -- than one with +80, purely by pigeonhole. Sorting by size therefore selects *for* the very +functions most likely to be false positives, and the 34,316-byte outlier is +probably a mis-bounded extent (the decomp corrects three level-00 entries, per +`docs/LEVELS.md`) rather than a 34 KB loader. + +So the 394 needs a size-independent statistic before it is a shortlist. The right +measure is whether a function contains `0xc0` **more often than its immediate +count predicts** -- expected count from the neighbourhood rate, observed count +inside that function -- rather than whether it contains it at all. That has not +been measured. + +Recorded rather than claimed as progress: ranking by size is the wrong first cut, +and the reason is a confound that would have made the result look better than it +was.