Quantum error mitigation needs a controlled comparison, not an accuracy promise.

Error suppression changes execution to reduce exposure to selected noise; dynamical decoupling is one example. Pauli twirling instead restructures an arbitrary noise channel into a Pauli channel and can mitigate coherent-error buildup, while methods such as measurement mitigation, zero-noise extrapolation, and probabilistic error cancellation estimate or cancel selected effects through additional circuits, models, or extrapolation. Fault-tolerant error correction encodes logical information so errors can be detected and corrected during computation.

Calling every technique correction inflates the claim. A mitigated expectation value remains an estimator produced under a method, backend, calibration, sampling, and model boundary. It should be compared, not declared correct by configuration alone.

Mitigation is meaningful only relative to a declared quantity: an expectation value, distribution feature, energy estimate, symmetry, or other observable. Define the circuit, mapping, parameter set, comparison baseline, requested precision, uncertainty treatment, and acceptable total overhead before running variants.

Where a classically tractable instance exists, use it as a calibration or validation reference without assuming the same behavior will hold at larger scale. Where the answer is not classically known, use internal consistency, symmetries, cross-method agreement, held-out circuits, and stability checks as evidence—not as proof.

The raw hardware estimate is the reference needed to understand what the mitigation changed. Preserve its exact circuit snapshot, observable, backend, calibration time, shots, precision, result, variance or interval, and failure state.

Run related variants close enough in time to reduce avoidable drift where the provider's execution model permits it. IBM's execution-mode guidance, for example, describes batch as a useful way to schedule independent mitigation comparisons together. That is provider-specific context, not a universal scheduling rule.

Measurement mitigation addresses readout effects; suppression methods can reduce selected coherent or idle-time effects; zero-noise extrapolation estimates a zero-noise limit from deliberately varied noise; probabilistic error cancellation uses a learned noise representation and can incur substantial sampling overhead. These techniques have different assumptions and output semantics.

A higher resilience or mitigation setting is not automatically better. It can increase shots, QPU consumption, runtime, variance, and sensitivity to a stale noise model. Document why each enabled method fits the circuit and observable.

Mitigation may trade bias for variance or require many more circuit executions. PEC sampling overhead can grow rapidly with circuit noise, while ZNE requires multiple noise-scaled evaluations and an extrapolation model. The workflow must report total shots, circuit variants, QPU consumption, elapsed time, failed jobs, and the final uncertainty treatment.

If mitigation improves a point estimate but makes uncertainty or cost unacceptable, the experiment may not have passed. The decision rule should evaluate result quality and total evidence cost together.

A result moving toward a desired value can be reassuring and still be misleading. Compare multiple settings, inspect monotonicity or fit quality where applicable, repeat across relevant calibration windows, and test whether conclusions survive reasonable changes in extrapolator, noise factors, mapping, or shot allocation.

Record negative evidence: failed extrapolation, excessive overhead, method disagreement, unstable fit, or a mitigated result that changes the decision unpredictably. These outcomes prevent a polished final plot from hiding the method's operating boundary.

A QFlow mitigation packet should link the workflow and source snapshot, provider route, mapped circuit, raw run, each mitigation variant, settings, calibration and noise-learning context, shots, results, uncertainty, overhead, fit diagnostics, failures, reviewer note, and final decision. Provider credentials and private billing state remain excluded.

The final claim should be narrow: which observable changed, under which method and conditions, with what uncertainty and overhead, and whether that change crossed the pre-registered acceptance threshold. It should never imply general hardware accuracy or fault tolerance.