Short answer: use quantum hardware when the claim is explicitly about what a named physical backend did, about hardware-dependent noise or calibration, or about a performance comparison that cannot be evaluated without genuine QPU samples. Use formal analysis or classical simulation when the question concerns an algorithm, circuit identity, small-instance correctness or an idealized model.
Haivian sells research audits, including suitable quantum-computing claims. The audit method is chosen after fit and scope are established. Provider-backed QPU execution is not included automatically in the US$1,499 base audit. If required, it is a separately approved compute component subject to access, provider availability, an estimate and a customer cost ceiling.
Four different evidence questions
Formal proof asks whether a stated conclusion follows from stated assumptions. It may use mathematics or a proof assistant. It does not show that physical hardware implemented the model faithfully.
Classical simulation asks what an ideal or noisy quantum model predicts for a tractable workload. Simulation is often the best first check because it supports exact or high-precision comparisons on small cases. It does not become a hardware observation merely because the simulated circuit targets a QPU.
Empirical QPU execution asks what happened on a named provider, backend and job under recorded compilation and calibration conditions. That evidence is statistical, time-dependent and hardware-specific.
Comparative performance asks whether the quantum approach adds value against a strong classical comparator under a fair evaluation contract. Running a circuit is not, by itself, evidence of quantum advantage.
Hardware is needed when the claim makes hardware load-bearing
- The paper reports counts, expectation values or success rates from a named QPU.
- The claim concerns drift, calibration, crosstalk, readout error or mitigation on physical hardware.
- The proposed result depends on a provider-specific native gate set, topology or runtime behaviour.
- A fair, predeclared comparison requires real QPU timing, queue-independent execution metrics or hardware samples.
- The audit must reproduce a published hardware job whose identity and result are part of the claim.
In those cases, the audit record should freeze the circuit or problem payload, provider, backend, job identifier, compiler or transpiler versions and parameters, qubit layout, shots, calibration context, raw counts, post-processing, mitigation, repeats and statistical uncertainty.
Hardware is not yet needed when an earlier test can decide the issue
A malformed circuit, missing baseline, ambiguous metric or unbounded cost model should be resolved before hardware spend. Small circuits can often be checked by exact statevector simulation. Claimed algebraic identities can be tested formally. A model-selection claim needs a frozen evaluation contract and a strong classical comparator before a QPU adds useful evidence.
IonQ advises testing on a simulator before hardware in its Azure Quantum guide. This is sensible audit sequencing, not evidence that a later hardware run will support the claim.
Calibration and transpilation change the record
IBM documents that transpilation transforms a circuit to a selected backend's instruction set and topology, and that stochastic passes may require a seed for reproducibility. See IBM's transpilation guide and common parameters. IBM also notes that calibrations run throughout the day, so two jobs can use different calibration sets. A later rerun can be informative without being identical.
That is why a credible audit does not archive only a high-level circuit and final chart. It preserves the transformation and hardware context between them.
Make a fit decision before spend
- State the exact claim and the decision that depends on it.
- Identify which part requires proof, simulation, QPU evidence or comparison.
- Freeze the workload and acceptance criteria.
- Run classical controls and simulators where feasible.
- Estimate provider usage and set a cost ceiling.
- Execute only if the remaining uncertainty is genuinely hardware-dependent.
A defensible “not yet” is a successful preflight result. It prevents a visually impressive hardware run from being mistaken for evidence that it cannot supply.
Next, read how to independently audit quantum-computer results and what a quantum-computing research audit costs.