Quantum Control-Plane Reference Implementation

The control plane is the part of the platform that turns intent into governed execution. It does not replace the QPU vendor stack, the lab control system, or the researcher’s SDK. It wraps them with identity, policy, routing, observability, evidence capture, and lifecycle management.

NIST SP 800-160 frames trustworthy systems as the result of engineering discipline across the system life cycle [R200]. For a quantum platform, the control plane is where that discipline becomes executable.

Diagram loads as you read

Quantum Control-Plane Reference Implementation · Figure 1

View diagram source

flowchart TB
    User[User or service] --> API[Quantum platform API]
    API --> Policy[Policy engine]
    API --> Catalog[Target catalog]
    API --> Broker[Workload broker]
    Broker --> Runtime[Runtime adapter]
    Runtime --> Provider[Provider or lab stack]
    Provider --> Results[Results]
    Results --> Evidence[Evidence service]
    Evidence --> Warehouse[Experiment warehouse]
    Evidence --> Audit[Audit log]

Control plane responsibilities

A quantum control plane should own the parts of execution that are independent of a specific provider.

Diagram loads as you read

Control plane responsibilities · Figure 2

View diagram source

flowchart LR
    ControlPlane[Control plane] --> Identity[Identity and entitlement]
    ControlPlane --> Intake[Workload intake]
    ControlPlane --> Admission[Admission control]
    ControlPlane --> Routing[Target routing]
    ControlPlane --> Evidence[Evidence capture]
    ControlPlane --> Cost[Cost attribution]
    ControlPlane --> Lifecycle[Lifecycle state]

It should not hide physics. It should expose target constraints and make unsafe abstractions harder to misuse.

API surface

The minimum useful API is small:

API	Purpose
workload submission	accept a declared experiment or service request
target catalog	expose hardware, simulator, and emulation capabilities
policy decision	explain why a workload is allowed, denied, or constrained
run status	expose queue, execution, completion, and failure state
evidence retrieval	return artifacts needed for review and reproduction
cost estimate	project and record usage
retirement	mark workloads, targets, and evidence as inactive

OpenAPI provides a standard interface-description format for HTTP APIs [R202]. Use it for synchronous control APIs. Use AsyncAPI and event envelopes for long-running state transitions and telemetry streams [R203].

Diagram loads as you read

API surface · Figure 3

View diagram source

sequenceDiagram
    participant Client
    participant API as Platform API
    participant Policy
    participant Broker
    participant Adapter
    participant Evidence
    Client->>API: submit workload contract
    API->>Policy: evaluate entitlement and guardrails
    Policy-->>API: allow with constraints
    API->>Broker: enqueue governed request
    Broker->>Adapter: execute on selected target
    Adapter-->>Broker: result and telemetry
    Broker->>Evidence: persist evidence package
    API-->>Client: run handle and evidence link

Events as first-class records

Every important transition should emit an event. CloudEvents provides a common event metadata model for interoperability across services and systems [R204].

Diagram loads as you read

Events as first-class records · Figure 4

View diagram source

flowchart LR
    Submit[workload.submitted] --> Admit[workload.admitted]
    Admit --> Route[workload.routed]
    Route --> Start[run.started]
    Start --> Complete[run.completed]
    Start --> Fail[run.failed]
    Complete --> Evidence[evidence.sealed]
    Fail --> Incident[incident.candidate]

The event stream becomes the platform’s factual spine. Dashboards, alerts, audits, cost views, and postmortems should read from it rather than inventing separate truth.

Adapter pattern

Each provider or lab stack gets an adapter. The adapter translates the platform contract into the provider’s API, then translates provider output into the platform evidence model.

Diagram loads as you read

Adapter pattern · Figure 5

View diagram source

flowchart TB
    Contract[Canonical workload contract] --> Adapter{Adapter}
    Adapter --> IBM[IBM Runtime]
    Adapter --> Braket[Amazon Braket]
    Adapter --> Azure[Azure Quantum]
    Adapter --> Lab[Internal lab control]
    Adapter --> Sim[Simulator cluster]
    IBM --> Canonical[Canonical result]
    Braket --> Canonical
    Azure --> Canonical
    Lab --> Canonical
    Sim --> Canonical

Adapters should be boring. They should not contain hidden scientific assumptions. If an adapter changes mitigation, compilation, target selection, or shot policy, that change must be visible in evidence.

State machine

Quantum runs are long-running, failure-prone, and partially external. Treat them as state machines.

Diagram loads as you read

State machine · Figure 6

View diagram source

stateDiagram-v2
    [*] --> Draft
    Draft --> Submitted
    Submitted --> Admitted
    Submitted --> Rejected
    Admitted --> Queued
    Queued --> Running
    Running --> Completed
    Running --> Failed
    Running --> Cancelled
    Completed --> EvidenceSealed
    Failed --> EvidenceSealed
    Cancelled --> EvidenceSealed
    EvidenceSealed --> Archived

The important operational decision is not whether every run succeeds. It is whether every run ends in a known, auditable state.

Reference services

Diagram loads as you read

Reference services · Figure 7

View diagram source

flowchart TB
    subgraph Core[Core services]
        Identity[Identity]
        Policy[Policy]
        Catalog[Catalog]
        Broker[Broker]
        Evidence[Evidence]
    end
    subgraph Support[Support services]
        Cost[Cost]
        Telemetry[Telemetry]
        Secrets[Secrets]
        Registry[Artifact registry]
        Docs[Developer docs]
    end
    Core --> Support

The first implementation can be thin. A small API gateway, policy service, run database, event log, and evidence store are enough. The platform becomes valuable when these pieces are consistent.

Anti-patterns

Do not build a control plane that only forwards API calls. That is an expensive proxy. Do not build one that hides target differences. That creates false portability. Do not build one that stores results without provenance. That creates unusable data.

The control plane earns its existence when it can answer: who ran what, where, under which constraints, with which evidence, at what cost, and with what decision outcome.