Operating the Stack

Running a quantum computer is closer to operating a scientific instrument than operating a conventional server. The machine must be calibrated, controlled, scheduled, measured, diagnosed, and continuously characterized.

The central operational fact is drift. The device you calibrated earlier is not exactly the device you have now.

4.1 The operating stack

A production quantum platform needs at least four control loops:

1. Calibration loop — maintain gate, readout, and timing quality.
2. Compilation loop — map workloads to the current machine.
3. Execution loop — run shots and collect measurements.
4. Learning loop — update models based on observed performance.

flowchart TB
    subgraph Users
        Workloads[Workload submissions]
    end

    subgraph Platform
        Admission[Admission control]
        Compiler[Hardware-aware compiler]
        Scheduler[Scheduler]
        Metadata[Provenance store]
        Telemetry[Telemetry pipeline]
    end

    subgraph Control
        Calibrator[Calibration services]
        Pulse[Pulse/control generation]
        Readout[Readout processing]
    end

    subgraph Device
        QPU[Quantum processor]
    end

    Workloads --> Admission --> Compiler --> Scheduler --> Pulse --> QPU --> Readout --> Telemetry
    Calibrator --> Compiler
    Calibrator --> Pulse
    Telemetry --> Calibrator
    Telemetry --> Metadata
    Compiler --> Metadata
    Scheduler --> Metadata

The platform is healthy when these loops cooperate. It is unhealthy when they operate as disconnected scripts.

4.2 Calibration as production infrastructure

Calibration is not a one-time setup step. It is a production workload. It competes with user jobs for machine time, and it determines whether those jobs are meaningful.

A calibration system should answer:

• Which qubits and couplers are currently usable?
• Which gate parameters are valid?
• Which readout models are valid?
• Which regions of the device should be avoided?
• How fast are relevant metrics drifting?
• What must be recalibrated before accepting a workload?

sequenceDiagram
    participant T as Telemetry monitor
    participant C as Calibration service
    participant S as Scheduler
    participant Q as QPU
    participant DB as Calibration database

    T->>C: drift alert or scheduled check
    C->>S: request calibration slot
    S->>Q: run calibration circuits
    Q->>C: return measurements
    C->>C: fit parameters and validate
    C->>DB: publish new calibration snapshot
    DB-->>S: update backend availability

Calibration should publish versioned snapshots. A workload should reference the snapshot used for compilation and execution.

4.3 Admission control

Not every submitted circuit should run. Admission control protects scarce hardware time and protects users from paying for meaningless results.

Admission control can reject, defer, or rewrite workloads based on:

Admission control is not bureaucracy. It is a quality gate.

4.4 Scheduling quantum work

Quantum scheduling differs from classical scheduling because the resource is time-varying and partially consumed by maintenance. A backend may be unavailable because it is calibrating, warming, cooling, undergoing diagnostics, or reserved for characterization.

gantt
    title Example QPU Daily Schedule
    dateFormat  HH:mm
    axisFormat  %H:%M

    section Maintenance
    Morning calibration      :done, cal1, 08:00, 45m
    Drift characterization   :diag1, 12:00, 20m
    Evening calibration      :cal2, 18:00, 45m

    section User jobs
    Chemistry VQE batch      :job1, 09:00, 90m
    Benchmark circuits       :job2, 10:45, 60m
    QAOA parameter sweep     :job3, 13:00, 120m
    Reserved enterprise slot :job4, 15:30, 90m

A scheduler should understand calibration windows. A job compiled against a snapshot may no longer be valid after enough drift.

4.5 Telemetry design

Quantum telemetry has two audiences: the machine operator and the computational user.

Operators need low-level signals: calibration residuals, readout trends, gate errors, environmental measurements, failed diagnostics, and utilization.

Users need workload-level signals: compiled depth, estimated error exposure, shot count, raw counts, mitigation settings, backend version, and confidence intervals.

flowchart LR
    QPU[QPU and controls] --> Raw[Raw telemetry]
    Raw --> Ops[Operator dashboards]
    Raw --> Quality[Quality models]
    Quality --> Compiler[Compiler hints]
    Quality --> Scheduler[Scheduler scoring]
    Raw --> UserMeta[User-visible metadata]
    UserMeta --> Reports[Result reports]

The platform should not expose every low-level metric to every user, but it should expose enough for scientific and engineering auditability.

4.6 Incident response

Quantum incident response is not limited to crashes. A more common incident is silent quality degradation.

Examples:

• A subset of qubits begins producing abnormal readout distributions.
• A calibration routine succeeds numerically but produces worse workload outcomes.
• Queue delay causes jobs to execute outside the intended calibration window.
• A compiler update increases two-qubit gate count for common workloads.
• A mitigation method reduces variance but introduces bias.

An incident runbook should include:

1. freeze affected calibration snapshot,
2. stop admitting sensitive workloads,
3. identify impacted jobs,
4. rerun diagnostics,
5. compare against previous known-good calibration,
6. notify users if published results may be affected,
7. record root cause and guardrail changes.

4.7 Reproducibility levels

Quantum reproducibility has levels:

Most platforms can aim for source and compile reproducibility immediately. Execution reproducibility is harder because physical conditions change. Statistical and scientific reproducibility require careful experimental design.

4.8 Operator checklist

For platform operations:

• Maintain versioned calibration snapshots.
• Bind jobs to calibration and compiler metadata.
• Score backend suitability before execution.
• Track drift and calibration validity windows.
• Separate operator telemetry from user provenance metadata.
• Alert on quality degradation, not only system failure.
• Keep known-good compiler and calibration baselines.
• Make incident impact analysis possible from stored metadata.

4.9 Chapter summary

Operating a quantum computer means operating multiple feedback loops under drift. Calibration, compilation, scheduling, telemetry, and incident response are part of the computation. A platform that treats quantum execution as a stateless API call will produce results that are hard to trust and hard to improve.