Reproducible quantum experiments need more than a histogram.

A chart may accurately represent one output file while leaving essential questions unanswered. Which circuit version ran? Was the source generated before or after the final canvas edit? Did the output come from an ideal simulator, noisy model, or provider target? How many shots were requested, and did a retry change the route?

Reproducibility begins by preserving the dependency chain around the counts. QFlow addresses this as a workflow-record and evidence-packet problem: the result stays attached to identity, source snapshot, route, runner, run trace, exports, review notes, and an explicit statement of fields excluded from sharing.

A minimum record needs stable workflow and run identifiers plus a source snapshot tied to that execution. The canvas may continue evolving after a run, so a reviewer cannot assume that today’s visual state produced yesterday’s result. Version, owner, and timestamp make that distinction visible.

QFlow’s documented manifest includes a source snapshot with generated Qiskit and OpenQASM paths. Where source was exported or changed outside the studio, the record should state the boundary instead of presenting generated and executed code as automatically identical.

The public evidence manifest is a practical minimum, not the ceiling for research. A reproducible study may also need SDK, package, transpiler, compiler, simulator, and operating-environment versions; random seeds; optimization levels; noise-model configuration; and resource-estimation assumptions.

These details can live as supplemental artifacts when the base manifest does not expose a dedicated field. The important property is discoverability: another person should see that context exists, where it is stored, and which version belongs to the run rather than hunting across messages and notebooks.

The same logical circuit can produce different operational records on an ideal simulator, noisy simulator, resource estimator, and hardware route. The record should therefore preserve route type and status, runner, shots, seed where relevant, provider job reference, timestamps, queue and execution states, failure reason, and retry history.

Hardware comparisons may also require the available backend, topology, calibration, compilation, and mitigation context. When a provider does not expose a required field or historical snapshot, say that it is unavailable. Missing information is safer than silently pretending it did not matter.

Raw counts, probabilities, JSON or CSV rows, and a run trace allow a reviewer to verify the transformation behind a chart. A derived metric should identify its calculation and reference. If post-processing removes states, normalizes a subset, mitigates error, aggregates jobs, or chooses the best of several attempts, that transformation should be visible.

QFlow’s public Bell evidence example demonstrates a narrow artifact chain: source, counts and exports, trace, a share-safe link, and a manifest stay connected. It is evidence of the packet design, not proof that every future experiment becomes reproducible because an export button exists.

W3C PROV distinguishes entities such as a source snapshot or result file, activities such as compilation and execution, and agents such as a workflow owner or reviewer. Workflow Run RO-Crate applies a related idea to packaging computational runs. These models are useful because provenance is relational: a file matters through how it was produced and used.

QFlow’s workflow record can act as the user-facing index into that graph. It does not have to replace repositories or research packages. It should point clearly from the brief to source, route, run, exports, transformation, review, and next decision so additional artifacts remain understandable.

Provider tokens, billing state, administrator permissions, private emails, and raw secrets do not help reproduce the scientific path. They create security risk. A reviewer-safe packet should expose sufficient circuit, source, route, run, and output context while explicitly marking private fields as excluded.

The final test is practical: ask a reviewer unfamiliar with the run to identify the exact source, route, runner, shots, raw output, transformations, and known gaps, then attempt a controlled rerun. Stochastic results need a declared tolerance or distributional comparison; reproducibility does not require every finite-shot sample to be numerically identical.