Repeat the packet measurements per level, correcting two over-general claims

The five-block result was measured on level 0 only. Rule 3a asks for the same measurement per partition, so it was repeated on level 1's savestate before being written up as a property. Range measured: savestate slot 2 (level 1), RAM 0x22a000..0x28f52f, 415024 bytes, then six of its pointer-bearing records read to count*16. The six sampled pointers split 3/3 between the two payload kinds: 00949430 41 00 00 00 30 sub-list 009496c0 13 69 b0 bf 80 fixed-point 00957970 36 00 00 00 30 sub-list 00957bb0 10 58 7e 8d 80 fixed-point 0095b740 12 37 49 41 80 fixed-point 0095d6d0 57 00 00 00 30 sub-list Taking all six as sub-list gives 3/6 with five blocks. Taking only the three that actually open 00 00 00 30 gives 3/3, with the first three blocks at 0, 32, 64 in all three. The three fixed-point payloads have zero such blocks, as expected. The earlier 3/6 was my sampling, not a counterexample -- the six pointers were never all the same kind of object. Combined: 11 of 11 sub-list payloads across both levels have exactly five blocks, the first three at offsets 0, 32, 64. The fixed-point payloads have an exact signature: byte 3 of every 4-byte group is 0x80 in 100% of cases -- 52/52, 40/40, 48/48 over the first 512 bytes of the three level 1 samples, and the same across all nine level 0 payloads. That separates the two payload kinds without the record tag, which does not select them. Correction: level 1's record tags are not level 0's. The same scan finds 18 04 04 00 01 headers against 19, plus 6 02 01 00 01 against 10, and byte 11 is no longer constant: 0x30 on 10, 0x00 on 5, 0x20 on 2, 0xbc on 1, where level 0 had 0x30 on all 19. "Byte 11 is 0x30, constant" was a level-0 partition result written up as universal; across both levels it takes four values. Fixed-point payload entropy over all nine level 0 payloads is 5.51 to 5.89 bits per byte against 8.0 for uniform, and the mean of the s16 reading varies per payload from -82 to -907 -- structured, and consistent with vertex positions relative to a per-payload origin. Not established: what the five blocks are, and how the fixed-point data decodes to vertices. Its entropy is far below random, so it is compressed or permuted rather than stored plainly, and the permutation table seen once in 0x009376f0 remains unexplained.
2026-10-12 02:31:27 +02:00
parent 186a700f32
commit af0b1aa949
1 changed files with 61 additions and 0 deletions
@@ -565,3 +565,64 @@ comparison; the permutation table was not among them.
 same word, and what moves blocks 4 and 5 -- their offsets are not monotone in
 the count (`count` 21 gives 280 and `count` 36 gives 400 and 404), so something
 inside the earlier blocks sets them.
+
+## Partitioned across two levels: the sub-list shape is universal, the payload kinds are not mixed
+
+The five-block result was measured on level 0 only. Rule 3a asks for the same
+measurement per partition, so it was repeated on level 1's savestate before
+being written up as a property.
+
+**Range measured:** savestate slot 2 (level 1), RAM `0x22a000..0x28f52f`,
+415,024 bytes, then six of its pointer-bearing records read to `count * 16`.
+
+**The six sampled pointers split 3/3 between the two payload kinds:**
+
+| pointer | count | first four bytes | classification |
+|---|---|---|---|
+| `00949430` | 41 | `00 00 00 30` | sub-list |
+| `009496c0` | 13 | `69 b0 bf 80` | fixed-point |
+| `00957970` | 36 | `00 00 00 30` | sub-list |
+| `00957bb0` | 10 | `58 7e 8d 80` | fixed-point |
+| `0095b740` | 12 | `37 49 41 80` | fixed-point |
+| `0095d6d0` | 57 | `00 00 00 30` | sub-list |
+
+Taking all six as sub-list gives 3/6 with five blocks. Taking only the three
+that actually open `00 00 00 30` gives **3/3**, and the first three blocks land
+at 0, 32, 64 in all three:
+
+    00949430  41  blocks at 0, 32, 64, 308, 428
+    00957970  36  blocks at 0, 32, 64, 268, 376
+    0095d6d0  57  blocks at 0, 32, 64, 400, 572
+
+The three fixed-point payloads have **zero** `00 00 00 30` blocks, as
+expected. So the earlier 3/6 was my sampling, not a counterexample: the six
+pointers were never all the same kind of object.
+
+**Combined: 11 of 11 sub-list payloads across both levels have exactly five
+blocks, the first three at offsets 0, 32, 64.**
+
+**The fixed-point payloads have an exact signature.** Byte 3 of every 4-byte
+group is `0x80` in 100% of cases -- 52/52, 40/40 and 48/48 over the first 512
+bytes of the three level 1 samples, and the same holds across all nine level 0
+payloads. That is a clean one-bit-per-group marker and is what separates the
+two payload kinds without needing the record tag, which the previous entries
+established does not select them.
+
+**Level 1's record tags are not level 0's.** Scanning the same 64 KB for
+`04 04 00 01` headers gives 18, against 19 on level 0, plus 6 `02 01 00 01`
+against 10. And byte 11 is no longer constant: `0x30` on 10, `0x00` on 5,
+`0x20` on 2 and `0xbc` on 1. Level 0 had `0x30` on all 19.
+
+That corrects an earlier statement. "Byte 11 is `0x30`, constant" was a
+level-0 partition result written up as universal. Across both levels it takes
+four values. The constancy was never a property of the format.
+
+**Fixed-point payload entropy**, all nine level 0 payloads read 4,096 bytes:
+5.51 to 5.89 bits per byte, against 8.0 for uniform. Structured rather than
+random, and `mean` of the `s16` reading varies per payload from -82 to -907,
+which is consistent with vertex positions relative to a per-payload origin.
+
+**Not established.** What the five blocks are, and how the fixed-point data
+decodes to vertices -- the payload entropy is far below random, so it is
+compressed or permuted rather than stored plainly, and the permutation table
+seen once in `0x009376f0` remains unexplained.