Feature Flags, Progressive Delivery, and Experiment Rollouts

Quantum platforms change constantly: compiler passes, routing heuristics, mitigation models, calibration policies, queue rules, result schemas, and provider adapters. Changing everything for everyone at once is unsafe. Feature flags and progressive delivery let teams reduce blast radius.

OpenFeature defines a vendor-agnostic feature-flag API and evaluation model [R218]. Quantum platforms should use the same principle for operational controls: route decisions through explicit flag evaluation rather than hidden environment variables.

Diagram loads as you read

Feature Flags, Progressive Delivery, and Experiment Rollouts · Figure 1

View diagram source

flowchart LR
    Request[Workload request] --> Context[Evaluation context]
    Context --> Flag[Feature flag evaluation]
    Flag --> Policy[Runtime policy]
    Policy --> Execution[Execution path]
    Execution --> Metrics[Outcome metrics]
    Metrics --> Rollout[Rollout decision]

What to flag

Not every parameter deserves a flag. Flag changes that alter correctness, cost, routing, or evidence.

Flag class	Example	Required evidence
compiler	new layout heuristic	benchmark comparison
mitigation	new ZNE profile	bias and variance report
scheduler	new priority rule	queue impact report
provider	new backend adapter	conformance test result
evidence	new schema version	compatibility proof
access	new admission policy	authorization test result

Diagram loads as you read

What to flag · Figure 2

View diagram source

flowchart TB
    FlagSurface[Quantum flag surface] --> Compiler[Compiler flags]
    FlagSurface --> Mitigation[Mitigation flags]
    FlagSurface --> Scheduler[Scheduler flags]
    FlagSurface --> Provider[Provider flags]
    FlagSurface --> Evidence[Evidence flags]
    FlagSurface --> Access[Access flags]

Progressive rollout states

Diagram loads as you read

Progressive rollout states · Figure 3

View diagram source

stateDiagram-v2
    [*] --> Disabled
    Disabled --> Internal: lab enablement
    Internal --> Canary: limited workload class
    Canary --> Expanded: selected projects
    Expanded --> DefaultOn: safe default
    DefaultOn --> Mandatory: old path retired
    Canary --> RolledBack: guardrail trip
    Expanded --> RolledBack: guardrail trip

The key control is not the flag itself. It is the rollout policy attached to the flag.

Rollout context

Feature decisions should depend on context.

Illustrative listing · yaml

flag_context:
  project: materials-vqe
  workload_class: benchmark
  evidence_class: internal
  backend_family: superconducting-transmon
  compiler_target_family: target-v7
  sensitivity: confidential
  cost_center: qc-platform

Diagram loads as you read

Rollout context · Figure 4

View diagram source

flowchart LR
    Context[Context] --> Project[Project]
    Context --> Workload[Workload class]
    Context --> Evidence[Evidence class]
    Context --> Backend[Backend family]
    Context --> Sensitivity[Sensitivity]
    Context --> Cost[Cost center]

A new mitigation model may be safe for exploratory workloads but not for external claims. A new scheduler policy may be safe for simulator runs but not reservation-backed QPU work.

Guardrails

Diagram loads as you read

Guardrails · Figure 5

View diagram source

flowchart TB
    Rollout[Rollout] --> Metrics[Monitor metrics]
    Metrics --> Error[Error and variance]
    Metrics --> Cost[Cost per accepted run]
    Metrics --> Latency[Queue and runtime latency]
    Metrics --> Incidents[Incident rate]
    Metrics --> Evidence[Evidence completeness]
    Error --> Decision{Guardrail breach?}
    Cost --> Decision
    Latency --> Decision
    Incidents --> Decision
    Evidence --> Decision
    Decision -- yes --> Rollback[Automatic rollback]
    Decision -- no --> Continue[Continue rollout]

Quantum guardrails must include scientific metrics, not only service metrics.

Rollback discipline

Diagram loads as you read

Rollback discipline · Figure 6

View diagram source

flowchart LR
    Breach[Guardrail breach] --> Freeze[Freeze rollout]
    Freeze --> Disable[Disable flag]
    Disable --> Drain[Drain affected queue]
    Drain --> Mark[Mark impacted evidence]
    Mark --> RCA[Run RCA]
    RCA --> Retry[Retry with revised gate]

Rollback should mark affected evidence packages so reviewers know which path was active.

Flag debt

Feature flags become risk when they never die.

Diagram loads as you read

Flag debt · Figure 7

View diagram source

flowchart LR
    Flag[Flag] --> Age[Age check]
    Age --> Owner[Owner check]
    Owner --> Usage[Usage check]
    Usage --> Decision{Still needed?}
    Decision -- yes --> Renew[Renew with expiration]
    Decision -- no --> Remove[Remove and close evidence]

Every quantum flag should have an owner, review date, planned removal condition, and evidence policy.