Utility Operating Contract Synthesis — Operating Quantum Computers

The operating contract is the shortest complete description of how a quantum platform behaves. It binds identity, workload specification, runtime mode, provider access, quotas, evidence, observability, retention, cost, support, change management, and customer promises. It is the artifact that lets the platform move from experimental capability to governed utility.

Diagram loads as you read

Utility Operating Contract Synthesis · Figure 1

View diagram source

flowchart TB
    Contract[Utility operating contract] --> Identity[Who may run]
    Contract --> Workload[What may run]
    Contract --> Runtime[How it runs]
    Contract --> Capacity[When and where it runs]
    Contract --> Evidence[What evidence is produced]
    Contract --> Data[How data is handled]
    Contract --> Cost[How cost is accounted]
    Contract --> Support[How failures are handled]

Contract sections

Section	Required decision
identity	workload identity, human owner, delegated authorization
workload	class, data classification, risk tier, algorithm family
runtime	API version, mode, target model, mitigation profile
capacity	provider, backend, quota, reservation, priority
evidence	schema, required artifacts, hash policy, retention
observability	trace, metric, log, and event obligations
security	policy decisions, secure build lineage, vulnerability posture
SLO	customer-facing and internal service objectives
cost	allocation, showback, chargeback, exception thresholds
change	release window, compatibility window, rollback trigger

Diagram loads as you read

Contract sections · Figure 2

View diagram source

classDiagram
    class OperatingContract {
      contract_id
      version
      owner
      effective_from
      effective_until
    }
    class RuntimeClause {
      api_version
      mode
      target_model
      mitigation_profile
    }
    class EvidenceClause {
      schema_version
      required_artifacts
      retention_class
    }
    class CapacityClause {
      provider
      backend
      quota
      reservation_policy
    }
    OperatingContract --> RuntimeClause
    OperatingContract --> EvidenceClause
    OperatingContract --> CapacityClause

Contract lifecycle

Diagram loads as you read

Contract lifecycle · Figure 3

View diagram source

stateDiagram-v2
    [*] --> Draft
    Draft --> Reviewed
    Reviewed --> Active
    Active --> Amended
    Amended --> Active
    Active --> Superseded
    Active --> Suspended
    Suspended --> Active
    Superseded --> Archived

Contract negotiation

The contract should be negotiated by operators, researchers, security, FinOps, product, and customer-facing teams. A quantum platform fails when any one of those groups has an implicit veto that is not encoded in the operating contract.

Diagram loads as you read

Contract negotiation · Figure 4

View diagram source

flowchart LR
    Research[Research team] --> Contract[Contract draft]
    Security[Security] --> Contract
    Ops[Quantum ops] --> Contract
    FinOps[FinOps] --> Contract
    Product[Product] --> Contract
    Customer[Customer or sponsor] --> Contract
    Contract --> Decision{Approved?}
    Decision -- yes --> Active[Active contract]
    Decision -- no --> Revise[Revise scope]

Runtime and capacity linkage

Runtime choices and capacity choices cannot be separated. A session is not merely an API option; it changes scheduling, queue exposure, fairness, and cost. A reservation is not merely procurement; it changes workload packing, rehearsal, and utilization responsibilities [R246][R247].

Diagram loads as you read

Runtime and capacity linkage · Figure 5

View diagram source

flowchart TB
    Mode[Runtime mode] --> Latency[Latency behavior]
    Mode --> Fairness[Fairness policy]
    Mode --> Cost[Cost model]
    Mode --> Evidence[Evidence obligations]
    Reservation[Reservation policy] --> Latency
    Reservation --> Cost
    Quota[Quota policy] --> Fairness
    Quota --> Cost

Assurance closure

A contract is closed only when every promise points to a measurement or evidence artifact.

Diagram loads as you read

Assurance closure · Figure 6

View diagram source

flowchart LR
    Promise[Contract promise] --> SLI[Indicator or control]
    SLI --> Query[Measurement query]
    Query --> Source[Evidence source]
    Source --> Owner[Owner]
    Owner --> Review[Review cadence]

Minimal viable operating contract

Illustrative listing · yaml

contract_id: qoc-utility-001
version: 1.0.0
owner: quantum-platform
runtime:
  api_version: 2026-04
  supported_modes: [job, batch, session, reservation]
capacity:
  quota_policy: project-and-provider
  reservation_policy: approval-required
evidence:
  schema_version: 4
  required_artifacts:
    - workload_spec
    - compiled_circuit
    - backend_snapshot
    - calibration_reference
    - result_hash
observability:
  trace_required: true
  telemetry_profile: quantum-otel-v1
security:
  workload_identity_required: true
  plugin_policy: allowlisted
change:
  compatibility_window_days: 30
  rollback_trigger: evidence_regression

Operating rule

The contract is the platform. Everything not written into it will be handled by heroics, memory, or assumption. That is not an operating model.