Keep a record of what actually ran¶
Run a two-qubit Bell circuit and connect the submitted program, local job and returned result. You will check the selected method, seed, ordering and trace, then decide what still needs to be saved for another researcher to repeat the experiment. Complete the Bell lesson and results and reports first.
Two files can contain identical counts while coming from different circuits or configurations. Counts describe the sampled outcomes; the surrounding records identify how they were produced. A hash is an identifier for the recorded content, not a substitute for retaining that content.
Run and inspect¶
"""Audit Digital execution through Result references and configuration facts.
Counts alone are insufficient evidence. An expert consumer also checks program
hash, bit order, selected method, seed semantics, diagnostics, and whether a
full RunTrace is actually available on this standalone Digital path.
"""
from __future__ import annotations
import json
from cascaqit import Circuit, LocalBackend
def main() -> None:
"""Run one Digital Job and verify its cross-object references."""
circuit = Circuit(2, program_id="lesson.digital.evidence")
circuit.h(0).cx(0, 1).measure_all(key="readout")
job = LocalBackend(seed=205).run(circuit, shots=32)
result = job.result()
config = result.metadata["simulation_execution_config"]
payload = {
"track": "digital_developer",
"level": "expert",
"lesson": "execution_evidence",
"facts": {
"job_state": job.status().state,
"program_hash_matches": result.program_hash
== circuit.to_ir().stable_hash(),
"trace_available": "run_trace" in result.metadata,
"reference_program_hash_matches": (
result.metadata["references"]["program_hash"] == result.program_hash
),
"method": config["method"],
"seed": config["seed"],
"bit_order": result.metadata["bitstring_ordering"]["qubit_order"],
"diagnostic_codes": result.metadata["diagnostics_summary"]["codes"],
},
"boundaries": {
"hardware_execution": False,
"cloud_execution": False,
"network_accessed": False,
"credentials_loaded": False,
},
}
print(json.dumps(payload, sort_keys=True))
if __name__ == "__main__":
main()
python3 examples/user/tracks/digital_developer/05_expert_execution_evidence_en.py
{
"boundaries": {
"cloud_execution": false,
"credentials_loaded": false,
"hardware_execution": false,
"network_accessed": false
},
"facts": {
"bit_order": [
"q0",
"q1"
],
"diagnostic_codes": [
"DIGITAL_SIMULATION_COMPLETED",
"DIGITAL_RESULT_ALIGNMENT_VALID"
],
"job_state": "completed",
"method": "state_vector",
"program_hash_matches": true,
"reference_program_hash_matches": true,
"seed": 205,
"trace_available": true
},
"lesson": "execution_evidence",
"level": "expert",
"track": "digital_developer"
}
| Check | What it establishes in this run |
|---|---|
job_state |
The local job completed |
program_hash_matches |
The result identifies the submitted circuit's numeric program |
reference_program_hash_matches |
The result's reference record agrees with its program identifier |
method, seed |
The recorded configuration uses state-vector execution and seed 205 |
bit_order |
Read displayed bits in [q0, q1] order |
diagnostic_codes |
The local path reports completion and result alignment |
trace_available |
Whether this result contains a run trace; the current example returns true |
In your copy, inspect result.metadata["run_trace"] and result.state_transitions(). This standalone Digital run records a Digital state transition and terminal sampling. It does not supply a separate captured state after every gate. Its logical timestamps and integrator_selected="not_applicable" should not be treated as gate-duration measurements or an Analog integration record. Fields for unrelated compilation or hardware records can be absent or null.
Save enough to repeat the experiment¶
Use result.to_dict() for the structured result and retain the script, bound parameters, SDK source revision and dependency versions alongside it. The HTML report is a view of that result; save the original data too. The experiment record template lists the context that a screenshot usually loses.
Practice these changes separately:
- Change the seed from 205 to 206 without editing gates. Which reference should remain the same, and which data may change?
- Remove CX and rerun. Compare the program reference and probabilities with the original run.
- Keep the gates fixed but rename the measurement register. Explain why “same ideal state” is not the same claim as “same complete program record.”
Check your reasoning
A seed change affects sampling configuration, not the submitted gate program or its ideal probabilities. Counts may change, although equality by chance is possible. Removing CX changes the circuit and its ideal distribution. A measurement-register name is part of the complete program description; changing it can change program identity without changing the prepared state. Matching program identifiers alone cannot confirm that a seed, dependency version or numerical option was held fixed.
Completion diagnostics do not prove that the experiment answers the intended scientific question. Combine execution records with a physical prediction or independent reference, as in the Rabi project. For mixed gate and pulse execution, continue with the D-A-D lesson.