Reproducing my offset result, the Decoder reported the same discrimination over
3311 records against my 1781, with exactness 49.6% against my 92.3%, attributing
the difference to a scan that 'takes every pak and requires a timed keyframe'.
Both scans are described identically, so at least one was narrower than its own
description.
Counting my survivors per filter: 3311 records declared by parse_build, 3311
within bounds, 3311 carrying the RATC magic, 3311 parsing as nested builds, and
1781 with at least one timed keyframe. So 3311 is the count BEFORE the timed
filter.
The arithmetic closes it: 1643/1781 is 92.3% and 1643/3311 is 49.6%, their figure
exactly. Same numerator. Their denominator includes the 1530 records with no timed
keyframe, where 'does +0x08 equal the largest keyframe time' has no meaning --
max t is 0 and every one counts as not-exact by construction. So their stated
filter is not applied, and 49.6% is not a weaker version of 92.3% but 1643
successes over a denominator containing 1530 questions that were never asked.
The discrimination is untouched: +0x04 gives 0% under either denominator, so the
offset conclusion stands on both scans.
And my own number needed a qualifier it did not carry. 92.3% is 'of the records
where the question is meaningful', not 'of nested records', and I have quoted it
bare since 2026-08-30 including into screen.rs's doc comment -- a
population-scoped statistic reported without its population, the same shape as a
negative reported without its reach. Qualified in place.
Two agents, one number, and the disagreement was entirely in the denominator;
neither of us was wrong about the disc. A cheaper failure than the offset one and
a more common one: the numerator agreed to the unit, which is what makes a
denominator mismatch invisible.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
6048c70bee