diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md
index dcfb543..ab255f6 100644
--- a/docs/port/HANDOFF.md
+++ b/docs/port/HANDOFF.md
@@ -61,6 +61,13 @@ authored version can be deleted.
   this milestone changes — every screen in scope is `GP_TITLE` — but do not ship
   `kind == 0x3002` as a general button test.
   (The kind is the 4th `u32` of the 60-byte declaration entry, at `+40`.)
+* **The title screen loops — it is not a still.** After building in, mean
+  luminance oscillates continuously at **≈ 2.2 s ± 0.4** (measured, 7 intervals
+  over a 22 s capture). Build 4 declares `ptloop01.rat`/`ptloop02.rat`, and
+  `loop*.rat` is a decoded **looping sprite animation**. Drawing the resting
+  pose and stopping will look wrong. ❔ Whether 2.2 s is the loop's declared
+  cycle is unread — `screen info` does not print the frame count inside a
+  `.rat`.
 * **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is
   ✅ correct for a vertical menu and is **not** a decoded neighbour graph — the
   disc's real navigation structure is unknown, and `opt ` is *not* a focus link
diff --git a/docs/re/ui-title-build-map.md b/docs/re/ui-title-build-map.md
index b89e4a9..1320931 100644
--- a/docs/re/ui-title-build-map.md
+++ b/docs/re/ui-title-build-map.md
@@ -199,3 +199,44 @@ tools/re-capture/pad.py tap A 0.30
 ```
 
 Mind the d-pad hold — see [`METHOD.md`](METHOD.md).
+
+## ✅ The title is not a still image — it loops, ≈ 2.2 s
+
+Recording the title at 10 fps for 22 s shows the screen **never settles**. After
+the build-in it oscillates by about ±0.5 in mean luminance, continuously:
+
+```
+peaks at   5.6  7.8  10.0  12.7  15.2  17.1  19.2  21.3 s
+intervals  2.2  2.2   2.7   2.5   1.9   2.1   2.1
+                                       mean 2.24 s
+```
+
+**measured**, n = 7 intervals, spread 1.9–2.7 s — peak-picking a low-amplitude
+signal is coarse, so read it as **≈ 2.2 s ± 0.4**, not a precise period.
+
+The mechanism is already decoded: build 4 declares **`ptloop01.rat` /
+`ptloop02.rat`**, and `loop*.rat` is a **looping sprite animation** rather than a
+composition ([`INDEX.md`](INDEX.md), UI screen layout row). So the title carries a
+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.
+
+**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.
+
+### ❔ The declared 4.08 s build-in was not tested
+
+That was the intent of this recording and it did not work. The title was reached
+by **skipping the movie with Ⓐ**, which cuts to black and brings the title up on a
+path that may not be the normal one; and the visible rise (≈ 2.7 s, from t ≈ 0.8
+to 3.5) is a *luminance* curve, which
+[`screen-transitions.md`](screen-transitions.md) already establishes is **not**
+the fade quad's ramp. So ≈ 2.7 s neither confirms nor contradicts build 4's
+declared `16 → 261` (4.08 s); the two are not measuring the same thing.
+
+Testing it properly needs the title reached **without** a skip, and a way to
+separate the quad from the elements — neither of which this recording had.