Device Lifecycle, Manufacturing, and Characterization

A quantum platform does not begin at first user job. It begins when a device design becomes a fabrication run, a package, a control model, a calibration hypothesis, and eventually an operational backend. The platform’s job is to make this lifecycle measurable.

This chapter describes the device lifecycle as a production system.

21.1 Device lifecycle map

flowchart LR
    Design[Device design] --> Fabricate[Fabrication]
    Fabricate --> Package[Packaging]
    Package --> Bringup[Bring-up]
    Bringup --> Characterize[Characterization]
    Characterize --> Calibrate[Calibration]
    Calibrate --> Qualify[Qualification]
    Qualify --> Operate[User operation]
    Operate --> Learn[Field learning]
    Learn --> Design

Every arrow should produce artifacts. Without artifacts, the team cannot learn across generations.

21.2 Device identity

A QPU should have a durable identity independent of marketing names and backend aliases.

device_identity:
  device_id: string
  generation: string
  modality: superconducting|ion|neutral_atom|photonic|annealing|other
  fabrication_lot: string
  wafer_or_batch: string
  die_or_trap_id: string
  package_id: string
  install_site: string
  control_stack_version: string
  first_bringup_date: date
  decommission_date: date|null

flowchart TB
    DeviceID[Device ID] --> Fab[Fabrication records]
    DeviceID --> Package[Package records]
    DeviceID --> Calibration[Calibration history]
    DeviceID --> Benchmarks[Benchmark history]
    DeviceID --> Incidents[Incident history]
    DeviceID --> UserRuns[User experiment provenance]

The device identity is the join key for science, operations, and product reporting.

21.3 Characterization pipeline

Characterization answers: what did we actually build? Calibration answers: how should we drive it today? Benchmarking answers: what user-visible quality does it deliver?

flowchart TB
    RawDevice[Raw installed device] --> Smoke[Smoke tests]
    Smoke --> Single[Single-qubit characterization]
    Single --> Pair[Two-qubit / interaction characterization]
    Pair --> Readout[Readout characterization]
    Readout --> Crosstalk[Crosstalk and spectator analysis]
    Crosstalk --> Model[Device model]
    Model --> Compiler[Compiler target]
    Model --> Scheduler[Scheduler constraints]

Characterization should produce:

21.4 Yield is a systems metric

Yield is not just the fraction of fabricated devices that work. For operators, yield is the fraction of devices that can become useful backends within acceptable bring-up cost.

flowchart LR
    Fabricated[Fabricated devices] --> Packaged[Packaged]
    Packaged --> Installed[Installed]
    Installed --> Characterized[Characterized]
    Characterized --> Qualified[Qualified]
    Qualified --> Productive[Productive user backend]

Example lifecycle yield table:

A high fabrication yield can still produce a poor platform yield if packaging, bring-up, or calibration is unstable.

21.5 Qualification gates

A device should not become a user backend because it is exciting. It should become a user backend because it passes qualification gates.

flowchart TB
    Candidate[Candidate backend] --> Basic[Basic health gate]
    Basic --> Calibration[Calibration stability gate]
    Calibration --> Compiler[Compiler compatibility gate]
    Compiler --> Bench[Benchmark gate]
    Bench --> Load[Load and scheduling gate]
    Load --> Trust[Trust-report gate]
    Trust --> Release{Release to users?}

Example gates:

21.6 Versioned device models

The compiler and scheduler should not consume informal device descriptions. They should consume versioned device models.

device_model:
  device_id: qpu-example-001
  model_version: 2026.04.18.1
  valid_from: 2026-04-18T09:00:00Z
  topology:
    qubits: 156
    couplers: 224
  native_operations:
    - name: rz
      arity: 1
    - name: sx
      arity: 1
    - name: ecr
      arity: 2
  timing:
    dt: 2.22e-10
  quality_summary:
    median_1q_error: 0.0003
    median_2q_error: 0.003
    median_readout_error: 0.015

flowchart LR
    Characterization[Characterization] --> Model[Versioned device model]
    Calibration[Calibration] --> Model
    Model --> Compiler[Compiler target]
    Model --> Scheduler[Admission and scheduling]
    Model --> Trust[Trust reports]
    Model --> Resource[Resource estimates]

Qiskit’s Target object is an example of a compiler-facing abstraction that describes backend instructions, properties, and timing information so the compiler can produce device-compatible circuits [R45]. The broader platform lesson is not Qiskit-specific: the compiler should compile against declared machine constraints, not folklore.

21.7 Field learning loop

User workloads reveal device behavior that laboratory characterization may not. The platform should capture those signals without letting user experiments become uncontrolled characterization campaigns.

flowchart TB
    UserRuns[User runs] --> Telemetry[Execution telemetry]
    Telemetry --> Detect[Anomaly detection]
    Detect --> Triage{Platform issue?}
    Triage -- no --> UserReport[User-facing explanation]
    Triage -- yes --> Characterize[Targeted characterization]
    Characterize --> Calibrate[Calibration update]
    Calibrate --> Model[Device model update]
    Model --> Release[Release gate]

Field signals:

21.8 Decommissioning

Decommissioning is part of the lifecycle. A device may be retired because it fails, because a better one replaces it, or because its operating cost exceeds value.

flowchart TB
    Monitor[Monitor backend value] --> Decline{Quality or value declining?}
    Decline -- no --> Operate[Continue operation]
    Decline -- yes --> Review[Retirement review]
    Review --> Preserve[Preserve data and models]
    Preserve --> Notify[Notify users]
    Notify --> Retire[Retire backend]
    Retire --> Archive[Archive lifecycle record]

Retirement checklist:

• export final calibration and device models,
• freeze benchmark history,
• preserve experiment provenance for reproducibility,
• remove backend from scheduler target lists,
• update documentation and examples,
• migrate users to successor systems,
• record final lessons for the next design cycle.

21.9 Chapter rule

Treat every QPU as a product generation with a lifecycle. The goal is not to operate a heroic one-off machine. The goal is to improve every generation using evidence from the previous one.

References used in this chapter: [R45].