Formal Workload Specifications and Contract Testing

Quantum workloads fail at boundaries: problem to circuit, circuit to compiler, compiler to target, runtime to evidence, and evidence to claim. Informal intent is too weak for serious operation.

A workload contract makes assumptions executable.

Diagram loads as you read

Formal Workload Specifications and Contract Testing · Figure 1

View diagram source

flowchart LR
    Intent[Scientific or product intent] --> Spec[Workload specification]
    Spec --> Tests[Contract tests]
    Tests --> Compiler[Compiler]
    Tests --> Runtime[Runtime]
    Tests --> Evidence[Evidence pipeline]
    Evidence --> Claim[Bounded claim]

Specification layers

Layer	Questions answered
problem	What objective, Hamiltonian, oracle, sampler, or claim is intended?
semantic	What must remain invariant?
compilation	Which transformations are allowed?
target	What topology, gates, timing, or analog controls are required?
execution	What shots, batching, sessions, reservations, or mitigation are required?
evidence	What artifacts and statistical tests are required?
governance	Which data, provider, region, and retention policies apply?

Diagram loads as you read

Specification layers · Figure 2

View diagram source

flowchart TB
    Problem[Problem spec] --> Semantic[Semantic contract]
    Semantic --> Compilation[Compilation contract]
    Compilation --> Target[Target contract]
    Target --> Execution[Execution contract]
    Execution --> Evidence[Evidence contract]
    Evidence --> Governance[Governance contract]

Contract object

Diagram loads as you read

Contract object · Figure 3

View diagram source

classDiagram
    class WorkloadContract {
      workload_id
      version
      objective
      invariants
      allowed_transforms
      target_requirements
      execution_requirements
      evidence_requirements
      claim_boundary
      kill_criteria
    }
    class ContractTest {
      test_id
      layer
      fixture
      expected_property
      tolerance
      blocking
    }
    WorkloadContract --> ContractTest

OpenAPI can describe service interfaces in a machine-readable way, and TLA+ can model state machines and concurrent protocols. Quantum platforms can apply the same discipline to brokers, scheduling, evidence workflows, and rollback protocols. [R174] [R179]

Boundary tests

Diagram loads as you read

Boundary tests · Figure 4

View diagram source

flowchart LR
    T1[Problem-to-circuit] --> T2[Circuit-to-compiler]
    T2 --> T3[Compiler-to-target]
    T3 --> T4[Runtime]
    T4 --> T5[Evidence]
    T5 --> T6[Claim]

Boundary	Example test
problem to circuit	observable definition preserved
circuit to compiler	forbidden transformations rejected
compiler to target	native operations and topology satisfied
runtime	shots, sessions, and mitigation options honored
evidence	required metadata present
claim	result inside declared confidence boundary

Negative tests

A platform should be tested against unsafe ambiguity.

Diagram loads as you read

Negative tests · Figure 5

View diagram source

flowchart TB
    Invalid[Invalid workload] --> Validator
    Validator --> Rejected{Rejected?}
    Rejected -- yes --> Good[Contract test passes]
    Rejected -- no --> Bad[Unsafe ambiguity accepted]

Examples include missing evidence requirements, unsupported dynamic control, confidential data routed to an unapproved region, ambiguous measurement ordering, and unapproved compiler optimization.

Tolerance envelopes

Quantum contract tests often compare against envelopes rather than exact values.

Diagram loads as you read

Tolerance envelopes · Figure 6

View diagram source

flowchart LR
    Expected[Expected behavior] --> Envelope[Tolerance envelope]
    Observed[Observed behavior] --> Compare[Compare]
    Envelope --> Compare
    Compare --> Decision{Inside envelope?}

An envelope specifies metric, confidence level, sample budget, drift window, baseline, and decision threshold.

Release gates

Diagram loads as you read

Release gates · Figure 7

View diagram source

sequenceDiagram
    participant Change
    participant Suite
    participant Canary
    participant Release
    Change->>Suite: run contract tests
    Suite-->>Change: pass/fail by workload class
    Change->>Canary: execute representative workloads
    Canary-->>Release: evidence comparison
    Release-->>Change: approve, limit, or rollback

New compiler profiles, runtime modes, mitigation methods, and calibration pipelines should pass relevant workload contracts before production promotion.

Operating rule

A workload is production-grade only when its semantics, transformations, execution requirements, evidence obligations, and claim boundaries can be tested automatically.