diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md
index 6a656f8..2a2d526 100644
--- a/docs/formats/core-data-regions.md
+++ b/docs/formats/core-data-regions.md
@@ -292,3 +292,30 @@ do not: an earlier "256x236" is wrong and should not be used.
 So the sky region is not one thing. Its first ~60 KB is an image; the rest is
 whatever the layer offsets address. Both halves still need work, and the
 image is the tractable one.
+
+## Re-verified: the 368 stride, against a matched control
+
+The sky autocorrelation was found to be inflated by a control that did not
+match the data, so the 368 result was re-checked the same way.
+
+**Range measured:** each level's post-shrub region start, first 65,536 bytes.
+
+**Method:** as before, but the control is the same bytes shuffled rather than
+uniform random bytes. Shuffling preserves the value distribution and destroys
+only the ordering, which is exactly what the control needs to do.
+
+**Result:**
+
+- Level 0's region is evenly distributed: 256 distinct byte values, most
+  common only 15.6%. Uniform random was therefore the *appropriate* control
+  here, and the shuffled control independently confirms it, reading **0.0000**
+  at strides 340, 368 and 4.
+- Level 0 peak remains 368 at 0.1110, against 0.0000 for the matched control.
+- Recomputed across all levels with matched controls: **24 of 24 peak at
+  exactly 368, every one with excess above 0.05.**
+
+So the 368-byte period stands, now with a control appropriate to its data.
+The contrast with sky is the point: the same statistic on the same kind of
+question gave a real answer in one region and an inflated one in the other,
+and the only thing that told them apart was whether the control matched the
+byte distribution.