diff --git a/docs/re/data/title-sweep-drawn-at-rest.txt b/docs/re/data/title-sweep-drawn-at-rest.txt
index 05c53384..93625a29 100644
--- a/docs/re/data/title-sweep-drawn-at-rest.txt
+++ b/docs/re/data/title-sweep-drawn-at-rest.txt
@@ -150,3 +150,49 @@
 # when the capture is ARMED rather than when it completes, so it returned 0.728 s.
 # The 3.6x boot slowdown says the limit took effect; it does not say fps went from
 # 28 to 15. So the RATIO is measured and the ABSOLUTE rate still is not.
+
+################################################################################
+# ❔ THE LEAF'S CLOCK: UNDECODABLE, WITH REACH. Four models, four refutations.
+#
+# 1. FRAME-LOCKED (fixed units per submitted frame). Predicts px/frame unchanged
+#    under --framerate_limit. Measured -4.348 -> -2.032, a 2.14x change. REFUTED.
+#
+# 2. WALL-CLOCK (fixed units per real second). Predicts px/frame LARGER at a lower
+#    limit, since more wall time passes per frame. It got SMALLER. REFUTED by
+#    direction.
+#
+# 3. FIXED WALL-CLOCK SAMPLING -- sylpheed-port's suggestion that my samples might
+#    be taken at a constant real-time rate while guest time slows, which would
+#    reproduce the observed direction. CHECKED, NOT ASSUMED: every capture reports
+#    `done: ... over 150 frames` and spans frame 1..149, so the capture is indexed
+#    by guest VdSwap submissions in all three runs. REFUTED.
+#
+# 4. PER UI-DRAWING FRAME. At limit 15 only 99 of 150 frames carry UI draws
+#    against 131 at default, so "submitted frame" and "UI update" diverge with the
+#    limit. Refitting against the strip's own appearance index instead:
+#       default   -5.773 px/appearance   limit 15  -3.687   ratio 1.57
+#    Not invariant either. REFUTED.
+#
+# 🔴 AND THE TWO SLOWDOWNS STILL DISAGREE: the boot slowed 3.58x (title at 862 s
+# against 241 s) while the rate ratio is 2.14 per submitted frame or 1.57 per
+# appearance. Three measures of one slowdown, no two of which agree. Whatever the
+# leaf's clock is, it is none of the four above, and the absolute rate stays
+# unpinned.
+#
+################################################################################
+# ✅ TWO THINGS THE SAME DATA DOES ESTABLISH.
+#
+# THE ROTATION IS CONFIRMED FROM THE ORACLE. sylpheed-port's export carries
+# rotation_deg +30 on pteff03 and -45 on pteff03a, read from the file. The AABB
+# height of a rotated quad predicts, from the DECLARED scale alone:
+#     pteff03   400x1080 at +30deg -> 1135.3   observed 1134   (0.12% off)
+#     pteff03a  400x1440 at -45deg -> 1301.1   observed 1303   (0.15% off)
+# Two angles, two scales, both to better than 0.2 %. A file-side field confirmed
+# by the running game, and it fixes which strip is which.
+#
+# 🔴 WHICH MAKES sylpheed-port's INVERSION REAL. Height 1134 IS pteff03 -- the leaf
+# whose declared track is PERFECTLY linear, +4.0000 px/unit over both segments --
+# and that is the strip my sign-change gate FAILS. Height 1303 is pteff03a, the
+# slightly non-uniform one (-4.0667 then -4.0625), and it PASSES. So the curvature
+# is in the strip whose source data is exactly straight: it is not in the disc, and
+# it is either in the measurement or in how the game advances the record.