With the record framing settled (leading two bytes = record index), the body is
bytes 2..len. Four probes, mostly negative, recorded so the next attempt does not
repeat them.
No count field. For every chunk type, every u16 and u32 position in the first 64
body bytes, at element strides 1,2,3,4,6,8,12,16: does the stored value equal
(record_len - offset) / stride on 90%+ of records? No type produced a hit. The
record does not carry an element count near its head.
The body is dense, not float-dominated. For the largest type (2430 records,
326-byte bodies): f32 reads within +/-5000 of origin 74%, uniform-random control
49%, zero-byte fraction 13%. Above baseline but far short of the tie blocks
(53-64% against 16%, with 43% zero bytes).
There is an index-like region near the tail. In the largest type, 12 of 163 u16
slots have a maximum below 0x1000 -- too small for float or half-float, so those
look like indices or small counts -- clustered at slots 111-121 and 130-131.
A sample-size correction. Dumping six records of one chunk showed slots 112-119
zero on every record plus a long run of other constants, which reads as "the
record is mostly a per-chunk template". Measured across the 1,171 chunks with at
least 8 records: 15,422 of 164,390 u16 slots are constant across their chunk,
9.4%, and 0 of 1,171 chunks are entirely constant.
So 9.4%, and no chunk is a template. Six records looked like a majority because
that chunk's tail carries shared constants. Per type the figure ranges from 9.4%
overall to 55.6% on one type, so it is reported per type as well as pooled --
the pooled figure alone would hide that spread, which is the same trap rule 3a
describes.
ReaperOfVeriod
e2b12a2e52