Short answer: freeze the claim and workload; identify the provider, backend and job; preserve compilation and transpilation; record shots and calibration context; obtain raw counts and post-processing; compare with simulators and strong classical baselines; then quantify uncertainty and state what the evidence does not establish.
Independence describes the relationship and the method, not a guarantee of correctness. The auditor should disclose who commissioned the work, what evidence was supplied, what was obtained independently, which provider systems remain trusted and whether any execution was newly performed.
Freeze identity before interpretation
Start with the manuscript, claim, code commit, circuit or optimization payload, input data and expected output. Hashes establish byte identity, not truth, but they prevent a later result from being silently attributed to different materials.
The execution record should name the cloud provider, account or project boundary where disclosure is permitted, backend, job identifier, submission and execution times, device properties, circuit count, width and depth, shots, compiler or transpiler version, optimization level, layout, random seeds and mitigation settings.
Preserve the raw result and the transformation chain
Published probabilities or summary metrics should be traceable to raw counts or samples. The audit should identify filtering, normalization, error mitigation, discarded jobs, aggregation and plotting code. Recomputing the figure from the raw output is a distinct check from rerunning the QPU.
For annealing, D-Wave's operation-timing documentation separates programming, sampling, readout and thermalization components. Those distinctions matter when a claim is about execution time or billed QPU access. For gate-model systems, native gates, topology and transpilation can change the physical workload.
Treat calibration and noise as context, not decoration
IBM's calibration documentation explains that calibrations may run throughout the day. IBM's job-monitoring guide describes access to backend calibration data associated with job timing. An audit should record what calibration evidence is available and avoid implying that a later device state was the state used for the original result.
Noise mitigation can improve an estimate, but it also adds assumptions and parameters. Report unmitigated and mitigated results where useful, including any shot multiplier and the exact method.
Use classical controls and simulator comparisons
For tractable instances, compare the QPU output with an exact simulator or analytically known answer. For optimization or machine-learning claims, compare against credible classical methods under equivalent data splits, budgets and metrics. Weak baselines make a quantum result easier to market and harder to interpret.
The result should distinguish: the circuit executed; the output matched a simulator within a declared tolerance; the output supported a scientific claim; and the quantum approach outperformed a classical alternative. Those are four different conclusions.
Quantify sampling and repeatability limits
Finite shots produce sampling uncertainty. Device drift and queue timing can add between-run variation. A defensible plan declares repetitions, confidence intervals or other comparison rules before inspecting the preferred result. Selective reruns and omitted failed jobs should be visible.
NIST researchers note that validating quantum computations from output samples is challenging, and NIST's quantum characterization work treats device behaviour as a measurement problem. The audit conclusion should therefore be bounded to the evidence actually obtained.
Reproducibility does not mean permanent bit-for-bit identity
A physical QPU can change through calibration, maintenance and software updates. Reproducibility means another investigator can identify the original conditions, execute a declared comparison and understand whether differences are expected. It does not require the device to remain frozen forever.
A 2026 preprint, Works on My QPU, reports a manual review of 127 papers and highlights recurring gaps in code, environment, hardware and executability. It is a preprint, not a final standard, but its categories are useful audit prompts.
What the report should say
- Which exact claim was tested and which was not.
- Which supplied and independently obtained artifacts were used.
- Whether QPU execution was observed, newly performed or only proposed.
- Which provider and backend facts remain trusted dependencies.
- What classical simulation and baseline comparisons showed.
- What uncertainty, drift and reproducibility limits remain.
- Whether the evidence supports, qualifies, contradicts or cannot decide the claim.
Payment funds this scrutiny; it never purchases a favourable result. Review when hardware is actually required and how audit and compute costs are separated.