diff --git a/docs/re/structures/mcol-collision.md b/docs/re/structures/mcol-collision.md
index cf9f3c02..af41565a 100644
--- a/docs/re/structures/mcol-collision.md
+++ b/docs/re/structures/mcol-collision.md
@@ -234,6 +234,52 @@ evidence.)
 which is the same shape as `REGN`'s `cell → item → refs → geometry`, as the two
 formats' shared header and shared count-1 convention already suggested.
 
-❔ Still open: the `0x54` and `0x58` blocks (neither is reached by this chain),
-what the indexed points form — triangles would want n divisible by 3 — and the
-44-vs-4 488 accounting is exact, so there is no second pointer species to find.
\ No newline at end of file
+❔ Still open: the `0x54` and `0x58` blocks (neither is reached by this chain).
+What the `u16` entries index is **not** the point block — see immediately below.
+
+## ❌ The `u16` entries do NOT index the point block — and the weak test said they did
+
+**2026-08-26.** Two tests, and the contrast between them is the point of this
+section.
+
+**Not a triangle list.** If the `u16` array held triangle corners, every count
+would be divisible by 3. Counts modulo 3 across all objects:
+
+    n % 3 == 0   639        n % 3 == 1   2 063        n % 3 == 2   1 786
+
+Spread across all three residues. Refuted.
+
+**Not cell-local either.** A B record is reached *through* a specific cell, so a
+point it references should lie in that cell. With a random-point control:
+
+| | |
+|---|---|
+| referenced point inside the cell that reached it | 142 / 17 871 = **0.79 %** |
+| a random point inside that cell (control) | 85 / 17 871 = **0.48 %** |
+
+Chance. So whatever the `u16`s address, it is not the `0x5C` point block in any
+spatially meaningful way.
+
+### ⚠️ This is the bound-check hazard caught in the act
+
+One section above, the same `u16` entries scored **18 379 / 18 379 (100 %)** on
+"are these valid `0x5C` point indices". I flagged that at the time as the weak
+bound-check rather than evidence, and recorded it as *consistent* rather than as
+a finding. **That caution was correct**: the powered version of the same question
+now returns chance.
+
+This is the fifth appearance of the pattern across `REGN` and `MCOL`, and the
+first time both halves have been run side by side on the same field, so it is
+worth stating exactly:
+
+> A bound-check asks *"could this be an index?"*. Almost always, yes — the answer
+> is set by how large the target collection is, not by whether the field means
+> anything. The powered version asks *"does the thing it points at make sense
+> where it was reached from?"*, and only that version can be wrong.
+
+Had the 100 % been written up as the decode, this page would now carry a
+confident and false statement about `MCOL`'s geometry.
+
+❔ What the `u16`s index is open. A datum for the next attempt: the maximum
+`u16` is consistently ≈ **0.75 ×** the point count (923/1 232, 1 019/1 360,
+1 163/1 552, 59/80) — too consistent to be coincidence, and not explained.
\ No newline at end of file