A quantum program becomes useful through a sequence of physical and computational decisions. Someone chooses a question, prepares a circuit, selects a target, schedules execution, interprets measurements, and decides whether the evidence supports a claim. Operating the computer means keeping that entire sequence coherent. A successful job submission is one event in it.
This book follows that sequence through a small Bell-state experiment and a separate error-correction experiment. Both run locally in simulators. Their value is that the implementation, assumptions, measurements, and decisions can be inspected together. Their results do not certify a quantum device or establish a commercial advantage.
A program is an instruction for an experiment
A classical program often returns a value that can be checked directly. A quantum circuit commonly returns samples from measurements. Those samples become an estimate only after an analysis specifies what was measured, how outcomes map to numbers, and what uncertainty is acceptable. Some quantum measurements have deterministic outcomes in ideal circumstances; probabilistic outputs are common, not universal.
A circuit description also leaves work for the surrounding system. Abstract gates must become supported operations, logical qubits must be assigned to physical resources, and measurements must be associated with the correct classical bits. On hardware, control electronics and calibration determine how those instructions are realized. The same abstract circuit can therefore lead to different physical experiments on different targets.
The operator's first useful habit is to keep five objects distinct: the scientific objective, the program, the target configuration, the execution record, and the interpreted result. A target change might preserve the program while changing the experiment. An analysis correction might preserve the raw measurements while changing the conclusion. Recording those distinctions makes changes reviewable.
Execution state and scientific disposition
The teaching runner records execution state separately from scientific disposition. A run can finish normally and still be inconclusive because its shot budget was insufficient. A cancelled run can contain useful partial measurements without supporting the requested conclusion. An invalid evidence package is a validation problem, even if a simulator returned counts.
This separation prevents an operational dashboard from turning every green job into a scientific success. “Completed” answers whether execution reached its stopping point. “Accepted” answers whether a specified decision rule was met. Neither word implies that a different workload, noise model, or device would pass.
The Bell example requests a raw measured score with a lower confidence bound of at least 0.9 and a confidence half-width no larger than 0.04. It checks only declared cumulative shot counts. These are teaching requirements attached to this experiment, not universal definitions of a good quantum computer.
Worked example: three numbers for one experiment
At the baseline parameters, the implemented model prepares a state with analytic Bell overlap 0.985 before readout. The declared measurement-error model lowers the expected raw score to approximately 0.955894. The captured simulator run estimates that raw score as 0.9561 after 5,000 shots per measurement basis.
These numbers answer different questions. The first describes the prepared state in the known model. The second includes the model's readout process. The third is a finite-sample estimate. Its simultaneous half-width is approximately 0.038923, giving a lower bound near 0.917177. The run satisfies the declared acceptance rule.
The accounting matters too. There are three bases, so 5,000 shots per basis means 15,000 preparations and measurements. The checkpoints are cumulative: reaching 5,000 does not mean purchasing 100 plus 200 plus 500 plus every later checkpoint again. A separate recovery run has its own measurements and must be counted separately.
Evidence belongs to the operating loop
Useful evidence connects configuration, implementation versions, target context, sample counts, analysis, and the stopping decision. A checksum can detect an accidental change relative to a recorded digest. It does not prove that a physical experiment occurred or authenticate an unknown author. Statistical validation and evidence integrity solve different problems.
The local simulator can replay a recorded sampling sequence under the tested implementation and environment. That does not recreate an unknown hardware state or restore yesterday's calibration. Hardware repetitions generally seek statistically compatible evidence under documented conditions.
Exercise: interpret the dashboard
Two runs report completed. Run A reaches its budget with an interval crossing the acceptance threshold. Run B meets both the lower-bound and width requirements. What should a dashboard report, and should it automatically combine their counts?
Answer. A is completed and inconclusive; B is completed and accepted. Counts should be combined only under an analysis that permits pooling and establishes compatible experimental contexts. Shared execution status supplies neither condition. A useful dashboard shows each run's decision rule, budget, context, and uncertainty alongside its status.
Continue with circuits, measurement, and observables, or open the interactive lab to see the operating loop as a concrete experiment.