Control-Plane Deployment Topologies and Disaster Domains

Quantum platforms have unusual failure domains. A control plane may be cloud-hosted while the QPU sits in a lab, a cryogenic system may be local while the job broker is remote, and evidence storage may be governed by a different residency policy from runtime execution.

Resilient design starts by naming disaster domains. A disaster domain is the boundary inside which a failure can invalidate service, evidence, or safety assumptions.

Diagram loads as you read

Control-Plane Deployment Topologies and Disaster Domains · Figure 1

View diagram source

flowchart TB
    Domains[Disaster domains] --> Lab[Lab and facilities]
    Domains --> Control[Control plane]
    Domains --> Provider[Provider runtime]
    Domains --> Network[Network and identity]
    Domains --> Evidence[Evidence store]
    Domains --> People[Operator availability]

Topology patterns

Cloud-mediated access

Diagram loads as you read

Topology patterns · Figure 2

View diagram source

flowchart LR
    User[User] --> Portal[Enterprise portal]
    Portal --> Broker[Quantum broker]
    Broker --> Cloud[Provider cloud]
    Cloud --> QPU[Provider QPU]
    Cloud --> Results[Provider result store]
    Results --> Evidence[Enterprise evidence store]

This is the common pattern for most enterprises. Its risk is dependency on external runtime behavior and provider-side operational transparency.

Lab-owned QPU with cloud control services

Diagram loads as you read

Topology patterns · Figure 3

View diagram source

flowchart LR
    User[User] --> CloudControl[Cloud control services]
    CloudControl --> LabGateway[Lab gateway]
    LabGateway --> ControlRack[Control rack]
    ControlRack --> QPU[Local QPU]
    LabGateway --> Evidence[Enterprise evidence store]

This pattern separates cloud orchestration from physical execution. It needs strict network segmentation and local safety interlocks.

Air-gapped or restricted enclave

Diagram loads as you read

Topology patterns · Figure 4

View diagram source

flowchart LR
    User[Cleared user] --> EnclavePortal[Enclave portal]
    EnclavePortal --> LocalScheduler[Local scheduler]
    LocalScheduler --> Simulator[Local simulator]
    LocalScheduler --> QPU[Enclave QPU]
    QPU --> EvidenceVault[Enclave evidence vault]

This pattern prioritizes residency and confidentiality. It increases operational burden because dependencies, images, documentation, and security updates must move through controlled channels.

Disaster-domain matrix

Domain	Example failure	Required response
lab	cryogenic outage	stop admission, preserve telemetry, open facility incident
cloud control	API outage	pause submissions, retry idempotently, fail over if approved
provider runtime	queue or backend outage	reroute eligible workloads, preserve rejected requests
identity	token compromise	revoke credentials, freeze high-assurance workloads
evidence	storage corruption	recover from immutable backup, verify checksums
people	on-call gap	transfer ownership, restrict risky changes

Diagram loads as you read

Disaster-domain matrix · Figure 5

View diagram source

flowchart TB
    Failure[Failure] --> Detect[Detect]
    Detect --> Classify[Classify disaster domain]
    Classify --> Contain[Contain]
    Contain --> Preserve[Preserve evidence]
    Preserve --> Recover[Recover service]
    Recover --> Review[Post-incident review]

Recovery objectives

Quantum platforms need multiple recovery objectives.

Diagram loads as you read

Recovery objectives · Figure 6

View diagram source

flowchart LR
    RTO[Recovery time objective] --> Service[Service availability]
    RPO[Recovery point objective] --> Data[Evidence and metadata loss]
    RCO[Recovery confidence objective] --> Trust[Trust in recovered baseline]
    RQO[Recovery quality objective] --> Quality[Result quality after recovery]

The extra objectives matter because a recovered service can still produce untrustworthy results if the baseline state is unknown.

Split-brain risks

Diagram loads as you read

Split-brain risks · Figure 7

View diagram source

flowchart TB
    Split[Split-brain risk] --> Baseline[Two active baselines]
    Split --> Queue[Duplicate job admission]
    Split --> Evidence[Conflicting evidence stores]
    Split --> Identity[Stale access policy]
    Split --> Status[Incorrect status page]

Control-plane failover must prevent two sites from admitting claim-bearing jobs under different assumptions. Prefer conservative fail-closed behavior for high-assurance workloads.

Recovery drill

Diagram loads as you read

Recovery drill · Figure 8

View diagram source

sequenceDiagram
    participant Lead as Exercise lead
    participant Portal as Portal
    participant Broker as Broker
    participant Evidence as Evidence store
    participant OnCall as On-call
    Lead->>Portal: Declare simulated provider outage
    Portal->>Broker: Disable affected target
    Broker->>Evidence: Record admission freeze
    OnCall->>Broker: Reroute eligible workload
    Broker->>Evidence: Attach reroute evidence
    Lead->>OnCall: Verify recovery objective

Drills should include evidence preservation. A platform that recovers service but loses auditability has not recovered.

Practical rule

Do not design quantum continuity around “the QPU is up.” Design around which failure domains can fail independently, which workloads are safe to reroute, and which claims are still defensible after recovery.