diff --git a/docs/re/plate-pulses-via-ptbtn00f.md b/docs/re/plate-pulses-via-ptbtn00f.md
new file mode 100644
index 00000000..a14a589f
--- /dev/null
+++ b/docs/re/plate-pulses-via-ptbtn00f.md
@@ -0,0 +1,82 @@
+# ✅ The plate **does** pulse — but `ptbtn00` is not what loops. `ptbtn00f` is, on a declared **120-unit** cycle
+
+**Status: ✅ measured for the pulse; ✅ decoded for the period's source; ❔ the
+per-frame series does not exist.** 2026-09-02. Instruments: ⟨disc⟩ for the loop
+length, ⟨capture⟩ for the pulse itself.
+
+Answers the port's question — *does the `PRESS Ⓐ` plate pulse in the running game,
+and with what period?* — and **corrects the premise it was asked under**.
+
+---
+
+## The correction first, because it changes where to look
+
+The port asks whether `ptbtn00`'s declared `0:0 214:0 236:255 238:255 244:0`
+loops at `t = 244`. **It does not.** `ptbtn00` ramps up, holds, extinguishes, and
+stays out.
+
+> **The pulse is a different element.** `ptbtn00f` — the plate's focus/glow variant,
+> reached through `focus_link` and carrying **no top-level element of its own** —
+> declares a **120-unit loop** ⟨disc⟩.
+
+That is why a reader looking only at `ptbtn00` sees a one-shot: the looping
+element is the one that a declaration-order walk never reaches.
+📌 It is also the same element that needed the by-name accessor in
+`ui_layout` — `ptbtn00f.t32` is in `build.sprites` with nothing pointing at it —
+so this is the second time that element has been invisible to a walk that only
+follows declared elements.
+
+## The measurement that exists
+
+[`title-plate-delay-measured.md`](title-plate-delay-measured.md), from two boots
+on 2026-08-29:
+
+> *"its pulse is the focus record `ptbtn00f`, measured here at **2.12 / 2.19 /
+> 2.34 / 2.31 s** over four intervals, mean **2.24 s**"*
+
+**Cross-check against the disc, which is the part that makes it more than a
+stopwatch reading:** 120 declared units at the rate law
+([`clock-rate-follows-the-vblank.md`](clock-rate-follows-the-vblank.md):
+`units/s` = display refresh rate) is **2.000 s** at 60 Hz. Measured mean **2.24 s**
+— **12 % long**, in the direction and roughly the size Canary's slower-than-real
+pacing produces. Declared period and measured period agree.
+
+**So: yes, it pulses, and the period is 120 units.**
+
+## ⚠️ What this is NOT, stated plainly
+
+The port asked for a **per-frame series**, and **this is not one.**
+
+* Those four intervals come from a **screenshot probe** — the weaker of the two
+  instruments, and one carrying a wall-clock duration off an emulator whose pacing
+  is load-dependent. It is the instrument class that has cost this corpus four
+  withdrawn timing claims.
+* The strong instrument — per-frame vertex alpha off the guest's own buffer, the
+  one that settled the splash — **has never reached this screen.** Five capture
+  attempts, each blocked differently: wall-clock timeout, frame cap, a
+  self-matching `pkill`, and the fact that the title sits past the **137.7 s**
+  attract movie at ~1.3–1.8 presents per decoded movie frame.
+
+**For the port:** the *fact* and the *period* are answerable now — a 120-unit
+cycle, not a 244-unit one, driven by `ptbtn00f` and not `ptbtn00`. The
+**trajectory within a cycle** is not, and I will not infer its shape from the
+declared keyframes when the whole point of the splash exercise was that only a
+capture could confirm the shape.
+
+## Refutation attempt, recorded per the adversarial duty
+
+**Target:** the port's framing that the question is *"whether the timeline loops
+at 244 or something else drives it."*
+
+**Result: the disjunction is REFUTED — both halves are wrong about `ptbtn00`.** It
+does not loop at 244, and nothing else drives *it*; a **different element** loops,
+on 120. The port's instinct not to infer from "PRESS START prompts usually blink"
+was right, and the answer turned out to be one element sideways rather than one
+timing constant away.
+
+## Reach
+
+⟨disc⟩ for the 120-unit loop, so it generalises to every screen carrying that
+element. ⟨capture⟩ ×2 boots for the pulse, at four intervals, via the screenshot
+probe. **No per-frame series, on any instrument, for this element** — that gap is
+real and is what the next title-reaching capture should spend itself on.