Reproducible Quantum Build and Execution Environments

Quantum reproducibility is not only about rerunning a circuit. It is about rebuilding the environment that generated the circuit, transpiled it, selected the backend, submitted the job, interpreted the results, and produced the claim.

SLSA defines provenance as an attestation tying produced artifacts to the build platform and build definition [R206]. Cloud Native Buildpacks frame reproducibility as the same inputs producing the same outputs, with practical caveats for container images [R209]. Quantum platforms should adopt the same pattern: every experiment artifact should have a reproducible build path and an execution attestation.

Diagram loads as you read

Reproducible Quantum Build and Execution Environments · Figure 1

View diagram source

flowchart LR
    Source[Source repo] --> Build[Build environment]
    Build --> Image[Container image]
    Image --> Lock[Dependency lock]
    Lock --> Circuit[Circuit artifact]
    Circuit --> Submit[Submission package]
    Submit --> Job[Quantum job]
    Job --> Result[Result artifact]
    Result --> Attestation[Execution attestation]

Separate build reproducibility from physics reproducibility

A reproduced container does not reproduce a QPU state. It reproduces the software environment. A reproduced calibration snapshot does not reproduce a random shot stream. It contextualizes the physical environment.

Diagram loads as you read

Separate build reproducibility from physics reproducibility · Figure 2

View diagram source

flowchart TB
    Repro[Reproducibility] --> Build[Build reproducibility]
    Repro --> Execution[Execution reproducibility]
    Repro --> Statistical[Statistical reproducibility]
    Repro --> Claim[Claim reproducibility]
    Build --> SameImage[Same image and dependencies]
    Execution --> SameContract[Same runtime contract and baseline]
    Statistical --> CompatibleDistribution[Compatible distribution]
    Claim --> SameDecision[Same bounded conclusion]

The goal is not bit-for-bit equality of shot outcomes. The goal is bounded equivalence under the stated physical and statistical assumptions.

Execution environments

The execution environment includes more than Python packages.

Layer	Required capture
source	commit, branch, patch state, review status
dependencies	lock file, package hashes, solver version
container	image digest, base image, build recipe
SDK	SDK version, provider plugin, transpiler version
compiler	target, pass manager, optimization level, seed
runtime	primitive, execution mode, shot policy, resilience options
backend	QPU identifier, baseline ID, queue window
post-processing	script hash, model version, statistical method

Diagram loads as you read

Execution environments · Figure 3

View diagram source

flowchart TB
    Env[Execution environment] --> Source[Source hash]
    Env --> Deps[Dependency lock]
    Env --> Image[Image digest]
    Env --> SDK[SDK and provider versions]
    Env --> Compiler[Compiler and target]
    Env --> Runtime[Runtime options]
    Env --> Backend[Backend baseline]
    Env --> Post[Post-processing version]

Artifact graph

Every artifact should be linked forward and backward.

Diagram loads as you read

Artifact graph · Figure 4

View diagram source

flowchart LR
    Requirements[Experiment requirements] --> Spec[Workload spec]
    Spec --> BuildDef[Build definition]
    BuildDef --> Container[Container digest]
    Container --> CircuitIR[Circuit or IR]
    CircuitIR --> Transpiled[Transpiled circuit]
    Transpiled --> JobRequest[Job request]
    JobRequest --> JobResult[Job result]
    JobResult --> Notebook[Analysis notebook]
    Notebook --> Report[Evidence report]

The graph allows a reviewer to start at a published chart and walk backward to the exact code, data, baseline, and runtime contract.

Randomness and seeds

Seeds should be captured, but they should not be mistaken for full determinism.

Diagram loads as you read

Randomness and seeds · Figure 5

View diagram source

flowchart TB
    Randomness[Randomness] --> SimSeed[Simulator seed]
    Randomness --> OptimizerSeed[Optimizer seed]
    Randomness --> SamplingNoise[Shot noise]
    Randomness --> HardwareNoise[Hardware noise]
    SimSeed --> Deterministic[Often reproducible]
    OptimizerSeed --> Path[Reproduces configured pseudorandom choices]
    SamplingNoise --> Distribution[Requires statistical comparison]
    HardwareNoise --> Baseline[Requires baseline context]

For simulators, seeds can reproduce pseudorandom choices when the implementation and environment are controlled. Reconstructing an optimizer trajectory also requires its initial parameters, options, and recorded objective evaluations; hardware shot outcomes cannot be regenerated from an optimizer seed. For hardware, use uncertainty-aware distribution comparisons and predeclared success criteria.

Build attestations for quantum work

A useful quantum build attestation records:

Illustrative listing · yaml

artifact_type: quantum_experiment_bundle
source_commit: 9f2c1a7
builder_id: qbuild-prod-03
build_definition: quantum-ci-v4.yaml
container_digest: sha256:...
dependency_lock_digest: sha256:...
transpiler_version: qiskit-x.y.z
provider_plugin_version: provider-a.b.c
compiler_target_id: target-2026-04-20T1015Z
created_at: 2026-04-20T11:45:00Z

Diagram loads as you read

Build attestations for quantum work · Figure 6

View diagram source

flowchart LR
    Builder[Trusted builder] --> Attest[Build attestation]
    Attest --> Bundle[Experiment bundle]
    Bundle --> Admission[Admission controller]
    Admission --> Execute{Allowed?}
    Execute -- yes --> QPU[QPU runtime]
    Execute -- no --> Reject[Reject with reason]

Admission control should be able to reject unsigned bundles, unreviewed dependencies, unknown compiler targets, or stale baselines.

Practical rule

A quantum result is not reproducible because the circuit is stored. It is reproducible when the artifact graph can be rebuilt, the execution context can be reconstructed, and the statistical claim can be re-evaluated.

Additional technical sources: [R281].