diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md
index a870785..6a656f8 100644
--- a/docs/formats/core-data-regions.md
+++ b/docs/formats/core-data-regions.md
@@ -254,16 +254,40 @@ control of the same size reads flat at 0.0000 for every stride tested.
 
 **Result:**
 
-- Peak stride in the first 64 KB is **256** at a 0.772 match rate, against a
-  flat random control. Strides 255, 257 and 4 score nearly as high, which is
-  what a true period looks like smeared by sampling.
+- Peak stride in the first 64 KB is **256** at a 0.772 match rate. Strides 255,
+  257 and 4 score nearly as high, which is what a true period looks like
+  smeared by sampling.
 - Across levels the peak is 256 on 21, 512 on 5 and 128 on 1. 512 and 128 are
   a harmonic and a sub-multiple, so the fundamental period is **256 bytes**.
-- The periodicity holds from `+0` to about `+60160` and then stops: **236 rows
-  of 256 bytes**, i.e. a 256-wide, 236-tall image at one byte per pixel.
-- The remaining ~362,240 bytes of the sky region are *not* 256-periodic and
-  remain unidentified. That is 86% of the region, and it is where the offset
-  table seen at `+0x20` earlier points.
+
+**Correction to the control.** The original comparison used uniform random
+bytes, which read flat at 0.0000 -- and made the 0.772 look like an enormous
+signal. It is not: 91.8% of the region's bytes are the same value (`0x07`), so
+a stride-256 comparison matches trivially wherever both positions are `0x07`.
+
+The right control is the same bytes shuffled, which preserves the value
+distribution and destroys only the ordering. That control reads **0.512** at
+stride 256, not 0.0000. The true excess is 0.772 − 0.512 = **+0.26**, a real
+signal and a far smaller one than the original framing suggested.
+
+**And the extent is wrong too.** Re-measured against the matched control, the
+excess over the value distribution is:
+
+| offset | excess |
+|---|---|
+| +0 .. +49152 | +0.38 .. +0.45 |
+| +53248 | +0.26 |
+| +57344 | +0.07 |
+| +61440 | −0.13 |
+
+So the 256-periodic data ends between `+53248` and `+57344` — somewhere in
+rows 205 to 224 — **not** at `+60160` as first reported. The original figure
+came from a raw threshold with no distribution control, and 91.8% of one byte
+value drags that threshold wherever the dominant run ends.
+
+The 256-byte period itself stands, cross-checked on 21 of 27 levels with the
+remaining levels showing its harmonic and sub-multiple. The image dimensions
+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