diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index 94af356..a9805bb 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -1125,16 +1125,36 @@ The sample was twelve units out of 1,724,334. Both the monotonic reading and the quantisation were artifacts of that sample, and the disproof is asserted in `crates/gc-extract/tests/disc.rs` so it cannot creep back. -**Record size: 16 bytes, on the classes where it can be measured.** The earlier +**Record size: RETRACTED. Block size is a multiple of 16; the records are not a +uniform 16 bytes.** The earlier "divisible by 16" figure was computed from the "next `packets` offset ends this block" rule, which is unsound because **`packets` is strictly increasing on only 461 of 1,864 classes**. On the other 1,403 the two offsets are unordered, so they cannot both be block starts into one ascending region. Restricting to the 461 classes where the rule does hold: **922 of 922** -consecutive block sizes are a multiple of 16. That is the evidence for a 16-byte -record, and it is confined to the subset where it can be checked. The other 1,403 -classes remain unmeasured rather than measured-and-different. +consecutive block sizes are a multiple of 16. That was taken as evidence for a +16-byte record. **It is not**, and the record-size claim is withdrawn. + +What actually survives, and what killed it: + +- Every one of those **922 blocks opens with a `u32` that is positive and a + multiple of 4** (922/922), ranging 48 to 1,744 with 17 distinct values across + level 0's LOD0 blocks. So the block opens with a count, not a size and not a + pointer. +- Reading that `u32` as a byte size and chaining to the next block lands exactly + on the next block start on **0 of 1,383** blocks. It is not a size chain. +- Assuming `[header][count][count uniform records]` and solving for the record + size: **no record size tiles the block for any header size up to 512 bytes.** + Not 16, not 12, not 8. +- Reading the block as uniform 16-byte units gives fields spanning their entire + legal range -- `u32@0` from -2,139,029,504 to 2,139,029,587, `u16@8` and + `u16@10` both 0..65,535, and 8,969 distinct values in `i16@0` alone on level 0. + Uniform units would not produce that. + +So the 16 is a property of the **block size**, not of a record. The previous +commit's "record size is 16 bytes" was an inference from a divisibility fact that +does not carry it, and it is withdrawn rather than softened. **`packets[0]` is a constant, not an offset.** It reads **256 on 1,864 of 1,864** classes, while `packets[1]` and `packets[2]` vary widely and land at different diff --git a/docs/roadmap.md b/docs/roadmap.md index bb9da12..11ef39f 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -247,19 +247,20 @@ Phase 1 hands over the extents; this phase works out what each one contains. despite the field name). All **1,864** tie classes resolve, with `o_class` agreeing on every one, and all **5,592** LOD block offsets land inside `core_data`. -- [~] The tie **record size is 16 bytes**, established on the classes where it can - be checked: `packets` is strictly increasing on only **461 of 1,864** - classes, and on those **922 of 922** consecutive block sizes are a multiple - of 16. The remaining 1,403 classes are unmeasured, not measured-and- - different. `packets[0]` reads **256 on 1,864 of 1,864** classes and is a - constant, not an offset -- `TIE_PACKETS0`. -- [ ] The tie **record contents are not decoded.** One reading is **disproved**: - the word at `+0` of a 16-byte unit is strictly increasing on **0 of 1,864** - blocks, despite looking exactly like a linked list on the first twelve - units of one class, and `i16[0]` takes 8,969 distinct values on level 0 - rather than the two a sample suggested. A 12-unit sample of a 1.7M-unit - population is the pooled-claim error rule 3a exists to prevent; the test - asserts both the disproof and the new bounds so neither can creep back. +- [~] Tie **block sizes** are established: `packets` is strictly increasing on + only **461 of 1,864** classes, and on those **922 of 922** consecutive + block sizes are a multiple of 16. `packets[0]` reads **256 on 1,864 of + 1,864** classes and is a constant, not an offset -- `TIE_PACKETS0`. Every + one of the 922 blocks opens with a `u32` count, positive and a multiple of + 4 (48 to 1,744). +- [ ] The tie **record layout is not decoded, and a 16-byte record is + withdrawn.** Block sizes being multiples of 16 does not make the records + 16 bytes: reading the block as uniform units gives fields spanning their + whole legal range (`u32@0` from -2,139,029,504 to 2,139,029,587), and + assuming `[header][count][count uniform records]` yields **no record size + that tiles the block for any header up to 512 bytes**. The opening `u32` + is a count, not a size -- chaining it as one lands on the next block start + on 0 of 1,383 blocks. - [~] `shrub` — class table done (48-byte entries, not 32; reading shrub at 32 still gives 231 sane-looking entries of 358, which is the hazard). Geometry header parsed and checked field by field on all 358 spans: