diff --git a/docs/re/data/title-sweep-drawn-at-rest.txt b/docs/re/data/title-sweep-drawn-at-rest.txt
index a27cee86..8a95d107 100644
--- a/docs/re/data/title-sweep-drawn-at-rest.txt
+++ b/docs/re/data/title-sweep-drawn-at-rest.txt
@@ -70,3 +70,42 @@
 # time while VdSwap frames arrive at the ~28.1-28.5 fps this corpus measures for
 # the idle title, the ratio is 30/28.5 = 1.053 -- close to the observed 1.07.
 # Untested.
+
+################################################################################
+# CAN THE fps ASSUMPTION BE REMOVED? Three routes, all closed. 2026-08-30.
+#
+# sylpheed-port's caveat: two strips agreeing to three significant figures
+# constrains the strips TO EACH OTHER, not the absolute rate -- both ratios come
+# from ONE capture under ONE fps assumption, and a systematic error there scales
+# both identically. Correct, and I could not remove it.
+#
+# ROUTE 1 -- compare the leaf against a TOP-LEVEL clock in the same capture, so
+# fps cancels in the ratio. NOT AVAILABLE: on a settled title nothing top-level
+# moves; that is what settled means. Every varying quad in the capture is a leaf.
+# The plate looked like a candidate at 538x76 with a clean ~56-frame pulse, but
+# build 2's ptbtn00 is a one-shot fade (0,0,255,255,0 at t=0,214,236,238,244) --
+# the repeating pulse comes from its own nested .rat, so it is a leaf too.
+#
+# ROUTE 2 -- fit the same strips in the TRANSITION captures, which do contain a
+# top-level clock (the fade quad, 8 declared units measured at 2.0 units/frame).
+# The strips are present, but the fits are not measurements:
+#
+#   capture      strip A slope   rms resid   x travelled
+#   fadecap4     +1.943 px/f     26.70 px    147 px over 44 frames
+#   fadecap2     +3.566 px/f     16.75 px    147 px
+#   titledraw2   +4.287 px/f      3.59 px    627 px over 148 frames
+#
+# An rms residual of 17-27 px against 147 px of travel is scatter, not a line.
+# Only titledraw2 -- 627 px of travel at rms 3.6 -- is a real fit. The apparent
+# disagreement between captures is a NON-measurement, not a contradiction, and
+# quoting 1.94 or 3.57 as a second sample would have been the same error as the
+# 6-7 px/frame eyeball.
+#
+# ROUTE 3 -- read the emulator's fps from its own log. Not printed.
+#
+# 🟡 SO: 1.07 units/frame stands on ONE capture, exactly as sylpheed-port said. It
+# rules out a per-record quirk (two strips, different cycles, same ratio) and it
+# does NOT pin the absolute rate. The test that would is measuring the same strips
+# at a deliberately different emulator frame rate -- if px/frame is unchanged the
+# leaf is frame-locked, if it scales with 1/fps the leaf runs on wall time. That
+# has not been run.