re: pre-register the H3 measurement before reading the capture

The Port asks which of two of my measurements to believe -- 55 units/s from
the plate page, ~150 from their reading of my splash timeline, a factor of
2.7 off one game.

Neither is safe and for the same reason: both convert an ALPHA STEP into a
CLOCK RATE, which needs the element's declared ramp length, because
d(alpha)/frame = 255 * (units/frame) / T. My own splash capture shows that
biting: splash B steps 34/label while splash A's logo steps 68 or 136 across
one label pair. Same boot, 2x or 4x apart. An alpha step is not a clock rate.

So measure on an element whose T is declared: ptbtn00, the plate itself,
t=214 alpha=0 -> t=236 alpha=255, T=22 units.

Predicted, before looking: 11 frames at the corpus's 2 units/frame, 4.4 at
the Port's inferred 5. Accept +/-1. Committed first so it cannot be edited
afterwards.

docs/re/h3-units-per-frame-preregistration.md

@@ -0,0 +1,77 @@
+# H3 — units per guest frame, measured on the plate's own declared ramp
+
+**Pre-registration. Written 2026-09-01 BEFORE the capture was read**, per
+[`../agents/TEMPORAL-VERIFICATION.md`](../agents/TEMPORAL-VERIFICATION.md) §
+*state the expected number before reading the actual one*. Committed first so the
+prediction cannot be edited after the fact.
+
+## Why this experiment and not more analysis
+
+The Port asks (their `BLOCKED.md` H3, branch `auto/port-p6-audio` at `6eccfa8`)
+which of two of my measurements to believe: `title-plate-delay-measured.md`
+implies ~55 units/s, and their reading of `splash-quad-timeline.txt` implies
+~150. A factor of **2.7**, both off the same game, both mine.
+
+**Neither reading is safe, and for the same reason.** Both convert an *alpha
+step* into a *clock rate*. That conversion needs the element's declared ramp
+length `T`, because `Δα per frame = 255 · (units per frame) / T` — two elements
+with different `T` give different `Δα` at identical clock rates. My own capture
+already shows this happening: on splash **B** the six quads step **34/label**,
+while on splash **A** the logo `Q0` goes `85 → 221` across one label pair, which
+is **68 or 136 per step** depending on how that pair is counted. Same game, same
+boot, 2× or 4× apart. So an alpha step is not a clock rate, and reading one as
+the other is how you get a factor of 2.7 out of one console.
+
+The fix is to measure on an element whose `T` is **declared and known**, and to
+quote a **frame count**, which has no phase.
+
+## The element
+
+`ptbtn00`, the `PRESS Ⓐ` plate, `GP_TITLE` build 2. Its declared ramp, from the
+Port's export of the same bundle: `t=214 → α=0x00`, `t=236 → α=0xff`.
+
+**`T = 22 units`, over which alpha travels the full 0 → 255.**
+
+It is the right element three times over: it is the one the play-test complains
+about; its ramp is a single declared segment with both endpoints pinned; and it
+sits on the title, which is a different screen from the splashes, so the answer
+is not a property of one bundle.
+
+## The prediction, stated before reading
+
+Counting **guest frames from the first frame in which `ptbtn00`'s quad is
+submitted with α > 0, to the first frame in which it is submitted with α = 255**:
+
+| reading | units/frame | predicted frames over the ramp | predicted Δα/frame |
+|---|---|---|---|
+| the corpus's ✅ law (`ui-keyframe-time-unit.md`) | **2** | **11** | ~23 |
+| the Port's inference from my splash timeline | **5** | **4.4** | ~58 |
+
+**I accept ±1 frame.** The two predictions are 6.6 frames apart, so the
+measurement separates them decisively or it fails cleanly.
+
+## The two controls this run carries
+
+1. **The empty-label control.** 14 frame labels in the splash capture carry
+   **zero** draws — not even the clear (`2, 5, 8, 12, 15, 54, 79, 83, 124, 148,
+   153, 194, 218, 222`). Whether such a label is a real guest frame changes every
+   frame count on this page. If the plate's alpha advances by the *same* step
+   across an empty label as across an adjacent occupied one, an empty label is
+   **not** an animation tick and must not be counted; if it advances by *twice*
+   the step, it is one and must be. The plate's ramp is monotone over ~11 frames,
+   so it is a good place to read this, and I do not have to decide it in advance.
+2. **The in-capture positive control.** The same frames carry the title's own
+   elements, whose declared ramps end at `t=118` and `t=160`. A clock rate read
+   off the plate must place those two anchors at the frame counts the same rate
+   predicts, or the rate is wrong. This is the Port's *other* H3 question — which
+   of `t=118` and `t=160` my "title settled" anchor is — and the same capture
+   answers it, so the two are not measured independently and must not be quoted
+   as if they were.
+
+## What this cannot answer
+
+* **Seconds.** This measures units per *guest frame*. Converting to units per
+  *second* still needs the guest's frame rate, which Canary does not preserve
+  (~28.1 fps presented). The port needs units/second; I can give units/frame
+  honestly and the frame rate is a separate, and separately suspect, number.
+* **Whether every screen shares one rate.** Two screens is not disc-wide.