Standard Operating Environment for Quantum Platforms

A quantum platform should not be a loose collection of notebooks, credentials, provider accounts, simulator scripts, and lab procedures. It needs a standard operating environment: the approved baseline that tells users what they may run, where they may run it, what evidence must be captured, and which paths are supported.

The standard operating environment, or SOE, is not bureaucracy. It is the mechanism that makes quantum work repeatable. Without it, two teams can submit similar circuits through different SDK versions, different runtime options, different calibration snapshots, and different post-processing assumptions, then argue about whose result is “real.”

The SOE should be maintained like production infrastructure. NIST CSF 2.0 frames governance as part of cybersecurity risk management, not as a separate afterthought; the same principle applies to quantum operations. The operating environment is where governance becomes executable. [R160]

Diagram loads as you read

Standard Operating Environment for Quantum Platforms · Figure 1

View diagram source

flowchart LR
    Intent[User intent] --> SOE[Standard operating environment]
    SOE --> Toolchain[Approved toolchain]
    SOE --> Targets[Approved targets]
    SOE --> Evidence[Required evidence]
    SOE --> Policy[Guardrails]
    Toolchain --> Run[Execution]
    Targets --> Run
    Evidence --> Review[Review and reuse]
    Policy --> Run

What the SOE contains

A useful SOE defines the supported path from problem statement to preserved result.

SOE domain	Quantum-specific content
identity	users, service accounts, lab roles, broker roles
toolchain	SDK versions, compiler versions, simulator versions, container images
target catalog	providers, QPUs, simulators, analog devices, target classes
evidence	required metadata, calibration links, result packages, review state
policy	admission rules, data rules, cost limits, publication rules
support	escalation paths, runbooks, change windows, rollback rules

Diagram loads as you read

What the SOE contains · Figure 2

View diagram source

mindmap
  root((Quantum SOE))
    Toolchain
      SDKs
      Compilers
      Containers
    Targets
      QPUs
      Simulators
      Testbeds
    Policies
      Access
      Cost
      Evidence
    Operations
      Runbooks
      Incidents
      Maintenance

The SOE should be narrow enough that teams can rely on it and broad enough that research is not forced into unsupported shortcuts.

Baseline profiles

Do not define one environment for all users. Define profiles.

Diagram loads as you read

Baseline profiles · Figure 3

View diagram source

flowchart TB
    SOE[SOE] --> Explore[Exploration profile]
    SOE --> Research[Research profile]
    SOE --> Production[Production profile]
    SOE --> Regulated[Regulated profile]

    Explore --> Loose[Loose cost and evidence rules]
    Research --> Repro[Reproducibility package required]
    Production --> SLO[SLO and rollback required]
    Regulated --> Audit[Audit and retention required]

Example profiles:

Profile	Use	Controls
exploration	learning, demos, quick tests	small budget, simulator-first, limited evidence
research	publishable or reusable experiments	versioned artifacts, calibration capture, statistical review
production pilot	customer-facing or operational workflow	SLO, evidence package, incident path, cost envelope
regulated	export, privacy, safety, or contractual sensitivity	approval workflow, retention, audit, constrained targets

Golden paths

A golden path is the supported route through the platform. It should make the correct action easier than the unsafe shortcut.

Diagram loads as you read

Golden paths · Figure 4

View diagram source

sequenceDiagram
    participant Dev as Developer
    participant CLI as Quantum CLI
    participant Policy as Policy engine
    participant Broker as Broker
    participant Store as Evidence store
    Dev->>CLI: qrun submit workload.yaml
    CLI->>Policy: validate profile and constraints
    Policy-->>CLI: approved with target class
    CLI->>Broker: submit package
    Broker->>Store: create run record
    Broker-->>CLI: job id and evidence id

A golden path should include:

project creation;
local simulation;
target selection;
budget estimation;
policy validation;
execution;
evidence capture;
review;
archival.

Configuration layering

Quantum operations become unmanageable when configuration is scattered across notebooks, environment variables, web consoles, and provider defaults.

Diagram loads as you read

Configuration layering · Figure 5

View diagram source

flowchart TB
    Org[Organization policy] --> Project[Project config]
    Project --> Workload[Workload manifest]
    Workload --> Run[Run request]
    Target[Target profile] --> Run
    Calibration[Calibration snapshot] --> Run
    Run --> Evidence[Evidence package]

Use explicit precedence rules.

Illustrative listing · yaml

configuration_precedence:
  - organization_policy
  - project_policy
  - target_profile
  - workload_manifest
  - run_request
forbidden_overrides:
  - evidence_retention
  - export_control_classification
  - publication_review_required
  - regulated_data_target_allowlist

Toolchain drift

The SOE must track toolchain drift as aggressively as device drift.

Diagram loads as you read

Toolchain drift · Figure 6

View diagram source

flowchart LR
    SDK[SDK release] --> Test[Regression tests]
    Compiler[Compiler release] --> Test
    Runtime[Runtime change] --> Test
    Target[Target profile change] --> Test
    Test --> Approve{Approve?}
    Approve -- yes --> Promote[Promote to SOE]
    Approve -- no --> Hold[Hold and document]

A compiler update can change circuit depth, routing, gates, measurement ordering, or metadata. That means it can change cost and scientific interpretation. The SOE must record which versions are approved and which claims rely on which versions.

Target classes

Avoid hard-coding provider names into workflows. Use target classes.

Diagram loads as you read

Target classes · Figure 7

View diagram source

flowchart TB
    Workload[Workload requirements] --> Class[Target class]
    Class --> Superconducting[Superconducting gate model]
    Class --> Ion[Trapped-ion gate model]
    Class --> Neutral[Neutral-atom analog]
    Class --> Annealing[Annealing]
    Class --> Simulator[Simulator]

A target class can specify:

instruction set;
topology assumptions;
timing features;
shot limits;
queue behavior;
mitigation support;
data residency;
evidence requirements.

Release trains

The platform should publish releases. A release is not just software. It is a synchronized statement of supported SDKs, compiler passes, target profiles, policies, and evidence schemas.

Diagram loads as you read

Release trains · Figure 8

View diagram source

stateDiagram-v2
    [*] --> Candidate
    Candidate --> Validation
    Validation --> Pilot
    Pilot --> Released
    Validation --> Rejected
    Pilot --> RolledBack
    Released --> Deprecated
    Deprecated --> Retired

Each release needs a compatibility note.

Illustrative listing · yaml

release:
  id: qsoe-2026.04
  sdk_versions:
    qiskit: approved
    braket_sdk: approved
    cuda_q: restricted
  target_profiles:
    - superconducting-small-v3
    - trapped-ion-research-v2
    - neutral-atom-analog-v1
  evidence_schema: evidence-package-v6
  breaking_changes:
    - mitigation_options_require_explicit_declaration
    - target_class_names_revised

Unsupported work is allowed, but labeled

Research teams need freedom. The SOE should not prohibit experimentation, but it should label unsupported paths clearly.

Diagram loads as you read

Unsupported work is allowed, but labeled · Figure 9

View diagram source

flowchart LR
    Request[Run request] --> Supported{On golden path?}
    Supported -- yes --> Normal[Normal execution]
    Supported -- no --> Exception[Exception workflow]
    Exception --> Label[Unsupported evidence label]
    Exception --> Owner[Named accountable owner]
    Exception --> Expiry[Expiry date]

Unsupported work should not silently become production evidence.

SOE operating review

The SOE needs a recurring review cadence.

Diagram loads as you read

SOE operating review · Figure 10

View diagram source

journey
    title Monthly quantum SOE review
    section Inputs
      Provider changes: 4: Platform
      Incident trends: 4: SRE
      User friction: 3: DX
    section Decisions
      Promote toolchain: 4: Review board
      Deprecate target profile: 3: Review board
      Update policy: 4: Security
    section Outputs
      Release notes: 5: Platform
      Migration guide: 4: Support

A platform without a standard operating environment can still run jobs. It cannot reliably run a program.