diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md
index 1726b44..5f9d89c 100644
--- a/docs/formats/core-data-regions.md
+++ b/docs/formats/core-data-regions.md
@@ -1774,6 +1774,27 @@ Within the all-zero case there is a third distribution: `i16[3] == 0` exactly
     high 0x00, low 1..255 83,490   the ordinary case, 92% at 1/4096
     high non-zero         6,271    0%, an encoding this reading does not see
 
+### The element layout differs between those cases
+
+Scoring all four slot pairs within the non-zero high-byte group, **no pair
+stands out** -- the best is `(6,7)` at 7.5% for a divisor of 4, against a 2-5%
+baseline:
+
+    i16[3] high byte NON-ZERO (n = 6,271)
+        pair         /1      /4     /16    /256
+        ( 0, 1)   100.0%   4.6%   3.5%   0.7%
+        ( 2, 3)   100.0%   2.0%   0.6%   0.0%
+        ( 4, 5)   100.0%   1.9%   0.3%   0.1%
+        ( 6, 7)   100.0%   7.5%   5.7%   4.5%
+
+So for those 6,271 vertices the 16 bytes are **not laid out as
+position/texcoord/normal** at all -- none of the four pairs carries fixed-point
+coordinates. Whatever they are, it is a different element shape, selected by the
+high byte of `i16[3]`.
+
+This also settles why the global score looked ambiguous: pooling the two layouts
+averages a 92% pair and a 7% pair into one number that describes neither.
+
 **Not established:** what any of those three cases means. Whether `i16[3]` is a
 texture index, a normal index, a flag or a combination is still open -- but it is
 now a field whose *role* is known, which is more than "packed word".