# Referee report: marrakesh two-length run (hostile, read-only; nothing submitted to IBM)
Scratch: /private/tmp/claude-501/-Users-heuremen/80087010-0cb3-4ae5-9e13-362e6d5086ad/scratchpad/ref_len/ (mine.py, boot2.py, idle.py, sched.py, sched2.py)

## VERDICT: NARROW
The measured effect is real and survives every attack I could make. Three things must change: (a) drop the R3 "a includes 0" statement (it comes from a bug in analyze_len.py); (b) do not call N=4 "proportional-to-length" in the paper (fragile, and the pooled/N=8 data are below proportional); (c) do not say "not a fixed amount per readout" in general or imply length is the cause: kingston, with an even larger length ratio, shows almost no instruction dependence.

## 1. Recompute from raw
Hashes of code/plan/addendum verify. analyze_len.py reproduces results_marrakesh.text exactly. My independent code (pooled copies, own bootstrap, 5000 resamples) gives: N=4 ratio 0.576 [0.435, 0.731]; N=8 0.508 [0.367, 0.649]; medians -2.222/-1.281 and -2.263/-1.150. Known-good (N=8 L1 -2.263 [-3.185,-1.714] vs control -2.39 [-3.00,-1.72]) is met.
Robustness: copy 0 / copy 1 separately give ratio 0.600 / 0.586 (N=4) and 0.450 / 0.465 (N=8). Trimmed-mean ratios 0.51-0.53 (N=4), 0.47-0.48 (N=8). The raw mean ratio is 0.63 [0.45,1.03] (N=4), 0.49 [0.27,0.77] (N=8): heavy tails (per-qubit L1 kick 10th percentile about -13 deg, 90th about -0.2 deg), so only the median-type statements are stable. Wilcoxon on per-qubit k2 vs k1: p ~ 5e-12.
Pooling the two counts (same qubits, same job, so N=4 and N=8 are NOT independent confirmations): 0.510 [0.387, 0.619]; excludes both 1 and 0.702 (P(ratio >= 0.702) = 0.0014).
Caveat: per-qubit L1 and L2 kicks correlate only weakly (r = 0.19, 0.09). The ratio is a population-median statement, not a per-qubit law.

## 2. Compiled schedule (rebuilt with the committed build()/transpile settings; meta order matches job_ibm_marrakesh.json)
Target durations: measure 671 dt (2.684 us), measure_2 471 dt (1.884 us), identical on all 156 qubits; dt = 4 ns. Every emitter in every circuit runs one identical sequence, e.g. S-arm N=4 L2 M: delay9, measure_2 x4, delay680; D: delay9, delay471 x4, delay680. Untouched qubits get exactly 4 (or 8) delays of 471 (L2) or 671 (L1) dt, in M and D alike. Circuit duration is identical in M and D for each length (L2 N=4: 2573 dt = 9+4x471+680; L1 N=4: 3373; L2 N=8: 4457; L1 N=8: 6057). No scheduler padding after measure_2 and no extra delay: the D arm idle matches the M arm's nominal duration for each instruction. (Limit: this is the compiled nominal timing; the real pulse length is whatever IBM's calibration says.)

## 3. Idle arms across instructions
They differ in length by design, but k = wrap(phase_M - phase_D)/N is computed within a length, so detuning precession cancels. Check: D-arm phase advance from N=4 to N=8 is consistent with elapsed time (for 103 qubits with small advance, predicted-from-L1 vs observed-at-L2 median error 1.35 deg against a median advance of 14 deg). D-arm coherence at equal N is higher at L2 (shorter), as expected from T2, and M/D amplitude ratios are 0.99/0.98 at both lengths. Like for like, yes.

## 4. Selection and bootstrap
Alive filter (coherence > 5/sqrt(5000) = 0.071, on pooled copies) leaves of 117: N=4 L1 117 (D) / 116 (M), L2 117 / 115, both-instruction set 115; N=8 L1 113 / 110, L2 114 / 113, both-instruction set 110 (7 dropped; their kicks are scattered, not systematically large). Removing the filter: ratio 0.575 [0.441,0.733] (N=4), 0.503 [0.354,0.635] (N=8). Threshold 0.141: 0.540, 0.504. Not a selection artefact.
BUG FOUND in analyze_len.py (R3): `ab` is built from a fresh, independent bootstrap resample of median(a1) minus `bb` from a different resample, so a and b are decorrelated and the interval for a is far too wide. With shared resamples: N=4 a = +0.94 [-0.18, +2.84]; N=8 a = +1.47 [+0.32, +3.44] (excludes 0). b intervals are unaffected (b = -1.18 [-2.26,-0.63]; -1.39 [-2.46,-0.79]). So "a interval includes 0" is wrong at N=8, and is the same fact as the R2 N=8 "outside both". Also a > 0 means an extrapolated kick of opposite sign at zero length, which is physically odd: two points cannot support a split. Drop R3 from the paper, or report it only with the corrected bootstrap and no mechanism reading. (Fix is one line; it does not change any R1/R2 number, but note the committed code is what is hashed.)
R2 N=4 label: upper bound 0.731 barely contains 0.702 (P(ratio >= 0.702) = 0.038); N=8 and the pooled value exclude it. "PROPORTIONAL-TO-LENGTH" is a fragile label; the ratio is below proportional.

## 5. Kingston
Ratio 0.920 [0.774,1.169] at N=4 (excludes 0.633, contains 1); N=8 0.986 [0.786,1.285], flagged only because the L1 copy gap is [+0.003, +0.091] deg against a kick of -2.75 deg (the plan notes this rule has a false-fire floor). The point value and interval exclude proportionality either way. So kingston is not really undecided: it shows little or no instruction dependence, with a LARGER length ratio (0.633) than marrakesh (0.702). Hence it does not conflict with the marrakesh measurement (different processor, different instruction calibrations; kingston states equal errors and similar thresholds for the two instructions, marrakesh does not), but it does conflict with any reading that length is what changes the kick. In contrast the measured qubit's own loss (R4) scales with instruction on both processors (kingston 0.0148/0.0238 = 0.62 at N=4; marrakesh 0.0158/0.0243 = 0.65). Note ibm_fez was fired but its raw data was never fetched (no raw_ibm_fez.npz), so only two of three processors are in hand.

## 6. Wording
Problems with the proposed text: "the kick is not a fixed amount per readout on that processor" is true as measured but invites the length reading that kingston argues against; N=4 and N=8 are quoted as two results when they are one data set at two counts; the threshold figures (-9.07e7 vs -2.04e7) are chip-wide medians over all 156 qubits in arbitrary units (the 39 measured: -8.5e7 vs -1.7e7), a record entry, not a demonstrated amplitude difference; and the threshold ratio (0.2) is far from the length ratio (0.7), so the units are not simply signal times length.

Proposed wording (use exactly):
"On ibm_marrakesh the kick depends on which readout instruction is used: the shorter instruction (measure_2, 1.884 against 2.684 us) gives 0.58 [0.43, 0.73] and 0.51 [0.36, 0.65] of the longer one's kick at 4 and 8 readouts (0.51 [0.39, 0.62] pooled over the two counts, which share the same qubits and job). On ibm_kingston, where the two instructions differ more in length (1.380 against 2.180 us), the same test gave 0.92 [0.77, 1.17] at 4 readouts, so length alone does not set the kick. The two marrakesh instructions also differ in IBM's calibration record (discriminator threshold, stated readout error), so length is not the only difference."
(Add for kingston N=8: ratio 0.99 [0.79, 1.29], flagged by the copy-gap rule; fez not read.)
Do not print: the R3 split, the PROPORTIONAL-TO-LENGTH label, or any mechanism.