# πŸ”΄ The main menu does NOT self-return to the title β€” and three "latencies" were my own pipeline **Status:** one βœ… **measured** negative, one 🟑 ordering-only result, and one πŸ”΄ **instrument defect that voids three numbers I took the same day.** Taken 2026-08-29. ## βœ… Refuted: "an ~8–10 s idle returns to the title" does not apply to the main menu HANDOFF's residue table downgraded *β’· leaves the main menu* to **authored**, on the grounds that "an ~8–10 s idle also returns to the title, and nobody has separated the two". That reason is now gone. **Measured:** the main menu was held with **no input at all** and classified every ~1.2 s by [`screen_match.py`](../../tools/re-capture/screen_match.py): | phase | duration untouched | screens seen | |---|---|---| | period capture | 24 s | menu only | | idle probe | **60 s** (49 samples) | **menu only** | Correlation against the committed main-menu capture never moved outside **0.9245 – 0.9249** across the whole idle window β€” not a drift, not a fade, a screen sitting still. Conservatively that is **β‰₯ 60 s of continuous idle with no self-return**, against a claim of 8–10 s. βœ… **And the 8–10 s idle is real β€” it belongs to the TITLE.** Immediately after this run, a probe that expected to find the title still on screen found it had left on its own into the attract movie. So the corpus's idle timer is a property of the **title screen** (title β†’ `ADV.wmv` β†’ title), and the residue table attached it to the wrong screen. **What this gives the port:** the idle alternative that made β’· unprovable is refuted *on the screen in question*. β’· is no longer competing with a timer there. ## 🟑 β’· on the main menu: the ordering survives, the timing does not β’· was **delivered** β€” Canary's own log records `[file-pad] keystroke vk=5801 down` / `up` and `XamInputGetKeystrokeEx -> user=0 vk=5801`, so this is not a dropped press. In both runs the menu was followed by the title, and in both runs **β’· was the only input** in a window of β‰₯ 100 s either side. 🟑 **But it is still two observations with a confound I cannot yet exclude**, and the reason is the next section: the "latency" I measured is worthless, so I cannot say the return followed β’· *promptly*. What stands is ordering plus the absence of any other cause: * no input for β‰₯ 100 s before β†’ no transition; * β’· delivered β†’ transition to the title. **Classification: measured ordering, unmeasured timing.** The port should keep β’·β†’title, and it is now better supported than "authored" β€” but it is not yet a timed measurement. ## πŸ”΄ The defect: an oracle that cost 1503 ms per frame produced three fake latencies `screen_match.classify_array` does a Β±8 px ZNCC search over a 675Γ—1279 surface against two references. **Measured: 1503 ms per frame.** A probe calling it on every frame of an 8 fps `x11grab` stream therefore drained the pipe at **0.64 frames/s** β€” verified from the probe's own trace, 107 samples over 166 s. The pipe backed up at ~7.4 fps, so every frame classified was **stale, and increasingly so**. That is not a subtle bias; it manufactured three numbers: | reported | actually | |---|---| | plate appears 24.66 s after the title art | unknown | | β’· β†’ title in 15.58 s (run 1) | unknown | | β’· β†’ title in 25.60 s (run 2) | unknown | | β’Ά β†’ menu in 20.26 s | unknown | πŸ”΄ **All four are withdrawn.** The tell was that they are all ~20–25 s: a screen transition, a button press and a plate fade do not share a duration, but a backlog does. The two β’· figures *growing* 15.6 β†’ 25.6 s across a longer run is the backlog accumulating, and it is the signature to remember. ⚠️ **What a backlog does and does not destroy.** It delays every frame by the same growing amount, so it **preserves ordering** and destroys **durations**. That is why the ordering results above survive and every duration here does not. βœ… **Fixed and re-controlled.** `screen_match` now has a `fast=True` path (4Γ— decimation, Β±2 decimated px) at **38–75 ms**, a 20–60Γ— reduction, and the control was re-run on **both** paths: 8/8 each, with the fast path agreeing with the exact path to **Β±0.005** on every score. βœ… **The ring measurements are NOT affected**, and this was checked rather than assumed: `ring_period.py` does a greyscale conversion and a crop per frame, and achieved **15.03 fps against a requested 15** β€” it kept up exactly, so its timestamps carry no backlog. Its period also has an internal check a drifting clock cannot pass: eight *evenly spaced* autocorrelation peaks ([`focus-ring-spin-measured.md`](focus-ring-spin-measured.md)). ## 🟑 The `PRESS β’Ά` plate: sequence answered, duration not The port asked whether the boot title is build 4 alone, build 4 with the plate composited from the start, or build 4 **then** the plate after a delay. βœ… **It is the third.** On the boot title the green-β’Ά glyph count went **154 β†’ 781** with the title art already matching at 0.946. The 154 is the decisive number: the committed no-plate capture `live-title-build4-no-plate.png` reads **159** with the same counter, and plate titles read 753 / 977 / 1493. So the title genuinely presents **without** the plate first, and the plate arrives afterwards. πŸ”΄ **How long afterwards is NOT measured** β€” that figure came from the backlogged probe and is withdrawn with the rest. The port needs one more run with the fast path to get it. ## Instrument controls, now committed The negative controls for `screen_match` are **movie frames**, because that is the class the oracle exists to reject β€” a statistics-based oracle (green/white/mean) called a frame of `ADV.wmv` containing a bright green laser `title`, and a probe built on it tapped β’Ά into the movie and then waited 120 s for a menu that was never coming. An earlier version of the control list pointed at two **scratch** grabs, and a later run of the same probe overwrote one of them β€” turning a negative control into a title frame and failing the control for the wrong reason. They are now committed fixtures under [`captures/instrument-controls/`](captures/instrument-controls/).