Certification for Quantum Simulation and Hardware: ZCC-v0.1 and ZHF-v0.1

Approximate classical simulation has become the practical backbone of near-term quantum research. Matrix product state (MPS) and Pauli propagation methods now reach one hundred qubits and beyond on commodity hardware, and they are the tools most researchers actually use to prototype algorithms, validate hardware, and estimate resources. Real quantum processors present the same problem from the other direction: a device returns measured counts with no statement of how closely those counts track the ideal answer. Across much of the commercial landscape, both simulated and hardware results are delivered as bare numbers, with no accompanying statement of how far those numbers may sit from the truth.

This omission is consequential, because approximate methods are approximate by construction and physical hardware is noisy by construction, and both characteristic failure modes are silent. The purpose of this article is to make the accuracy statement a first-class output on both sides: to define what can be claimed, to separate evidence from proof, and to specify the two versioned protocols we attach to every job, ZCC-v0.1 for simulated results and ZHF-v0.1 for hardware results.

The failure mode of approximate simulation

An MPS simulator run with insufficient bond dimension does not raise an error. It returns a normalized probability distribution that looks entirely plausible and is quietly wrong. A Pauli propagation run with an overly aggressive truncation threshold behaves the same way. Unlike a numerical routine that diverges or a program that crashes, the truncated simulation converges to a confident answer that happens to be incorrect. Any accuracy framework must therefore be designed to detect precisely this quiet, self-consistent kind of error.

Convergence as evidence

The most broadly applicable accuracy check is a convergence study. Every approximate method exposes a resource parameter: the bond dimension for MPS, the coefficient cutoff for Pauli propagation. Running a circuit at resource level chi and again at 2chi, then measuring the change in the reported observables, yields direct evidence about whether the approximation has saturated. If doubling the resource leaves the result unchanged within tolerance, the additional representational capacity found nothing new. If the result moves, that movement is itself a quantified warning. This is the same discipline that basis-set convergence and mesh refinement have provided in computational chemistry and numerical analysis for decades.

In the SDK, this is the default behavior for the tensor-network engine. No special flag is required; the convergence record is attached to every result.

import qsim_sdk

client = qsim_sdk.Client(token="...")
result = client.run(circuit, engine="mps.quimb.cpu")

print(result["error_info"])
# {
#   "method": "MPS (quimb), 3-point convergence extrapolation",
#   "bond_sequence": [64, 128, 256],
#   "step_deviations": [0.0, 0.0],
#   "converged": true
# }

A convergence check is strong evidence, but it is not a proof: it demonstrates that the answer stopped moving, not that it cannot move. We label it as such and never describe it as a certified bound.

A rigorous single-run bound

For matrix product states, a genuinely rigorous accuracy statement is available in a single run. When the circuit is built with state renormalization disabled, the squared norm of the final state records exactly how much weight every singular-value decomposition discarded during truncation. Writing eps for that accumulated discarded weight, eps equals one minus the squared norm of the final state. By the Eckart-Young theorem this quantity is exact, not estimated, and the error on any single outcome probability is bounded above by the square root of twice eps. This is a ceiling measured directly from the computation, not an extrapolation across runs.

Passing certified=True selects this path, and the reported error_bound is the rigorous quantity.

result = client.run(circuit, engine="mps.quimb.cpu", certified=True)

print(result["error_info"])
# {
#   "protocol": "ZCC-v0.1",
#   "method": "MPS (quimb), rigorous discarded-weight bound",
#   "truncation_weight": 3.2e-09,   # eps = 1 - ||psi||^2
#   "error_bound": 8.0e-05,         # sqrt(2 * eps)
#   "certified": true
# }

Pauli propagation admits the analogous statement. The engine reports the total discarded coefficient mass, which bounds the error on the returned expectation value directly. In both cases the quantity is measured within the run rather than inferred from a second one.

As a concrete, reproducible example, a 192-qubit GHZ circuit measured with an all-Z observable on the pauli.cpu engine returns an expectation value of exactly +1, carrying a certified ZCC-v0.1 error bound of 0 because no Pauli terms were discarded during propagation. A statevector simulator cannot reach this size, since 192 qubits would demand more memory than exists on Earth, yet the run completed in under a minute for $0.001, a tenth of a cent. Its certificate is public and independently verifiable at api.zksf.org/certify/5b8b2c4309d44d41, and the three lines of SDK code that reproduce it are in the documentation.

ZCC-Estimate-v0.1: error mitigation, reported as an estimate

Convergence and the discarded-weight bound both concern classical simulation accuracy. Error mitigation raises a related but distinct question about noisy results: given a measured expectation value, how close is it to the noise-free answer, and how far might the correction still be off? Zero-noise extrapolation (ZNE) is the standard technique. The circuit is evaluated at several deliberately amplified noise levels and the chosen observable is extrapolated back to the zero-noise limit, which removes much of the coherent bias that gate noise introduces. It runs on the simulator as a cheap preview, and on real hardware, where each noise level is a separate submission, so a three-point extrapolation is three billed runs.

The result carries a ZCC-Estimate-v0.1 statement: the mitigated value together with an uncertainty taken as the larger of the shot-noise uncertainty propagated through the extrapolation and the disagreement between the linear, quadratic, and Richardson extrapolations of the same measured data. Both quantities are computed without reference to the true answer, so the identical statement applies on hardware, where the true answer is unknown. This is an evidence-based statistical estimate, not the rigorous ceiling of the certified path: an extrapolated value cannot be bounded with certainty, and the protocol is named and labelled to say so rather than borrowing the authority of a proof it does not have.

result = client.run(circuit, engine="noisy.cpu", mitigate=True,
                    observable=[[1.0, "ZZ"]])

print(result["error_info"])
# {
#   "protocol": "ZCC-Estimate-v0.1",
#   "technique": "zero-noise extrapolation",
#   "raw_expectation": 0.81,
#   "mitigated_expectation": 0.82,
#   "error_bound": 5.0e-02,
#   "estimated": true
# }

Most platforms that offer mitigation at all return the mitigated number alone, with no error statement. Reporting the uncertainty, and labelling it an estimate rather than a bound, applies the same discipline to a third case: state what can be claimed, and separate evidence from proof.

Reproducible benchmarks

The following runs are drawn from our public benchmark suite, which ships with the SDK so the numbers can be reproduced independently. The CPU figures are from a single consumer laptop (Intel i7-12700H, 32 GB RAM); the 32-qubit statevector is from the GPU tier.

Circuit                        Qubits  Depth  Engine      Wall time  Accuracy
GHZ (Clifford)                 5,000   5,000  clifford    0.56 s     exact
QAOA MaxCut ring, p=3          100     304    mps.quimb   5.9 s      converged (dev 0.0)
Hardware-efficient ansatz      100     9      mps.quimb   5.6 s      converged (dev 0.0)
Exact reference (ansatz)       26      9      exact.cpu   2.7 s      exact (ground truth)
GHZ exact statevector (GPU)    32      32     exact.gpu   8.2 s      exact (64 GiB state)

The convergence verdicts above are not decorative. Each MPS entry was recomputed at double the bond dimension, and the maximum shift in the leading outcome probabilities was zero to the reported precision. Where an exact reference is tractable, as in the 26-qubit statevector row, the approximate engines reproduce it.

ZHF-v0.1: the hardware analogue

The same infrastructure certifies a different and complementary claim on real hardware. A quantum processor returns its own measured counts, and the relevant statement is device fidelity rather than approximation error, so it carries its own protocol, ZHF-v0.1, rather than being folded into ZCC-v0.1's simulation-accuracy claim. Where the circuit is small enough to also simulate exactly, ZHF-v0.1 reports the measured fidelity between the hardware counts and that exact ideal distribution, computed directly rather than taken from a vendor specification sheet. Two representative runs, submitted through the same API as a simulator job and reported exactly as measured:

Rigetti Cepheus-1-108Q   3-qubit GHZ, 50 shots    000: 23, 111: 22, plus 5 bit-flip errors   45/50 in the GHZ states
IonQ Forte-1             2-qubit Bell, 100 shots   00: 54, 11: 44, 01: 2                        98/100 in the Bell states

These are raw counts with no error mitigation applied. Reported as a live, session-specific fidelity rather than a vendor specification sheet, such measurements are the honest hardware analogue of a simulation error bar. The certificate for the IonQ run above, generated directly from this platform, is shown below.

Verifiable certificates, and why verification matters

An error bound printed in a terminal is only as trustworthy as the person who ran the job. Once a number leaves that session and enters a paper, a slide deck, or a client report, its provenance is gone; a reader has no way to confirm the circuit that was actually run, the method that produced the figure, or whether the number was transcribed correctly. This is not a hypothetical concern. Simulation results are increasingly cited as evidence in hardware comparisons and algorithm papers, and an unverifiable number is, in practice, an assertion rather than a result.

Any completed job can be exported as a certificate that closes this gap. Each certificate is a self-contained record, independent of the account that generated it, that anyone can check without signing in or trusting the author's transcription. A certificate carries:

• The exact circuit, identified by a SHA-256 hash of its source, so the certificate cannot be silently attached to a different computation.
• The method and its parameters: which engine ran the job, and, where relevant, the resource budget used (bond dimension, coefficient cutoff, or the classical direct-verification limit for hardware runs).
• The accuracy verdict: a rigorous error bound, a convergence-based estimate, or a measured hardware fidelity, labeled according to which of these it is, never blurred together.
• A public, permanent verification link, backed by a record containing no account, billing, or personal information, so the certificate can be checked independently of ZKSF as a company.

A reviewer or collaborator can follow that link and see the same figures the author reported, tied to the same circuit, with no additional trust required. That is the entire purpose of a certificate: to move an accuracy claim from something a reader must take on faith to something a reader can check in one click. A representative example, the certified ZCC-v0.1 simulation-accuracy job referenced earlier, is shown below.

Recommendations for practitioners and reviewers

For those reviewing manuscripts, we suggest asking authors what accuracy evidence accompanies any classical simulation baseline, and specifically what a second run at doubled resources would show; for a hardware result, the equivalent question is what fidelity was measured against, and whether that was computed directly or asserted by the vendor. For those procuring simulation or hardware access, the same questions apply to the provider. A convergence record, a rigorous truncation bound, and a measured hardware fidelity are all inexpensive to produce and straightforward to verify, and their absence is itself informative. ZCC-v0.1 and ZHF-v0.1 are our attempt to make their presence the default.