# Referee report, late results (22 Oct 2026). Read-only; nothing submitted to IBM; no token used or printed.
Scripts: a.py, c.py, e.py, f.py in this directory (own venv v/ with qiskit 2.6, qiskit-aer 0.18).

## VERDICTS
- A-R4 NARROW
- A-R1 NARROW
- B-ratio DROP (as a finding; keep only as "not decided")
- B-measured-loss NARROW

## A. Three-box, ibm_marrakesh
Recompute: raw npz reproduces R4 (hardware minus model: +0.0763, +0.0568, +0.0451; hardware means +0.0812/+0.0617/+0.0485, SE ~0.010, model +0.0049/+0.0049/+0.0034) and R1 (P hw -0.589/-0.588/-0.600 vs model -0.759/-0.759/-0.761; differences +0.170/+0.171/+0.161) to the digit.

Model fairness. NoiseModel.from_backend builds the readout error from the target's single `measure` error. For qubit 8 (FakeMarrakesh, same construction) the readout matrix is SYMMETRIC [[0.99365,0.00635],[0.00635,0.99365]]. It does NOT use prob_meas0_prep1 / prob_meas1_prep0. So the asymmetry is not in the model, and the question is fair to ask.
IBM's stated figures for probe qubit 8 at firing: prob_meas0_prep1 = 0.006592, prob_meas1_prep0 = 0.000244 (readout_error 0.00342). Applied to a post-selected probe-X read of a probe at <X>=0: offset = b - a = +0.0063, gain 1 - a - b = 0.9932. That is 8-14% of the observed offset (0.045-0.076). Adding it to the model gives difference +0.070, +0.051, +0.039 (each still above zero: about 6.7, 5.0, 3.8 SE).
Post-selection on s0=s1=0 with s0/s1 readout error (q6 b=0.0037, q7 b=0.0093): in the unused box the control never fires on the support, so the probe is |+> whatever the system state. Misassigned system shots therefore carry the same probe distribution; they cannot create an offset. Hard bound even if they carried <X>=1: contamination <= ~1.3% = 0.013. Not the source.
What the offset is not: readout asymmetry, post-selection leakage. What it may be (untested): coherent/ZZ/crosstalk and leakage that from_backend omits (the properties file lists zz terms; the model has none); calibration snapshot 11:46 EDT, fired 13:17 EDT, so staleness is not the issue. Cross-run support: +0.062 (fez 11 Oct), +0.060 (24 Sep), same sign in all three variants here.
Per-eps: hardware unused-box mean sits 0.03-0.10 at every eps; no eps dependence resolved.

R1. The P gap (+0.16/+0.17) is real against this model, but the positive boxes also fall short of the same model (V11 0.78/0.80 vs 0.90; V10 0.84/0.84 vs 0.90; VA 0.80 and 0.72 vs 0.90). R2 (G) is CONSISTENT in all three variants. So R1 is a model-versus-chip gain gap shared by all boxes, only somewhat larger on the negative box (~0.17 against 0.06-0.18). "Negative box less negative than model" is true but is not specific to the sign; the addendum's SIGN on one chip (-0.094 [-0.188,-0.001], null-world false SIGN rate noted by the addendum itself) is not a finding.

Wording to keep:
- A-R4: "On ibm_marrakesh the post-selected probe in the unused box reads <Xp> = +0.081, +0.062, +0.049 (+-0.010) in three variants; the standard qiskit-aer noise model built from IBM's calibration at firing gives +0.005. IBM's stated readout asymmetry of the probe qubit (prob_meas0_prep1 0.0066, prob_meas1_prep0 0.0002) would add +0.006; the remaining +0.04 to +0.07 is not produced by that model or by that asymmetry. Same sign and size on fez 11 Oct (+0.062) and 24 Sep (+0.060)." Do NOT say "not produced by IBM's stated calibration" (the stated calibration has no coherent/crosstalk terms; the claim is about a construction from it).
- A-R1: "The negative box reads P = -0.59 to -0.60 against the model's -0.76; the positive boxes also read 0.06 to 0.18 below the model; the difference between the two is not resolved (G consistent with 0 in all variants)."
Candidate vendor-deviation row: ibm_marrakesh q6-8, 22 Oct 2026: probe <Xp> on kept shots with ideal 0 = +0.049..+0.081 (+-0.010) vs qiskit-aer from_backend model +0.003..+0.005; IBM's stated asymmetry for q8 accounts for +0.006.

## B. Two-length, ibm_kingston
Recompute: analyze_len.py on raw npz reproduces every line of results_kingston.text. Copy-gap label bug confirmed: N=8 L1 gap [+0.003,+0.091] -> R1 N=8 L1 and R2 N=8 are CANNOT_TELL and the known-good (BELOW and overlapping -2.86 [-3.55,-2.09]) is missed by label although the kick (-2.755 [-3.623,-2.067]) overlaps the control. By the plan R2-R4 on kingston are "not decided". That rule stands unless the author drops it, and nothing here argues for relaxing it after the result.

B-ratio: DROP. N=4 0.92 [0.77,1.17] contains 1 and excludes 0.633, but the known-good gate marks the run not decided, and N=8 (0.99 [0.79,1.29], excludes 0.633 too) is CANNOT_TELL by label. N=8 is CANNOT_TELL by label. Also addendum 1: measure and measure_2 differ in discriminator and stated error (kingston measure 0.0104 vs measure_2 0.0120 median over the 39), so even PER-READOUT is "instruction-independent", not "length-independent". If quoted at all: "On kingston, N=4 kick ratio short/long = 0.92 [0.77,1.17]; N=8 not decided (copy gap); marrakesh and fez pending." Not a finding.

B-measured-loss. Recomputed: idle minus readout P(1), N=8: L1 +0.0459 [0.036,0.063], L2 +0.0270 [0.019,0.041]; N=4: +0.0238, +0.0148. Paired bootstrap L1 minus L2: N=8 +0.0166 [+0.0081,+0.0238]; N=4 +0.0069 [+0.0026,+0.0098]. So "more with the long readout" holds as a paired difference. Ratio L2/L1 0.59 [0.46,0.79] (N=8), 0.62 [0.50,0.94] (N=4): the excess scales with duration (L2/L1 = 0.633).
Like for like? Not confirmable from our record. Nominal: idle delays are exactly L_dt (2180 / 1380 ns) and the saved properties give measure 2180 ns and measure_2 1380 ns for all 39 measured qubits, so the compiled schedule is nominally equal. The compiled circuits were not saved and the FakeKingston target in the library has stale lengths (2.28/1.76 us), so I could not recompute the schedule; real control-system dead time or latency between readouts is invisible to estimate_duration and to this data. If the readout step took longer than stated, plain T1 would need extra time of (excess per step x T1 = 0.0057 x 263 us) = 1.4 us at L1 and 0.9-1.0 us at L2, i.e. 64% and 71% of the nominal lengths: a large unexplained hidden time, so a timing error alone is a stretch, but physical readout-induced decay (a 1.6-1.7x faster |1> decay while the readout is on) is equally good and indistinguishable here.
Double count: our quantity is readout minus idle, so T1 over the stated length is already subtracted; but IBM's own per-readout asymmetry prob_meas0_prep1 - prob_meas1_prep0 (the stated figure for loss of |1> during one readout) has median 0.0066 over the 39 qubits (b 0.0137, a 0.0068), and our excess per step is 0.0057 (L1, N=8; 0.0059 at N=4). That is ~85-90% of IBM's stated figure, so the measured-qubit excess is NOT beyond IBM's stated calibration for `measure`. For measure_2 IBM states no asymmetry (only gate_error 0.0120 median vs 0.0104); our L2 excess 0.0034-0.0037 per step is below the L1 stated figure. Per-qubit correlation of excess with (b-a) is weak (r 0.11-0.27) and with 1/T1 -0.15 (n=39), so neither explains qubit-to-qubit variation; not conclusive.

Wording to keep (NARROW):
"On ibm_kingston the measured qubit prepared in 1 ends at P(1) lower after N readouts than after N idles of the stated length: N=8 by 0.046 [0.036,0.063] with the 2.18 us readout and 0.027 [0.019,0.041] with the 1.38 us readout (difference 0.017 [0.008,0.024]); per readout 0.0057 and 0.0034. IBM's stated single-readout asymmetry prob_meas0_prep1 - prob_meas1_prep0 is 0.0066 (median, 39 qubits), the same order. Whether the readout steps take the stated time is not verified. One chip; the plan's copy-gap rule marks this run not decided; marrakesh and fez pending."
Do not write "beyond what IBM states" or "plain loss at equal elapsed time".
Candidate vendor-deviation row: none survives for B. (For the measured-qubit figure the row would read: kingston 39 measured qubits, per-readout loss of |1> beyond equal idle 0.0057 (2.18 us) / 0.0034 (1.38 us) vs IBM-stated prob_meas0_prep1-prob_meas1_prep0 0.0066 -> within the stated figure, not a deviation.)