diff --git a/docs/re/f6-unit8-leaf-clock-in-title-units.md b/docs/re/f6-unit8-leaf-clock-in-title-units.md
new file mode 100644
index 00000000..69f23df1
--- /dev/null
+++ b/docs/re/f6-unit8-leaf-clock-in-title-units.md
@@ -0,0 +1,70 @@
+# F6 unit 8 — the leaf's clock in TITLE units: **offset +40, rate ≈ ½**
+
+**Status: ✅ measured ⟨capture⟩ ×1.** 2026-09-02. The two numbers the port asked
+for, both from one capture so nothing crosses runs.
+
+**Question:** what are the leaf's clock origin and rate, expressed in title units?
+**Look at:** the title's own rate measured (not assumed), then the leaf against it.
+**Not covered:** unit 2's parent-alpha question; `pteff03a`'s absence.
+
+---
+
+## 1 — the title's rate, which unit 4 flagged as an assumption and is now measured
+
+`ptcopyright` declares α `0→255` across `t = 138…160` — **22 units**.
+
+```
+rising run: 22 frames    alphas 11 23 34 46 57 69 81 92 104 115 127 139 …
+                         modal step 12/frame
+```
+
+**22 frames for 22 declared units = 1.0000 title units per frame.** The step
+agrees independently: `255/22 = 11.6` against a measured modal 12.
+
+✅ This also **confirms the splash's 1 unit/present on a second screen**, which it
+had never been checked against.
+
+## 2 — the leaf's rate, anchored on the wrap rather than the endpoint
+
+```
+leaf first drawn   frame  746
+wrap               frame 1914      => 1168 frames for the declared 600-unit loop
+                                   => 0.5137 units/frame
+```
+
+⚠️ **This supersedes unit 3's 0.463.** That figure divided 540 units by 1167
+frames, but the declared track is **stationary from t=540 to t=600** (`540:1521`,
+`600:1521`) — so the endpoint I anchored on is where motion *stops*, not where the
+loop ends. The wrap is a clean event and gives the honest denominator.
+
+## 🔴 The two numbers
+
+| | |
+|---|---|
+| **origin offset** | leaf `t=0` at title frame **746**, title starts at **706** → **+40 title units** (title rate is 1.000, so frames = units) |
+| **rate** | **0.514 × the title's rate** — within 3 % of exactly **½** |
+
+`leaf_t = 0.514 × (title_t − 40)`
+
+The port's arithmetic was `0.463 × (title_t − 40)`. **The offset is confirmed; the
+rate is revised upward to ≈ ½**, and ½ is close enough to a round number that I
+would treat "the leaf runs at half the title's clock" as the likely intent.
+
+## ⚠️ The disagreement they asked me not to smooth
+
+The port says the human reports **the animation itself looks correct, only starting
+early**. But their renderer runs the leaf on the title's clock unscaled — at
+**1.0×** where this measures **0.514×**. If that is right, their sweep crosses the
+screen **twice too fast**, which a viewer should notice as well as the early start.
+
+**Either the human's "looks correct" is about the effect rather than its speed, or
+one of these two measurements is wrong.** I am flagging it rather than resolving
+it: my rate rests on a single wrap in a single capture, and a second wrap — a
+longer title capture — would settle it by giving a wrap-to-wrap period instead of
+a start-to-wrap one.
+
+## Reach
+
+⟨capture⟩ ×1. The title rate has two independent readings within the one capture
+(run length and step size). The leaf rate has **one** wrap and is the weaker of the
+two numbers.