Runtime Contracts and Quantum OS Abstractions

Quantum platforms need a stricter runtime contract than classical batch platforms because the executable unit is not just a program. It is a negotiated agreement between a compiler, a control system, a calibration state, an error model, and a result consumer.

A useful runtime abstraction answers six questions before execution begins:

1. What semantic guarantees does the program require?
2. What timing and control-flow features does the target support?
3. What calibration state is bound to the run?
4. What mitigation, suppression, or correction policy is active?
5. What result schema and uncertainty contract will be returned?
6. What provenance is sufficient to reproduce or reject the result?

IBM's primitive model, OpenQASM 3 control-flow features, QIR profiles, and low-latency logical-QPU APIs point toward a runtime ecosystem in which the useful abstraction is no longer “submit this circuit.” It is “execute this contract under these physical and statistical constraints.” [R95] [R96] [R97] [R98]

51.1 The runtime is the operating boundary

The runtime sits between intent and physics.

flowchart LR
    Intent[Application intent] --> IR[Program representation]
    IR --> Compiler[Compiler and mapper]
    Compiler --> Runtime[Runtime contract]
    Runtime --> Control[Control system]
    Control --> QPU[QPU execution]
    QPU --> Result[Statistical result]
    Result --> Consumer[Application consumer]

The runtime is where abstract algorithmic intent becomes a constrained hardware request. It should not hide uncertainty. It should expose enough detail for an operator to determine whether a result is usable.

51.2 Contract fields

A runtime contract should be explicit. Do not rely on defaults for any production-significant workflow.

runtime_contract:
  workload_id: qchem-fe2s2-active-space-v4
  semantic_profile: estimator.expectation_value
  program_ir:
    format: qasm3 | qir | native_circuit | pulse_package
    version: pinned
  target:
    provider: ibm | quantinuum | ionq | rigetti | braket | azure | local
    backend: name-or-arn
    required_features:
      - mid_circuit_measurement
      - conditional_branching
      - reset
  compilation:
    target_snapshot_id: backend-target-2026-04-19T09:00Z
    optimization_goal: minimize_expected_error
    max_depth: 320
    max_two_qubit_count: 480
  execution:
    shots: 20000
    seed_policy: recorded
    reservation_or_session: optional
  resilience:
    suppression: dynamical_decoupling | twirling | none
    mitigation: zne | pec | measurement_mitigation | none
  evidence:
    artifacts_required:
      - compiled_circuit
      - calibration_snapshot
      - backend_properties
      - mitigation_metadata
      - raw_counts_or_expectations

51.3 Contract negotiation

Runtime negotiation is not a formality. A program may be valid QASM or QIR and still be invalid for a target profile.

sequenceDiagram
    participant A as Application
    participant C as Compiler
    participant R as Runtime
    participant T as Target profile
    participant O as Operator policy

    A->>C: Submit intent + constraints
    C->>T: Query operations, timing, control support
    T-->>C: Supported profile + limits
    C->>R: Candidate executable + resource estimate
    R->>O: Check policy, budget, evidence requirements
    O-->>R: Admit, revise, or reject
    R-->>A: Executable contract or reasoned refusal

A mature platform returns a structured refusal when a job is not admissible. Refusals are useful data. They show where tooling, hardware, or expectations are mismatched.

51.4 Profiles, not promises

The word “supports” is too vague for quantum runtime features. A target may support mid-circuit measurement but only with constraints on latency, register use, branching structure, shot count, or device family. Azure Quantum target profiles distinguish support levels such as base and adaptive profiles; QIR also uses profile concepts to separate portable structure from target-specific capability. [R96]

flowchart TB
    Feature[Requested feature] --> Profile{Target profile supports it?}
    Profile -- no --> Reject[Reject or rewrite]
    Profile -- yes --> Limits[Check limits]
    Limits --> Timing{Timing acceptable?}
    Timing -- no --> Rewrite[Rewrite or target another backend]
    Timing -- yes --> Contract[Bind into runtime contract]

Treat target features as versioned capabilities, not marketing labels.

51.5 Quantum OS layers

A quantum operating system is not one monolithic kernel. It is a layered control and scheduling stack.

flowchart TB
    API[Application API] --> Runtime[Quantum runtime]
    Runtime --> IR[IR and profile layer]
    IR --> Compiler[Compilation and layout]
    Compiler --> Scheduler[Job/session scheduler]
    Scheduler --> Exec[Execution manager]
    Exec --> Control[Classical control firmware]
    Control --> Pulse[Pulse and waveform layer]
    Pulse --> Device[Physical device]
    Device --> Telemetry[Telemetry and results]
    Telemetry --> Runtime

Each layer should declare inputs, outputs, invariants, and evidence artifacts.

51.6 Real-time boundary

Fault-tolerant systems move some runtime logic into the microsecond loop. NVIDIA's cudaq-realtime and NVQLink materials describe GPU/controller integration for tight feedback loops in calibration and QEC workflows. That changes where software responsibility lives: some decisions must run close to the controller, not in a remote cloud workflow. [R97]

flowchart LR
    Slow[Slow control plane\nseconds-minutes] --> Plan[Plan experiments]
    Plan --> Queue[Queue jobs]
    Queue --> Fast[Fast feedback plane\nmicroseconds-milliseconds]
    Fast --> Decode[Decode syndrome]
    Fast --> Adapt[Adapt control]
    Decode --> Logical[Logical operation]
    Adapt --> Logical
    Logical --> Slow

Do not design a logical-qubit service around a batch-only mental model.

51.7 Runtime SLOs

A runtime service should expose SLOs that match quantum work.

flowchart LR
    SLO[Runtime SLOs] --> Admission[Admission]
    SLO --> Freshness[Target freshness]
    SLO --> Evidence[Evidence completeness]
    SLO --> Precision[Uncertainty compliance]
    SLO --> Repro[Mitigation reproducibility]

51.8 Failure modes

Runtime failures are usually cross-layer failures.

flowchart TD
    Failure[Runtime failure] --> Semantic[Semantic mismatch]
    Failure --> Compilation[Compiler target mismatch]
    Failure --> Calibration[Calibration stale]
    Failure --> Scheduling[Reservation/session expired]
    Failure --> Mitigation[Mitigation metadata incomplete]
    Failure --> Result[Result schema ambiguous]

The fix is not more abstraction. The fix is stricter contracts and better evidence.

51.9 Operator checklist

Before treating a runtime as production-ready, verify:

• every executable binds to a target profile and target snapshot
• every mitigation setting is explicitly recorded
• every dynamic-control feature has a tested fallback path
• every result includes uncertainty and provenance
• every admission refusal is machine-readable
• every high-value workflow has a simulator or emulator preflight path

stateDiagram-v2
    [*] --> DraftContract
    DraftContract --> Preflight
    Preflight --> Admit: valid
    Preflight --> Revise: invalid
    Revise --> DraftContract
    Admit --> Execute
    Execute --> ValidateEvidence
    ValidateEvidence --> Publish: complete
    ValidateEvidence --> Quarantine: incomplete

The runtime is the operating contract. In quantum computing, the contract is the product.