Operating Model and Maturity

A quantum platform is not operated by physicists alone, and it is not operated by software engineers alone. It requires a blended organization: device physics, control engineering, compiler engineering, platform engineering, data engineering, security, SRE, and domain science.

The operating model determines whether the platform learns. Without clear ownership, every failure becomes a meeting. With clear ownership, every failure becomes telemetry, a test, or a policy improvement.

17.1 Team topology

flowchart TB
    Platform[Quantum platform organization] --> Device[Device physics and hardware]
    Platform --> Control[Control systems]
    Platform --> Compiler[Compiler and runtime]
    Platform --> Infra[Platform infrastructure]
    Platform --> Data[Experiment data]
    Platform --> SRE[SRE and operations]
    Platform --> Security[Security and governance]
    Platform --> Domain[Application/domain teams]

Each team owns a different abstraction, but the user experiences one platform.

The interfaces between teams should be artifacts, not meetings.

17.2 Ownership map

flowchart LR
    Workload[Workload] --> DomainOwner[Domain owner]
    Compile[Compilation] --> CompilerOwner[Compiler owner]
    Cal[Calibration] --> DeviceOwner[Device owner]
    Queue[Scheduling] --> PlatformOwner[Platform owner]
    Result[Result trust] --> Joint[Domain + platform review]
    Incident[Incident] --> IncidentCommander[Incident commander]

Ambiguity to eliminate:

Shared consultation is healthy. Shared accountability without a final owner is not.

17.3 Release management

Quantum platforms release more than software. They release compilers, calibrations, target profiles, mitigation methods, policy changes, and sometimes hardware capability changes.

flowchart TD
    Change[Change proposal] --> Classify[Classify change]
    Classify --> Test[Test suite]
    Test --> Canary[Canary workloads]
    Canary --> Compare[Compare against baseline]
    Compare --> Approve{Approve release?}
    Approve -- no --> Rollback[Reject or revise]
    Approve -- yes --> Deploy[Deploy]
    Deploy --> Monitor[Monitor quality]
    Monitor --> RollbackDecision{Regression?}
    RollbackDecision -- yes --> Rollback
    RollbackDecision -- no --> Close[Close release]

Release classes:

Every release should say which result classes may be affected.

17.4 Change advisory without bureaucracy

The goal is not a slow review board. The goal is a small set of automatic gates plus human review for high-risk changes.

flowchart LR
    Change[Change] --> Risk{Risk level}
    Risk -- low --> Auto[Automated tests and deploy]
    Risk -- medium --> Reviewer[One accountable reviewer]
    Risk -- high --> CAB[Cross-functional review]
    Auto --> Release[Release]
    Reviewer --> Release
    CAB --> Release

High-risk examples:

• changes to measurement mapping,
• new mitigation default,
• pulse-level access policy changes,
• compiler passes that alter circuit layout materially,
• calibration procedures that change device operating point,
• scheduler policy changes during critical project windows.

The review should be proportional to potential result impact.

17.5 Maturity model

Quantum operating maturity can be described in five levels.

flowchart TB
    L1[L1: Lab scripts] --> L2[L2: Shared service]
    L2 --> L3[L3: Governed platform]
    L3 --> L4[L4: Reliable product]
    L4 --> L5[L5: Continuously optimized system]

Most teams should aim for L3 before claiming production readiness. L4 is where users can depend on the platform. L5 is where the platform improves itself without losing control.

17.6 Capability matrix

flowchart LR
    Capabilities[Capabilities] --> Access[Access control]
    Capabilities --> Provenance[Provenance]
    Capabilities --> Scheduling[Scheduling]
    Capabilities --> Calibration[Calibration]
    Capabilities --> Observability[Observability]
    Capabilities --> Cost[Cost control]
    Capabilities --> Security[Security]
    Capabilities --> ResultTrust[Result trust]

A practical assessment:

This matrix is more useful than a generic roadmap because it ties maturity to operational behaviors.

17.7 Training and certification

Quantum operations require internal certification. Not every user should have the same execution rights.

flowchart TD
    User[User] --> Basic[Basic platform training]
    Basic --> Simulator[Simulator access]
    Simulator --> QPUIntro[QPU introductory access]
    QPUIntro --> Advanced[Advanced workload certification]
    Advanced --> Restricted[Restricted capabilities]

Access tiers:

Training should include cost, uncertainty, result interpretation, security, and incident reporting. A user who cannot explain confidence intervals should not publish QPU-derived claims without review.

17.8 Decision forums

A quantum platform needs a few recurring forums, not endless sync meetings.

flowchart TB
    Forums[Operating forums] --> Daily[Daily operational review]
    Forums --> Weekly[Weekly quality and capacity review]
    Forums --> Release[Release review]
    Forums --> Incident[Incident postmortem]
    Forums --> Research[Research roadmap review]

Each forum should produce decisions or be deleted.

17.9 Build versus buy

Quantum organizations must decide what to build internally and what to rely on from vendors.

flowchart LR
    Need[Capability need] --> Strategic{Strategic differentiator?}
    Strategic -- yes --> Build[Build or deeply customize]
    Strategic -- no --> Vendor{Vendor adequate?}
    Vendor -- yes --> Buy[Use vendor/platform]
    Vendor -- no --> Partner[Partner or build minimal bridge]

Usually worth building:

• experiment data model,
• trust-report workflow,
• domain-specific application layer,
• internal governance and cost controls,
• reproducibility tooling,
• benchmark suites tied to your workloads.

Usually not worth rebuilding early:

• generic quantum SDKs,
• cloud identity systems,
• commodity observability backends,
• basic object storage,
• general-purpose workflow engines.

The platform should integrate aggressively and differentiate selectively.

17.10 Roadmap cadence

Quantum roadmaps must separate research uncertainty from platform commitments.

flowchart TD
    Vision[Long-term vision] --> Annual[Annual architecture bets]
    Annual --> Quarterly[Quarterly platform roadmap]
    Quarterly --> Monthly[Monthly reliability and quality targets]
    Monthly --> Weekly[Weekly operational improvements]

Good roadmap items:

• “reduce median compile-to-result time for approved estimator workloads by 30%,”
• “increase promoted-result provenance completeness from 75% to 95%,”
• “detect readout regressions within 15 minutes using canaries,”
• “reduce invalidated runs from compiler releases to zero through release gates.”

Weak roadmap items:

• “use more quantum,”
• “improve fidelity,”
• “make platform production-ready,”
• “support more algorithms.”

A roadmap item should identify the operational metric it changes.

17.11 Operating model checklist

flowchart LR
    Ownership[Ownership] --> Process[Process]
    Process --> Telemetry[Telemetry]
    Telemetry --> Learning[Learning]
    Learning --> Improvement[Continuous improvement]
    Improvement --> Ownership

The operating model is the machine around the machine. Without it, the QPU remains a lab instrument. With it, the QPU can become part of a reliable computational platform.