Certification
Verification requires a stated error
Approximate methods return estimates. The question that decides whether a result can be used is how far from the truth it might be, and that quantity is measured on every run rather than assumed.
The failure mode is silent
A matrix product state 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 routine that diverges or a program that crashes, the truncated simulation converges to a confident answer that happens to be incorrect.
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. Any accuracy framework has to be built to detect exactly this quiet, self-consistent kind of error.
Three statements, never blurred together
Each protocol answers a different question, and each is labelled for what it is. A measured bound is not an extrapolated estimate, and neither is a hardware fidelity.
ZCC-v0.1 · simulation accuracy
- protocol
- "ZCC-v0.1"
- method
- "MPS, discarded-weight bound"
- truncation_weight
- 3.2e-08
- error_bound
- 2.5e-04
- certified
- true
An error bound read from the weight discarded during simulation, measured in one run rather than extrapolated
ZHF-v0.1 · hardware fidelity
- protocol
- "ZHF-v0.1"
- device
- "IonQ Forte-1"
- fidelity_mode
- "direct"
- fidelity
- 0.9774
Real hardware counts measured against the exact ideal distribution, not a self-reported device spec
ZCC-Estimate-v0.1 · error mitigation
- protocol
- "ZCC-Estimate-v0.1"
- technique
- "zero-noise extrapolation"
- raw_expectation
- 0.81
- mitigated_expectation
- 0.82
- error_bound
- 5.0e-02
- estimated
- true
A mitigated value with an honest statistical uncertainty, labelled an estimate rather than a measured bound
Convergence is evidence
Every approximate method exposes a resource parameter: bond dimension for MPS, coefficient cutoff for Pauli propagation. Running a circuit at resource level chi and again at 2chi, then measuring the change in the reported observables, shows directly whether the approximation has saturated. If doubling the resource leaves the result unchanged, the extra representational capacity found nothing new. If the result moves, that movement is itself a quantified warning.
This is the default for the tensor-network engine. It is strong evidence, and it is not a proof: it shows the answer stopped moving, not that it cannot move. We never describe it as a certified bound.
A measured single-run bound
Passing certified=True selects a stronger path. The circuit is built with state renormalization disabled, so the squared norm of the final state records exactly how much weight every singular-value decomposition discarded. Writing eps for that accumulated weight, eps equals one minus the squared norm. Each truncation is optimal by the Eckart-Young theorem, and eps is measured rather than estimated. The error on any single outcome probability is reported as the square root of twice eps.
Pauli propagation is the stricter case: its bound is an additive triangle inequality over discarded coefficient mass, and needs no such assumption.
Where the bound stops holding
The square-root figure is tight when the individual truncation errors accumulate incoherently. That condition is not always satisfied. Across N sequential truncations the adversarial accumulation is the sum of the square roots of the individual eps values, which can exceed the square root of twice their total. In deep circuits the accumulated eps has been measured understating the true infidelity by as much as a factor of seven.
The reported bound is therefore an empirical result rather than a consequence of that derivation. Across 334 runs at sizes where the exact answer is computable, 290 of them constructed specifically to falsify it, the figure was never exceeded, coming closest at 49 percent of its value. Those checks need an exact reference and so reach 20 qubits. Beyond that size no direct verification is available, and we say so rather than implying the evidence extends further. Where a hard ceiling is required, use an exact or stabilizer engine.
Why a certificate, and what is in one
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 which circuit was actually run, which method produced the figure, or whether the number was transcribed correctly. An unverifiable number is an assertion rather than a result.
- The exact circuit, identified by a SHA-256 hash of its source, so a 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
- The accuracy verdict: a measured bound, a convergence-based estimate, or a measured hardware fidelity, labelled according to which it is
- A public verification link, backed by a record containing no account, billing, or personal information
A simulation whose own error bound would be vacuous is refused rather than returned, with a diagnostic stating what would make the circuit tractable.
Checkable without us
A certificate issued by the party that produced the result is a claim, not evidence. zcc-verify is an open-source checker that recomputes a certificate’s declared bound from the measurement the certificate reports, and requires the two to agree. It has no dependencies, needs no account, and does not call this service.
It establishes that a certificate is well formed and self-consistent. It does not establish that the underlying measurement was honestly made, and states as much. Verifying a certificate is not the same as trusting its issuer.
$ pip install zcc-verify$ zcc-verify df1d4c698a954051certificate df1d4c698a954051 (ZHF-v0.1)[ok] protocol recognised: ZHF-v0.1[ok] carries no account or circuit data[ok] circuit identified by SHA-256[ok] measured outcomes: 3 outcomes, 100 shots shown[ok] fidelity mode declared: direct[ok] fidelity within [0, 1]: 0.977442consistent: the stated bound follows from the stated measurement
A 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. 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.
For practitioners and reviewers
When reviewing a manuscript, it is worth asking what accuracy evidence accompanies a classical simulation baseline, and specifically what a second run at doubled resources would show. For a hardware result, the equivalent question is what the fidelity was measured against, and whether that was computed directly or asserted by the vendor. The same questions apply when procuring simulation or hardware access. A convergence record, a measured truncation bound, and a measured hardware fidelity are all inexpensive to produce and straightforward to verify, and their absence is itself informative.
Read further
The specification paper
Derivations, validation methodology, and the adversarial falsification search. Archived on Zenodo, DOI 10.5281/zenodo.21851381
The methodology write-up
The longer article, with code samples, reproducible benchmarks, and sample certificates
SDK documentation
How to request a certified bound, export a certificate, and read every field
Run a certified circuit
Open the console and produce a certificate of your own