diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md
index a1a6694..b5869ff 100644
--- a/docs/re/METHOD.md
+++ b/docs/re/METHOD.md
@@ -249,3 +249,9 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   second is the intro movie's own opening frame. Reading the capture alone gives
   "three logo screens". Cross-check a repeat against what is *supposed* to be
   playing at that moment before counting it as its own screen.
+* **Do not hard-code an expected element count into a structure scan.** Looking
+  for a `.rat` record's keyframes, I required 29 strictly-increasing times because
+  a header word read `30`. The records hold **three** keyframes in exactly the
+  layout I was testing for, and the over-constrained filter reported the layout as
+  refuted. Scan for the *shape* (here: `0x??ffffff` fade words at a constant
+  stride) and let the count fall out.
diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md
index 07052de..9315ccf 100644
--- a/docs/re/REFUTED.md
+++ b/docs/re/REFUTED.md
@@ -35,10 +35,13 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
-* "a `.rat` leaf record's keyframes use the build's 40-byte placement-block
-  layout (time at `+36`)" → they do not. A strided monotonic scan over
-  `ptloop01.rat`/`ptloop02.rat` finds no increasing time sequence at any aligned
-  start. [`ui-title-build-map.md`](ui-title-build-map.md)
+* ~~"a `.rat` leaf record's keyframes use the build's 40-byte layout" → they do
+  not~~ — **withdrawn.** They do. The scan that "found nothing" required 29
+  increasing times; the records hold **three**. Decoded in
+  [`ui-title-build-map.md`](ui-title-build-map.md).
+* "the title's measured ≈ 2.2 s oscillation is the `ptloop01`/`ptloop02`
+  elements" → **mine, and refuted by decoding them.** Their sweeps run 7.5 s and
+  9.5 s; a 22 s capture showed 8 peaks, not 3. The period's source is unidentified.
 * "the developer splash cannot be rendered by `screen render` at all" → it can,
   with **`--all`**. It is only invisible to the *default* listing, which filters on
   `is_build`. [`ui-title-build-map.md`](ui-title-build-map.md)
diff --git a/docs/re/ui-title-build-map.md b/docs/re/ui-title-build-map.md
index 6602958..e35c81c 100644
--- a/docs/re/ui-title-build-map.md
+++ b/docs/re/ui-title-build-map.md
@@ -220,36 +220,44 @@ composition ([`INDEX.md`](INDEX.md), UI screen layout row). So the title carries
 looping element by construction; what is new is that it runs at ≈ 2.2 s and never
 stops.
 
-### ❔ The loop record was opened, and its cycle is still not readable
+### ✅ The loop records ARE decoded — and they are not what I measured
 
-The `.rat` was located and partly confirmed, but its **keyframe times are not**.
+`ptloop01.rat` is an **`opt `-linked leaf record**: in build 4 the chunk `opt `
+(size `0x0c`) carries the name, immediately followed by a `RATC` blob at
+**`0xbb5966`** (`ptloop02.rat` the same at `0xbb5a82`). Its pivot fields read
+`200`/`90`, matching `screen info`'s `pivot (200,90)` — the right blob.
 
-`ptloop01.rat` is an **`opt `-linked leaf record**, not a nested build: in build 4
-the chunk `opt ` (size `0x0c`) carries the name `ptloop01.rat`, immediately
-followed by a `RATC` blob at **`0xbb5966`**. `ptloop02.rat` is the same shape at
-`0xbb5a82`.
+**The keyframes use the ordinary 40-byte block layout**, starting at `+0x68`:
 
-| offset | value | |
+| | `ptloop01` → `pteff03.t32` | `ptloop02` → `pteff03a.t32` |
 |---|---|---|
-| `+0x004` | `0x001e0000` — **30** in the high half | the ~30 keyframes [`structures/ui-rat-layout.md`](structures/ui-rat-layout.md) predicts |
-| `+0x014` | `1` | name count |
-| `+0x018` / `+0x01c` | `1280` / `720` | design space |
-| `+0x020` | `pteff03.t32` (`pteff03a.t32` for loop02) | the sprite it places |
-| `+0x050` / `+0x054` | `200` / `90` | pivot — **matches `screen info`'s `pivot (200,90)` for `ptloop01`**, which confirms this is the right record |
+| kf0 | `t=150` x=**−639** α=`ff` | `t=150` x=**1721** α=`00` |
+| kf1 | `t=540` x=−39 α=`80` | `t=630` x=1111 α=`80` |
+| kf2 | `t=600` x=**1521** α=`ff` | `t=720` x=**−839** α=`ff` |
+| scale | 100 × 600 | 100 × 800 |
+| span | 150 → 600 = **450 units = 7.5 s** | 150 → 720 = **570 units = 9.5 s** |
 
-**But the times are not where a build's are.** A build's keyframes are 40-byte
-blocks with the time at `+36`. Scanning every 4-byte-aligned start across
-`+0x60 … +0x120` for 29 strictly-increasing values at a 40-byte stride finds
-**nothing**, in either record. So a leaf record's keyframe layout is *not* the
-build placement layout, and the loop's declared cycle cannot be read by that
-route.
+Y is constant at 270 and X runs off one edge to the other, so these are
+**horizontal light sweeps** — `loop01` left → right, `loop02` right → left.
 
-**The ≈ 2.2 s therefore stays measured, not decoded.** What a future attempt
-gains from this one is the record's address, the confirmed pivot, and one layout
-ruled out.
+### 🔴 Two things I wrote last iteration are wrong
 
-**For the port:** drawing build 4's resting pose and stopping will look wrong —
-the title has a continuous ≈ 2.2 s loop over it.
+**1. "A leaf record's keyframes are not in the build's 40-byte layout."**
+Withdrawn — they are, exactly. The scan that "found nothing" demanded **29**
+strictly-increasing times because I read the word at `+0x004` (`0x001e0000`) as a
+keyframe count. These records hold **three** keyframes. A filter that hard-codes
+the expected count rejects the right structure; whatever the `30` is, it is not
+the number of keyframes here.
+
+**2. "The ≈ 2.2 s oscillation is the `ptloop` elements."** Withdrawn — I asserted
+the link because build 4 declares those elements, not because anything showed it.
+The decoded sweeps run **7.5 s and 9.5 s**. A 22 s capture would show ~3 peaks
+from a 7.5 s cycle; it showed **8**. So the loops are *not* what the oscillation
+measured.
+
+❔ **What the ≈ 2.2 s period actually is remains unidentified.** Candidates not
+checked: `pteff01.t32` (`[50 71 118]`), the five `ptlogo_back2eff*` glows, or a
+combination. The measurement stands; only its attribution is withdrawn.
 
 ### ❔ The declared 4.08 s build-in was not tested