More correction is not automatically a better estimate.
A quantum error-mitigation method can move an estimate closer to its reference and still leave you with too much sampling variance. It can produce a smoother-looking result while preserving the wrong bias. It can also consume pilot shots, calibration work, repeated circuits, and noise-factor measurements that a baseline method did not receive.
If those costs sit outside the comparison, the mitigated estimator is not winning. It is playing with a larger budget.
The operating rule: mitigation has to earn its overhead under the same total resource envelope. Compare the mitigated and baseline estimators for the same observable, circuit, hardware context, reference, and error metric. Count squared bias and variance together. If the measured difference does not survive uncertainty, call it indistinguishable—not a win.
That turns error mitigation from a feature checklist into a break-even decision.
The statistical test is smaller than the operating decision
For an estimator (j), mean-squared error decomposes into two parts:
MSE_j = bias_j² + variance_j
This is the statistical core used in Section 3.1, Equation 4 of a recent preprint by Sumit Chongder. Chongder's August 2026 arXiv v1 preprint studies error mitigation and finite-shot sampling under constrained execution budgets. It is one primary source, not a peer-reviewed or independently replicated field verdict.
The direct decision rule is:
MSE_mitigated < MSE_baseline
That comparison only means something when both sides operate inside the same declared resource budget and matched context.
The break-even equality is:
bias_mitigated² + variance_mitigated
=
bias_baseline² + variance_baseline
Rearrange it and the tradeoff becomes visible:
bias_baseline² - bias_mitigated²
=
variance_mitigated - variance_baseline
Mitigation helps when its reduction in squared bias is greater than the excess variance it introduces. It hurts when the variance penalty is greater. The direct MSE comparison remains the better general rule because a method may change both bias and variance in either direction.
Execution overhead does not become a third term in the MSE equation. It belongs in the constraint around the experiment.
The accounting boundary is practical. If zero-noise extrapolation needs measurements at several noise factors, those measurements consume the budget. If an allocation policy needs pilot shots, those shots count too. Calibration or characterization work required by the method should either be charged to the envelope or disclosed as an excluded cost. Classical compute, queue time, wall-clock latency, and dollars may matter to the adoption decision, but they cannot simply be added to a statistical MSE value.
The preprint separately uses C_QPU = N_shots × N_circuits as a sampling-cost proxy. That is useful, but it is not a complete economic model.
A bias improvement is not automatically an estimator improvement
One result in the preprint shows why the distinction matters.
In a reported simulation of a bias-sensitive parity-type observable, Section 5.4, Table 5 and Figure 5 report absolute bias of (5.07\times10^{-3}) for the raw estimate and (1.70\times10^{-2}) after zero-noise extrapolation. Readout mitigation plus zero-noise extrapolation is reported at (1.46\times10^{-2}).
That supports a narrow statement: in this simulated configuration, zero-noise extrapolation increased absolute bias relative to the raw estimator.
It does not support “ZNE is harmful” as a general claim. It does not establish that every mitigated total-error estimate was worse. And it is not a physical-device result.
The reverse mistake is just as common. A method that lowers bias has not necessarily produced a better estimate if its variance increases enough to erase the gain. Looking at only one side of the decomposition can make either the raw or mitigated result appear stronger than it is.
The practical question is not “did the correction move the point estimate?”
It is “did the estimator's total measured error fall under a fair resource constraint?”
Smarter shot allocation still has to beat the baseline
The paper's fixed-budget allocation example is even more useful for operators because it tests an idea that sounds right before measurement: allocate shots according to estimated variance instead of dividing them uniformly.
In Section 5.5, Table 6 and Figure 7, the author compares uniform and adaptive allocation across budgets of 900, 1,500, 3,000, 6,000, 12,000, and 21,000 shots. This six-budget comparison is a hardware-anchored simulation using a calibration-derived noise model. It is not a set of six physical-device executions.
The reported adaptive-to-uniform MSE ratios are 5.96, 0.998, 1.47, 0.988, 2.08, and 2.43. The author reports a mean ratio of 2.16.
Adaptive allocation had the lower reported MSE point estimate at two of the six budgets. But 0.998 and 0.988 are close to equality, and the displayed comparison does not establish that those small differences survive an uncertainty test. I would not call those decisive wins.
The result exposes a narrower failure mode: optimizing shot allocation against an estimated variance can miss the objective when bias dominates total error. “Adaptive” describes a mechanism. It does not certify the resulting estimator.
The paper also reports a distinct physical-device allocation record with 4,500 shots per arm. Uniform allocation split the budget evenly across three noise factors; the adaptive arm charged a 100-shot-per-factor pilot before distributing the remainder unevenly. That hardware record explains the mechanism, but it cannot be spliced into the six-budget simulation as though they were one experiment.
The same-budget mitigation break-even test
The paper supplies the fixed-budget MSE framing. Here is the operator checklist I would use to turn that framing into a reusable evaluation.
Before comparing two estimators, lock these invariants:
- Target observable. Both methods must estimate the same quantity.
- Circuit and workload. Keep the logical circuit and workload definition fixed.
- Reference. Use the same defensible reference value and disclose its uncertainty.
- Metric. Compare the same error measure, with MSE as the primary statistical decision metric here.
- Hardware context. Use the same backend or an explicitly matched hardware context.
- Calibration window. Keep measurements inside one snapshot or a bounded, disclosed window.
- Charged resource envelope. Count pilot, allocation, noise-factor, repeated-circuit, and final-estimation shots required by each arm.
- Uncertainty procedure. Predeclare enough replication, intervals, or resampling to distinguish a measured difference from finite-shot fluctuation.
Then classify the result using the predeclared replication, interval, or resampling procedure:
- Helped: mitigated MSE is lower and the advantage survives the uncertainty procedure.
- Indistinguishable within uncertainty: the comparison does not resolve a reliable difference.
- Hurt: mitigated MSE is higher and the disadvantage survives the uncertainty procedure.
Do not quietly turn “indistinguishable” into “promising.” That is how an evaluation becomes a marketing layer.
A comparison is not same-budget if mitigation receives extra shots, its pilot work disappears from the accounting, the observable or circuit changes, or the two methods cross an unlabeled backend or calibration boundary.
The reference value is a real limitation
Bias and MSE require a reference. That sounds obvious until the useful workload is too large for an exact answer.
In Chongder's preprint, the MSE analysis uses an exact noiseless statevector value for the same circuit and observable. An operator evaluating a harder workload may not have that luxury. A high-quality classical reference, a smaller verified instance, a cross-method consensus estimate, or another proxy may be useful—but each changes what can honestly be claimed.
If the reference is uncertain, carry that uncertainty into the evaluation. If no defensible reference exists, do not report “true MSE” as though it were directly observed. Call it a reference-estimation problem and separate proxy performance from known estimation error.
This is one reason there is no universal break-even shot count. The crossing depends on the circuit, observable, device, calibration state, mitigation design, allocation policy, and reference strategy. A threshold measured for one IBM backend and selected circuit family is not a readiness score for another workload.
Use three evidence labels and do not blur them
The preprint organizes evidence across ideal simulation, calibration-derived noisy simulation, and physical-device execution. Those layers answer different questions.
- Ideal simulation can isolate finite-shot behavior against a known noiseless value.
- Hardware-anchored simulation can test a policy under a noise model derived from calibration data.
- Physical-device execution captures the backend and calibration context actually encountered during the run.
A calibrated noise model is more grounded than an arbitrary toy model. It is still a simulation.
This labeling discipline prevents the most tempting inaccurate summary of the paper: that adaptive allocation lost at most budgets “on hardware.” Table 6 does not show that. The six-budget result is hardware-anchored simulation. The paper does contain physical-device work on ibm_marrakesh, but one evidence layer cannot silently inherit another layer's label.
The source itself is appropriately bounded in its limitations section: one backend, one calibration snapshot, a short hardware campaign, selected circuit families, and constrained execution time. Those are not reasons to dismiss the work. They are the conditions under which its evidence is useful.
Make mitigation prove the estimate, not decorate it
Quantum error mitigation should not be treated as an automatic upgrade. Neither should the absence of mitigation be treated as rigor.
The operator's job is to design a comparison that can fail either way.
Lock the resource envelope, keep the context matched, and charge the method for the hardware work it requires. Then count squared bias and variance together and report helped, indistinguishable, or hurt only when the uncertainty procedure supports that classification.
That is more demanding—and more useful—than showing a corrected line next to a raw one.
A mitigation method has earned adoption when the resulting estimator is better for this observable, on this workload, under this budget—not when the method merely sounds more sophisticated.
Source
This article uses one preprint as a bounded worked example. The abstract, HTML, and PDF are different representations of that same primary source, not independent corroboration. No peer-reviewed acceptance or independent replication was verified for this article.