The Operating Playbook — Operating Quantum Computers

This chapter compresses the book into a practical operating playbook. It is not a replacement for the earlier chapters. It is the checklist a platform team can use when deciding what to build next.

A quantum operating system is a set of loops:

the execution loop,
the calibration loop,
the compiler loop,
the scheduling loop,
the data and trust loop,
the cost loop,
the security loop,
the learning loop.

When those loops are disconnected, the platform decays. When they reinforce each other, the platform improves.

18.1 The full operating loop

Diagram loads as you read

18.1 The full operating loop · Figure 1

View diagram source

flowchart TB
    Intent[Problem intent] --> Encode[Encode]
    Encode --> Validate[Simulate and validate]
    Validate --> Compile[Compile]
    Compile --> Admit[Admission control]
    Admit --> Schedule[Schedule]
    Schedule --> Execute[Execute]
    Execute --> Measure[Measure]
    Measure --> Analyze[Analyze]
    Analyze --> Report[Trust report]
    Report --> Learn[Learn]
    Learn --> Optimize[Optimize platform]
    Optimize --> Compile
    Optimize --> Admit
    Optimize --> Schedule
    Optimize --> Validate

The loop has two products:

a user-facing result with uncertainty and provenance,
platform telemetry that improves the next run.

18.2 Minimum viable quantum platform

A credible minimum platform is not a pile of SDK examples. It has explicit services.

Diagram loads as you read

18.2 Minimum viable quantum platform · Figure 2

View diagram source

flowchart TB
    Client[Client / notebook / app] --> Gateway[Execution gateway]
    Gateway --> Policy[Policy and quota service]
    Gateway --> Experiment[Experiment service]
    Experiment --> Compiler[Compiler service]
    Experiment --> Scheduler[Scheduler adapter]
    Scheduler --> Provider[Provider runtime]
    Provider --> Store[Artifact store]
    Experiment --> Store
    Store --> Report[Trust report generator]
    Gateway --> Telemetry[Telemetry pipeline]

Minimum capabilities:

Capability	Minimum acceptable version
identity	named users or service identities, no shared tokens
project isolation	per-project budgets and result storage
execution gateway	one controlled path to QPU submission
simulator gate	automatic pre-QPU validation for serious runs
provenance	experiment bundle for every promoted run
telemetry	trace ID across submit, compile, schedule, execute, analyze
trust report	result, uncertainty, calibration context, compiler context
cost control	budget check before execution

Anything less may be fine for a lab. It is not a production platform.

18.3 Design principles

Diagram loads as you read

18.3 Design principles · Figure 3

View diagram source

mindmap
  root((Quantum operating principles))
    Evidence over output
    Provenance by default
    Policy before execution
    Simulation before QPU
    Quality before utilization
    Uncertainty before precision
    Rejection with repair path
    Continuous calibration
    Explicit ownership

Principles in operational form:

Principle	Operational behavior
evidence over output	every result includes uncertainty and provenance
provenance by default	run metadata is captured automatically
policy before execution	unsafe or unaffordable jobs fail early
simulation before QPU	obvious errors are caught cheaply
quality before utilization	capacity is measured by useful results
uncertainty before precision	report confidence, not fake exactness
rejection with repair path	users learn how to fix workloads
continuous calibration	device state feeds compiler and scheduler
explicit ownership	incidents and releases have accountable owners

18.4 The first 90 days

Diagram loads as you read

18.4 The first 90 days · Figure 4

View diagram source

gantt
    title First 90 days of a quantum platform program
    dateFormat  YYYY-MM-DD
    section Foundation
    Inventory workloads and users      :a1, 2026-04-18, 14d
    Define project and access model    :a2, after a1, 14d
    section Execution
    Build execution gateway            :b1, 2026-05-01, 30d
    Add simulator validation           :b2, after b1, 21d
    section Evidence
    Define experiment bundle schema    :c1, 2026-05-01, 21d
    Generate trust reports             :c2, after c1, 30d
    section Operations
    Add telemetry and runbooks         :d1, 2026-05-15, 30d
    Start weekly quality review        :d2, 2026-05-22, 45d

First 90-day outcomes:

one sanctioned execution path,
one experiment bundle format,
one trust report format,
one project access model,
one benchmark suite,
one cost dashboard,
one incident process,
one weekly quality review.

Do not attempt to solve every algorithmic problem first. Build the operating rails.

18.5 Build sequence

Diagram loads as you read

18.5 Build sequence · Figure 5

View diagram source

flowchart LR
    Step1[1. Access and project model] --> Step2[2. Execution gateway]
    Step2 --> Step3[3. Experiment bundle]
    Step3 --> Step4[4. Simulator and validation gates]
    Step4 --> Step5[5. Telemetry and trust reports]
    Step5 --> Step6[6. Scheduling and cost controls]
    Step6 --> Step7[7. Calibration-aware optimization]
    Step7 --> Step8[8. Fault-tolerant planning]

Recommended sequencing:

Stage	Why first
access and project model	prevents chaos before usage grows
execution gateway	creates one place to enforce policy
experiment bundle	captures evidence before you need it
simulator gates	reduces QPU waste immediately
telemetry and trust reports	makes quality visible
scheduling and cost controls	handles growth and scarcity
calibration-aware optimization	improves useful capacity
fault-tolerant planning	guides long-term architecture

Teams often start with advanced algorithms. That is fine for research, but the platform should start with evidence and control.

18.6 Workload review template

Illustrative listing · yaml

workload_review:
  project: string
  owner: string
  problem_class: string
  target_result: string
  quantum_reason:
    why_qpu_needed: string
    simulator_baseline: string
  circuit_profile:
    qubits: int
    depth: int
    two_qubit_ops: int
    measurements: int
  execution_plan:
    target: string
    shots_or_precision: string
    batching: string
    reservation_required: bool
  risk:
    expected_noise_sensitivity: string
    calibration_dependency: string
    result_use: exploratory|internal|published|production
  evidence:
    source_commit: string
    validation_results: string
    trust_report_required: bool

A workload review should answer one question: is this a good use of scarce quantum capacity?

18.7 Result trust template

Diagram loads as you read

18.7 Result trust template · Figure 6

View diagram source

flowchart TB
    Result[Trust report] --> Summary[Summary]
    Result --> Provenance[Provenance]
    Result --> Hardware[Hardware context]
    Result --> Compiler[Compiler context]
    Result --> Statistics[Statistics]
    Result --> Limitations[Limitations]
    Result --> Decision[Use / do not use]

Required sections:

Section	Content
summary	result, confidence interval, decision
provenance	experiment ID, source hash, artifact hashes
hardware context	backend, qubit mapping, calibration snapshot
compiler context	compiler version, options, target profile
statistics	shots, variance, mitigation, uncertainty
benchmarks	relevant canaries and historical context
limitations	known caveats and invalidation triggers
decision	recommended use and owner approval

Trust reports are the book’s central operating artifact.

18.8 When to say no

Quantum teams need a professional way to say no.

Diagram loads as you read

18.8 When to say no · Figure 7

View diagram source

flowchart TD
    Request[QPU request] --> Reason{Why no?}
    Reason --> Broken[Workload invalid]
    Reason --> TooExpensive[Cost too high]
    Reason --> LowSignal[Expected signal too low]
    Reason --> Unsafe[Unsafe target behavior]
    Reason --> NoProvenance[Missing provenance]
    Broken --> Repair[Offer repair path]
    TooExpensive --> Repair
    LowSignal --> Repair
    Unsafe --> Repair
    NoProvenance --> Repair

Good rejection language:

“This circuit exceeds the depth limit for the requested target. Try this reduced ansatz or simulator gate.”
“The requested precision is unlikely under the current calibration. Wait for recalibration or use a different target.”
“This job needs a project budget owner before submission.”
“This result cannot be promoted because the source commit and mitigation profile are missing.”

Bad rejection language:

“Not approved.”
“Too expensive.”
“Device unavailable.”
“Ask the quantum team.”

A no with a repair path improves the platform.

18.9 The north-star metric

The north-star metric should not be number of quantum jobs. It should not be shots executed. It should not be raw QPU utilization.

A better metric:

Illustrative listing · text

trusted_result_rate = promoted_results_with_complete_evidence / scarce_quantum_capacity_used

This can be adapted per organization, but the direction is correct: maximize trusted evidence per unit of scarce capacity.

Diagram loads as you read

18.9 The north-star metric · Figure 8

View diagram source

flowchart LR
    Capacity[Scarce capacity] --> Runs[Runs]
    Runs --> Evidence[Evidence packages]
    Evidence --> Promoted[Promoted trusted results]
    Promoted --> Metric[Trusted result rate]
    Metric --> Improve[Improve platform]
    Improve --> Capacity

The platform exists to produce trusted results, not merely to consume quantum hardware.

18.10 Closing frame

The practical future of quantum computing will be built by teams that treat quantum computers as operational systems. They will not wait for perfect hardware. They will build the loops that make imperfect hardware useful, measurable, governable, and improvable.

That is the work of operating quantum computers.