diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md
index 62bc6f10..07052de7 100644
--- a/docs/re/REFUTED.md
+++ b/docs/re/REFUTED.md
@@ -35,6 +35,10 @@ 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)
 * "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 13209319..6602958d 100644
--- a/docs/re/ui-title-build-map.md
+++ b/docs/re/ui-title-build-map.md
@@ -220,10 +220,33 @@ 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.
 
-❔ **Not confirmed:** that 2.2 s equals the loop's own declared cycle. `screen
-info` prints the element's *placement* keyframes (`ptloop01` is
-`[70 100 238 250]`) but not the frame count inside the `.rat`, and I did not open
-it. So the period is measured, not read.
+### ❔ The loop record was opened, and its cycle is still not readable
+
+The `.rat` was located and partly confirmed, but its **keyframe times are not**.
+
+`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`.
+
+| offset | value | |
+|---|---|---|
+| `+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 |
+
+**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.
+
+**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.
 
 **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.