A workload contract states what the service has agreed to attempt and what evidence would justify using the result. It joins a scientific question to executable constraints. In this lab, the question concerns an observed Bell correlation score. The constraints specify its three measurement bases, seven permitted sample counts, noise model, budget, and stopping rule.
The architecture becomes easier to understand when every component has a bounded responsibility. The configuration describes the request. The sampler produces outcomes. The statistical analyzer interprets counts. The runner advances the job and persists evidence. The validator checks whether the complete record agrees with the contract. The command line and local HTTP service call that same runner.
Make the contract inspectable
The concrete configuration contains id, p, q, budget, seed, and context. The scenario identifier selects a teaching case. The two noise parameters describe the declared simulator model. Budget is a maximum cumulative count per basis drawn from the approved checkpoint list. Context identifies the operating regime to which the samples belong.
Some requirements live outside those six fields. The shared scenario artifact fixes the bases, acceptance threshold, confidence allocation, and maximum half-width. The evidence schema fixes the record structure. Their hashes identify the exact artifacts used for a run. Separating these concerns avoids pretending that a bare circuit is a complete request.
Structural and semantic validation answer different questions. A schema can require a nonnegative count. The semantic validator also needs to establish that every basis received the correct incremental number of shots, that checkpoints occur in order, and that sampling stopped when required. A correctly shaped history is insufficient if its score was not computed from its counts.
A small service with a real execution path
The Python implementation stores jobs in SQLite and records worker ownership. The runner claims a job, collects a complete batch, evaluates the stopping rule, and saves a revised record. The HTTP handler submits work to a bounded worker pool. A 202 response acknowledges submission; the client must inspect the job to learn the outcome.
This is a runnable local architecture. Authentication between organizations, remote hardware adapters, distributed leases, and tenant accounting are proposed extensions, not hidden capabilities of the example. Adding them would require contracts for their own failure cases. In particular, a database transaction around a local state update cannot by itself make an external hardware operation happen exactly once.
The actual runner is shown with the assembled project in Build a Reproducible Workload Service. Its value is that a reader can follow a request through working code and verify which responsibilities are implemented.
Worked example: one score, two dispositions
The captured baseline finishes at 5,000 shots per basis with observed score 0.9561. Its interval is approximately [0.917177, 0.995023], and its half-width is 0.038923. The statistical criteria pass.
The invalid-provenance scenario deliberately generates the same measurement experiment and then removes the required model identifier. Its numerical history can therefore look just as convincing. Its final disposition is nevertheless invalid because the contract's provenance requirement fails.
That outcome is different from the degraded scenario, whose valid record has a sufficiently low upper bound to reject the quality claim. It is also different from the budget scenario, which produces a valid but inconclusive result. Combining these cases into a single Boolean success flag would discard the information needed to choose the next action.
Exercise and worked answer
Classify three records before deciding whether to use their estimates:
| Record | Execution and evidence |
|---|---|
| A | Completed; valid provenance; lower bound passes; width passes |
| B | Completed; missing model identifier; numerical gates pass |
| C | Completed; valid evidence; budget exhausted while bounds remain unresolved |
Worked answer: A is accepted. B is invalid; rerunning the arithmetic cannot reconstruct the missing provenance. C is inconclusive; its completed execution does not establish the claim. The next action for C may be a newly specified experiment with an adequate budget, while B requires resolving the evidence failure.
Run baseline, invalid, and budget in the lab and inspect both the execution status and disposition. When writing a client, carry those two fields through its result model. Keep the validation findings alongside them rather than converting every completed job into a usable answer. Reproducible Runs and Experiment Data explains how the underlying observations remain inspectable.