diff --git a/docs/re/structures/regn-map-grid.md b/docs/re/structures/regn-map-grid.md
index 02740af..bfe0c7c 100644
--- a/docs/re/structures/regn-map-grid.md
+++ b/docs/re/structures/regn-map-grid.md
@@ -461,4 +461,32 @@ gave for it was not evidence.
 *boundary* moves, and the four integer words I described as "four zeros" move
 with it into the record they describe — which is where the face adjacency, and
 the answer to the cell→geometry question, was hiding. See branch
-`auto/regn-reader` for the tetrahedral decode.
\ No newline at end of file
+`auto/regn-reader` for the tetrahedral decode.
+
+## ✅ Independent confirmation of the face decode
+
+**2026-08-26.** I re-derived the other branch's central check with my own code,
+my own reading of the record, and my own control — rather than accepting the
+number.
+
+Reading at base `chunk + 0x10`, taking the plane at intra-record `+0` and the
+**three `u16` vertex indices at `+32`**, and asking whether each named vertex
+satisfies its own face's plane equation:
+
+| | |
+|---|---|
+| faces where **all three** named vertices lie on the plane | **133 573 / 133 573 (100.00 %)** |
+| a **random** vertex lying on that plane (control) | 2 782 / 400 719 = **0.69 %** |
+
+A 100 % against a 0.69 % baseline is not a fit — the face record genuinely names
+the vertices of its own plane, and the `+0x10` base together with this layout is
+right.
+
+That also settles the record-boundary question from my side: the `u16`s that
+describe a plane sit **after** it in the same 48-byte record. My earlier reading
+of "four zeros at the start of each record" was those integers seen 16 bytes out
+of position, one record late.
+
+This is worth having in the corpus independently of the other branch: two
+different implementations, two different guesses at the intra-record layout, the
+same 100 %.
\ No newline at end of file