diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md
index 209fe91..e115181 100644
--- a/docs/formats/core-data-regions.md
+++ b/docs/formats/core-data-regions.md
@@ -1642,3 +1642,40 @@ commit concluded from the disc alone. Reading the header word at `+0x00` as an
 element count gave 0 of 922 blocks dividing; it is the byte offset to the payload,
 so the table it bounds has 16-byte records. The number was right and the reading
 was wrong, which is the error the packet-header identification corrected.
+
+## Collision payload: what the verbatim mapping settles, and what it does not
+
+With the payload confirmed verbatim in RAM, the disc bytes can be read directly.
+The grid dimensions are the **first two `u16`** of the payload -- level 0 reads
+**11 x 33 = 363 cells**, level 1 **24 x 16 = 384**, level 2 **1 x 53 = 53**.
+Level 2 being one cell wide is worth noting; the grids are not all similar in
+shape.
+
+**Disproved this round -- an ascending `u32` offset table.** A probe from payload
+`+1024` reads `f4ae0000 40af0000 c4b2000020b20000 ...`, which is three ascending
+values before the fourth goes *down* (`0xb2c4` to `0xb220`). Read as a table that
+was a three-value impression. Scanning all three levels for maximal ascending
+`u32` runs of 8 or more entries finds **zero**, on every level.
+
+**Disproved this round -- a global alternating-zero stride.** The head of level 0
+shows an obvious `(value, 0)` pattern from about `i16[37]` onward:
+
+    [32..] [1808, 1872, 2198, 0, 34, 86, 25848, 1, 25824, 1,
+           -13028, 0, -12284, 0, -12228, 0, -12716, 0, ...]
+
+Measured over the whole payload rather than the first 96 values, both alignments
+score far below what that sample suggests:
+
+    even-slot aligned: second half zero on 18% of pairs
+    odd-slot aligned : second half zero on 13% of pairs
+
+The sample again. What the global numbers *do* say is that the payload is heavily
+zero-bearing -- 18% against a chance rate of about 0.0015% -- which is what a
+sparse or variable-length encoding looks like, and is consistent with the
+variable-length reading established earlier. The 18-against-13 split is a real
+alignment preference but a weak one.
+
+**Still not decoded.** The cell layout. The useful position now is that the bytes
+can be read as they are, and that they are sparse and variable-length rather than
+fixed-stride -- so the next attempt should look for a terminator-delimited walk
+through the sparse region, not for a record size.