Commissioning New Quantum Systems

Commissioning is the transition from assembled hardware to operational computational instrument. A device is not commissioned when the fridge is cold or the trap is stable. It is commissioned when the platform can repeatedly accept workloads, produce traceable results, expose health signals, and recover from ordinary disturbances.

For a systems organization, commissioning is not a ceremony. It is a controlled release.

43.1 Commissioning as release management

A new quantum processor, upgraded control stack, new trap geometry, new cryogenic module, or new provider target should pass through staged release gates. Each gate narrows uncertainty.

flowchart LR
    Design[Design intent] --> Install[Physical install]
    Install --> Bringup[Subsystem bring-up]
    Bringup --> Characterize[Characterization]
    Characterize --> Calibrate[Calibration]
    Calibrate --> Validate[Validation workloads]
    Validate --> Limited[Limited availability]
    Limited --> General[General availability]

The mistake is to move directly from Calibrate to General availability. Calibration only proves that selected controls can be tuned under known conditions. Availability requires repeatability, monitoring, user contracts, and fallback behavior.

IBM’s processor documentation distinguishes processor families and revisions, and Quantinuum’s H2 operational documentation exposes how architecture affects scheduling and transport. Those details matter because commissioning criteria must match the modality rather than pretend every QPU has the same topology or control semantics. [R79] [R80]

43.2 Commissioning scope

Commissioning should cover the full stack:

flowchart TB
    Commission[Commissioning program] --> Facility[Facility readiness]
    Commission --> Device[Device readiness]
    Commission --> Control[Control readiness]
    Commission --> Calibration[Calibration readiness]
    Commission --> Compiler[Compiler readiness]
    Commission --> Scheduler[Scheduler readiness]
    Commission --> Data[Data readiness]
    Commission --> Support[Support readiness]

A commissioning plan that tests only quantum benchmarks will miss failures in access control, cost accounting, queue behavior, data lineage, and user support.

43.3 Gate design

Each gate should have measurable entry criteria, exit criteria, and rollback criteria.

commissioning_gate:
  gate_id: string
  owner: string
  entry_criteria:
    - prerequisite completed
    - telemetry available
    - rollback path tested
  tests:
    - name: string
      threshold: string
      sample_size: string
  exit_criteria:
    - metric within bound
    - artifact archived
    - reviewer approval captured
  rollback_criteria:
    - metric breach
    - data loss
    - unsafe operating state

stateDiagram-v2
    [*] --> Draft
    Draft --> Ready: entry criteria met
    Ready --> Running: execute tests
    Running --> Passed: thresholds met
    Running --> Failed: breach
    Failed --> Remediate
    Remediate --> Ready
    Passed --> Released
    Released --> Monitor
    Monitor --> Rollback: regression detected
    Rollback --> Remediate

A gate without rollback criteria is not a gate. It is a wish.

43.4 Bring-up experiments

Bring-up experiments are not user workloads. They are diagnostic probes. Their purpose is to expose whether the device, control stack, and analysis pipeline are consistent with the target model.

Typical bring-up families include:

Historical Qiskit Experiments releases documented pulse-calibration experiments and schedule and parameter management. That subsystem was removed following the removal of Qiskit Pulse in Qiskit 2.0; it should be distinguished from the project’s current characterization and verification features. Commissioning tests must use the target platform’s currently supported control interface. [R84] [R85]

flowchart LR
    Probe[Diagnostic probe] --> Extract[Extract parameter]
    Extract --> Store[Store calibration artifact]
    Store --> Bind[Bind to target model]
    Bind --> Validate[Validate with benchmark]
    Validate --> Decision{Accept?}
    Decision -- no --> Retune[Retune or repair]
    Retune --> Probe
    Decision -- yes --> Promote[Promote to release candidate]

43.5 Commissioning data room

A serious commissioning program maintains a data room. This is not a slide deck. It is a structured evidence repository.

flowchart TB
    DataRoom[Commissioning data room] --> Design[Design intent]
    DataRoom --> Config[Configuration snapshots]
    DataRoom --> Cal[Calibration history]
    DataRoom --> Bench[Benchmark records]
    DataRoom --> Incidents[Bring-up incidents]
    DataRoom --> Waivers[Waivers and exceptions]
    DataRoom --> Release[Release decision]

The data room should answer five questions:

1. What system did we intend to build?
2. What system did we actually assemble?
3. What does it do reliably?
4. What does it fail to do?
5. Who approved the release and under what limitations?

43.6 Limited availability

Limited availability is the safest way to learn from real users without pretending the platform is mature.

sequenceDiagram
    participant User as Approved user
    participant Portal as Platform portal
    participant Triage as Admission review
    participant QPU as New QPU
    participant Ops as Operations
    User->>Portal: submit candidate workload
    Portal->>Triage: attach workload metadata
    Triage->>Ops: request readiness check
    Ops-->>Triage: approve window and constraints
    Triage->>QPU: schedule workload
    QPU-->>Portal: result plus provenance
    Portal-->>User: return qualified result

Limited availability should expose explicit restrictions:

• supported circuit families,
• maximum depth or duration,
• supported dynamic features,
• job volume limits,
• expected queue behavior,
• data-retention terms,
• known device limitations,
• escalation process.

43.7 Commissioning anti-patterns

flowchart TD
    Anti[Commissioning anti-pattern] --> Count[Qubit-count marketing]
    Anti --> Bench[Benchmark-only evidence]
    Anti --> Hero[Heroic specialist workflow]
    Anti --> Waiver[Untracked waivers]
    Anti --> Rollback[No rollback path]
    Count --> Bad[False confidence]
    Bench --> Bad
    Hero --> Bad
    Waiver --> Bad
    Rollback --> Bad

43.8 Operating rule

A quantum system is commissioned when the organization can state:

This is the system, these are its validated operating envelopes, these are the workloads we will accept, these are the artifacts we preserve, these are the failure modes we know, and this is how we roll back.

Anything less is still bring-up.