re: MCOL's 32-byte record is a cell entry, and there are two interleaved arrays

Read as 8 big-endian words, word 0 as four bytes is (x,y,z,1) -- a 3-D cell
index, matching the object's 5x5x5 grid. Words 4-6 are a position and word 7 a
positive scalar (a bounding sphere); word 1 is a count, word 2 the relocated
pointer. Every record pointer lands in the same region, 8976/8976, each a fixed
distance on with the same stride -- so there are two parallel arrays, A and B.

The 50% is the tell. Three independent criteria -- byte 3 == 1, valid cell
index, sphere reaches that cell -- all land on 50.0%, which says half the
records are not this type rather than that the reading half-works. The POF0 slot
list interleaves both arrays and I was testing B's records against A's layout.

So array A is a per-cell record, the same role REGN's section 3 plays. Array B
is unread, and the criteria have not yet been re-run on A alone -- if the
reading is right they should go to 100%.

docs/re/structures/mcol-collision.md

@@ -87,4 +87,47 @@ is a reading of the shape; none of the four blocks has been decoded.
 ❔ Still open: the record layout, what the index block indexes, the **one object
 in eleven** where `0x74` does not land 8 before the array, and the 7.3 % of gaps
 that are not 32 (they are the boundaries between runs, but that has not been
-checked).
+checked).
+
+## 🟡 The 32-byte record — a cell entry, and there are two interleaved arrays
+
+**2026-08-26.** Reading each record as 8 big-endian words (record start =
+pointer slot − 8), the first entries of the smallest object are:
+
+    @0x6780  00000001 00000001 00007710 00000000 00000000 00000000 00000000 47295092
+    @0x67A0  01000001 00000001 00007730 00000000 …
+    @0x67C0  02000001 00000001 00007750 00000000 46023555 C6023555 C6023555 471FA1A7
+    @0x6820  00010001 00000001 000077B0 00000000 …
+
+Word 0 read as **four bytes** is `(x, y, z, 1)` — a **3-D cell index**. That
+object's grid is 5×5×5 (bbox ±25 000, cell 10 000), and the values run 0–4 in
+the first byte and step the second byte at the right point. Words 4–6 are a
+position and word 7 a positive scalar — a bounding sphere. Word 1 is a count and
+word 2 the relocated pointer.
+
+**Every record pointer lands in the same region — 8 976 / 8 976 (100 %)** — and
+each points 0xFA0 further on with the same stride, so there are **two parallel
+arrays**, not one: array A at `0x6780` and array B at `0x7720`.
+
+### The 50 % is the tell, not a failure
+
+Testing the cell-index reading over *all* relocated records gives almost exactly
+half:
+
+    byte 3 == 1                                  4 491 / 8 976  (50.03 %)
+    bytes 0..2 a valid cell index                4 488          (50.00 %)
+    the record's sphere reaches that cell        4 485          (49.97 %)
+
+Three independent criteria all landing on 50.0 % is not a partial fit — it says
+**half the records are not this type**. The `POF0` slot list interleaves both
+arrays, and I was testing array B's records against array A's layout. Reported as
+a rate it would read like a half-working hypothesis; split by array it is two
+clean populations.
+
+🟡 So array A is a **per-cell record** — cell index, count, pointer into array B,
+bounding sphere — the same role `REGN`'s section 3 plays. ❔ Array B's layout is
+unread, and the split has not yet been re-run per array to confirm 100 % on A.
+
+**Next step**: separate the two arrays by their start addresses (`0x74` → A,
+A's pointers → B), then re-run the three criteria on A alone. If the reading is
+right they go to 100 %.