A quantum workflow contains several kinds of progress. A classical application can finish compiling while its quantum work remains unsubmitted. A worker can finish sampling while the resulting estimate remains too uncertain to use. An operator can interrupt execution without making the completed observations disappear. A useful runtime represents these distinctions explicitly.
The lab gives them concrete names. A job is one durable request with an identifier, configuration, execution status, and evidence record. A batch contains additional measurements. A checkpoint is a permitted cumulative sample count at which the statistical rule is evaluated. These objects connect the timing and feedback ideas from the preceding chapter to an application that can be inspected and resumed.
Follow the work across boundaries
The local runner first stores a job as queued. Execution claims it and changes its status to running. After a complete checkpoint it saves counts and the recomputed analysis. A terminal statistical result produces completed, with a separate disposition of accepted, rejected, or inconclusive. Interrupted, cancelled, and failed executions have their own statuses. The distinction matters: a completed, valid experiment can remain inconclusive because its budget was insufficient.
A cloud session, when a provider offers one, is an execution context whose scheduling and lifetime rules come from that provider. The word does not establish a universal latency guarantee or imply that arbitrary quantum state survives between submitted circuits. Our local lab has no provider session API. Its durable context is the classical job record; each shot prepares a fresh Bell state.
For a future hybrid optimizer, an application-level session could group an initial parameter vector, objective evaluations, and optimizer state. That is an architectural extension. It would need an explicit restart contract, especially when an update depends on a measurement result that has not yet been committed.
Worked example: resume without changing the experiment
After installing the local project, run:
quantum-ops --db workflows.sqlite3 run --scenario interruptedThis scenario deliberately stops after two completed checkpoints. The checkpoints are 100 and 200 shots per basis. The second batch therefore contains 100 additional shots per basis, not 200. Across three bases, the saved record represents 600 shots.
Copy the returned identifier and replace RUN_ID in the following commands:
quantum-ops --db workflows.sqlite3 inspect RUN_ID
quantum-ops --db workflows.sqlite3 resume RUN_IDThe resumed job retains its identifier and its first two batches. The next checkpoint is 500 shots per basis, requiring another 300 in each basis. That adds 900 shots and brings the total to 1,500. The sampler seeds are derived from the original run seed, checkpoint index, and basis, so the pinned local implementation can replay this continuation.
Resume does not authorize changing the noise parameters, statistical rule, or engine implementation. The runner checks evidence and engine compatibility before continuing. A changed experiment needs a new record. The saved data are classical observations; this procedure does not checkpoint an unknown quantum state.
Admission and cancellation have different jobs
The loopback HTTP service admits at most two active worker tasks and rejects further submissions with HTTP 429 while those slots are occupied. That is a deliberately small teaching limit, not an implemented reservation market or a fairness scheduler. More elaborate admission policies belong in Capacity, Scheduling, and Cost.
Cancellation asks the worker to stop and preserves completed evidence. It is not permission to report a partially completed checkpoint as an approved statistical look. A distributed extension would also have to reconcile provider-side work that finished after a cancellation request. Retrying a submission without identifying the original work can create another experiment; it does not automatically resume the first.
Exercise and worked answer
An interrupted job contains checkpoints 100 and 200 in all three bases. A proposed recovery routine submits 500 new shots per basis and records the next checkpoint as 500. What is wrong, and what should the operator do if the calibration context also changed?
Worked answer: The routine would actually accumulate 700 shots per basis. Its declared checkpoint would disagree with its batch counts, and 700 is not one of the approved looks. Add 300 shots per basis to reach 500. If the calibration context changed, start a separate run instead of appending those observations to the old stationary experiment. Preserve the previous record and describe the relationship between runs, as developed in Incidents, Recovery, and Safe Changes.