diff --git a/docs/re/structures/regn-map-grid.md b/docs/re/structures/regn-map-grid.md
index 94821e9..f8b0a5e 100644
--- a/docs/re/structures/regn-map-grid.md
+++ b/docs/re/structures/regn-map-grid.md
@@ -373,4 +373,43 @@ nothing rises above chance.
 object in the executable and watch which fields it dereferences. That is static
 PE work (`/work/*.pe`, offset = VA − 0x82000000) of the same kind that cracked
 the `.slb` packing phase, and it is the honest next step rather than a
-twenty-first correlation.
\ No newline at end of file
+twenty-first correlation.
+
+## ⚠️ Open conflict with `auto/regn-reader` over the `+0x10` base
+
+**2026-08-26.** Branch `auto/regn-reader` decodes `REGN` as a **tetrahedral
+navigation mesh** and reports the cell→geometry link solved, with strong checks
+(faces passing through 3 of 4 tet vertices, 253 722/253 722; portal cost equal to
+the distance between face centroids, 380 460/380 460). Its load-bearing structural
+claim is that the `POF0` fixup base is **`chunk + 0x10`**, and therefore that
+"every offset previously recorded on that page was read 16 bytes early" — offered
+as the reason the ~20 correlation tests on this page returned chance.
+
+**I could not reproduce that as stated, on the one thing here that is
+independently checkable.** Re-reading the plane list at both bases:
+
+| | records | unit normals |
+|---|---|---|
+| section at `chunk + offset` (what this page used) | 133 573 | **133 573 (100.00 %)** |
+| section at `chunk + 16 + offset` | 133 573 | **0 (0.00 %)** |
+
+And the plane identity `n·p + d = 0` holds to float round-off at the **unshifted**
+base. A 16-byte shift destroys it completely. So for *this* record the unshifted
+reading is right, and the blanket statement is not.
+
+🟡 **The likely reconciliation is bookkeeping, not disagreement.** The other
+branch describes a 48-byte **face** record whose plane fields sit at a different
+intra-record offset; `chunk+16` with the plane at `+0` addresses the same bytes as
+`chunk+0` with the plane at `+16`, which is exactly what this page uses. If so
+both readings are correct and only the origin convention differs — but that is a
+guess, and I am not adopting either page's wording until it is checked.
+
+**Also confirmed here, incidentally**: my section-0 point test passes at **100 %
+at both bases**, so it never had the power to distinguish them. That test could
+not have caught a 16-byte error and should not be cited as if it validated the
+offsets.
+
+❔ Until the conflict is resolved, treat the plane/face layout on this page as
+verified by its own arithmetic and the tetrahedral decode on `auto/regn-reader`
+as verified by its own — and do not merge the two offset conventions without
+re-running one check from each.
\ No newline at end of file