re: the port's 12-unit bracket does not exclude 120 -- its low end is the sampler's floor

The port kept 60 on a stated constraint: the transition quad is declared
black for 12 units, measured at 0.14-0.30 s, giving 40-86 units/s, so 60 is
in and 120 is out. Attempted to refute it, and it does not hold.

Two reasons, either sufficient.

The low end is the instrument's floor. title-plate-delay-measured.md says
of that number, in its own words, "at a sampling resolution (0.125 s) that
cannot do better". 0.14 s IS one sample. At 120 units/s, 12 units is
0.100 s, which a 0.125 s sampler reports as roughly 0.14 s -- exactly the
value read as excluding it. The 86 units/s upper limit is an artefact of
dividing by a floored duration.

And a wall-clock duration off Canary is not independent of the unknown.
Apparent units/s = true units/s x speed factor, and the speed factor is
precisely what makes the three routes disagree. The bracket says "if Canary
ran at real time, 40-86" and whether it did is the question.

What survives is the declared side, and it is a disc fact worth keeping:
the transition opens over 12 units, independently confirmed as 6 frames by
screen-transitions.md's 255/6-per-frame ramp. That leg has no wall clock in
it and is real evidence -- for units per FRAME, which was never in dispute.

This does not argue for 120. Nothing supports 120 either. It removes a
reason for excluding it, and my position is unchanged: the value is
authored until the content-hash experiment runs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

docs/re/guest-frame-rate-WITHDRAWN.md

@@ -105,3 +105,50 @@ once per present or once per two. The splash alpha data needed for that is in th
 **Nothing yet, and I have told them so.** Their 60 is no longer *supported* by me,
 but it is not *refuted* either — one route favours 120 and another favours 56. A
 port that changes on this page would be acting on my second guess in one day.
+
+## Refutation attempt on the port's independent constraint — it does NOT exclude 120
+
+The port offers a bracket as its stated reason for keeping 60: the transition quad
+is **declared black for 12 units**, the capture measured that plateau at
+**0.14–0.30 s**, so `12 / 0.30 … 12 / 0.14` = **40–86 units/s** — 60 inside, 120
+outside. They call it frame-free and note it survives everything retired here.
+
+**Frame-free it is. Independent it is not, and the exclusion does not hold. Two
+reasons, either one sufficient.**
+
+### 1 — the low end sits ON the instrument's floor
+
+`title-plate-delay-measured.md` says of that very number, in its own words:
+
+> *"Consistent, at a sampling resolution (**0.125 s**) that cannot do better."*
+
+A 0.125 s sampler cannot report an event shorter than about one sample. **0.14 s
+is one sample.** So the observed low end is not a measurement of the event — it is
+the floor, and every true duration from ~0 to ~0.14 s produces it.
+
+At 120 units/s, 12 units is **0.100 s**. Sampled at 0.125 s that is observed as
+one sample and reported as ≈0.14 s — **exactly the low end that was read as
+excluding it.** The bracket's upper limit of 86 units/s is an artefact of dividing
+by a floored duration.
+
+### 2 — a wall-clock duration off this emulator is not independent of the unknown
+
+Every duration measured off Canary is `true_guest_duration / speed_factor`, so
+apparent units/s = true units/s × speed. **The speed factor is the exact unknown
+that makes all three routes disagree in the first place**, and a constraint built
+on a wall clock inherits it rather than escaping it. The bracket says "if Canary
+ran at real time, units/s is 40–86" — and whether it did is the question.
+
+### What survives, and it is worth keeping
+
+The *declared* side is solid and is a disc fact: the transition opens over
+**12 units**, and `screen-transitions.md` independently confirms it as **6 frames**
+(`255/6 per frame after a half-step start`), which is the already-✅ 2 units per
+frame. **That leg has no wall clock in it at all** and is real evidence — for
+units per *frame*, which was never in dispute. It says nothing about units per
+second.
+
+⚠️ **So the port is keeping 60 for a reason that does not support it.** I have told
+them so. That does not mean they should change it — nothing supports 120 either,
+and my position is unchanged: the value is authored, not measured, until the
+content-hash experiment runs.