Reference Platform Architecture — Operating Quantum Computers

This chapter assembles the book into a reference architecture. It is not a prescription for every organization. It is a concrete target state for a serious quantum platform: governed, reproducible, observable, cost-aware, provider-portable where useful, and honest about uncertainty.

34.1 Platform overview

Diagram loads as you read

34.1 Platform overview · Figure 1

View diagram source

flowchart TB
    Users[Users and domain teams] --> Portal[Experiment portal / API]
    Portal --> Governance[Governance and policy]
    Portal --> Planner[Workload planner]
    Planner --> Compiler[Compiler and target matcher]
    Compiler --> Scheduler[Scheduler and admission control]
    Scheduler --> Providers[Provider adapters]
    Providers --> QPUs[QPUs and simulators]
    QPUs --> Results[Result ingestion]
    Results --> Store[Artifact and metadata store]
    Store --> Trust[Trust report generator]
    Trust --> Users
    Store --> Observability[Observability]
    Scheduler --> Cost[Cost and capacity engine]

The platform has one job: convert user intent into trustworthy computational evidence under known constraints.

34.2 Control-plane services

Diagram loads as you read

34.2 Control-plane services · Figure 2

View diagram source

classDiagram
    class ExperimentAPI {
      submit()
      validate()
      status()
      cancel()
      report()
    }
    class PolicyService {
      authorize()
      enforce_budget()
      enforce_claim_policy()
    }
    class WorkloadPlanner {
      estimate_resources()
      choose_target_candidates()
    }
    class Scheduler {
      admit()
      queue()
      dispatch()
    }
    class ProviderAdapter {
      submit_provider_job()
      normalize_result()
    }
    ExperimentAPI --> PolicyService
    ExperimentAPI --> WorkloadPlanner
    WorkloadPlanner --> Scheduler
    Scheduler --> ProviderAdapter

Service inventory:

Service	Responsibility
experiment API	stable user-facing submission surface
policy service	identity, budget, approval, data controls
workload planner	resource estimate and target candidates
compiler service	circuit lowering and optimization
scheduler	admission, queueing, reservations, fairness
provider adapter	API translation and result normalization
artifact store	immutable provenance and raw data
trust generator	evidence reports and uncertainty summaries
observability	traces, metrics, logs, dashboards, alerts
cost engine	spend attribution and capacity planning

34.3 Data-plane architecture

Diagram loads as you read

34.3 Data-plane architecture · Figure 3

View diagram source

flowchart LR
    Execution[Execution result] --> Raw[Raw provider artifact]
    Execution --> Normalized[Normalized result]
    Execution --> Metadata[Execution metadata]
    Raw --> ObjectStore[Object store]
    Normalized --> Warehouse[Analytical warehouse]
    Metadata --> Catalog[Metadata catalog]
    Catalog --> Trust[Trust reports]
    Warehouse --> Dashboards[Dashboards]

Data-plane rules:

raw artifacts are immutable,
normalized results are derived and versioned,
metadata is queryable,
trust reports link to immutable inputs,
deletion and retention policies are explicit,
access is least-privilege,
schema migrations are recorded.

34.4 Experiment bundle

The experiment bundle is the atomic unit of reproducibility.

Diagram loads as you read

34.4 Experiment bundle · Figure 4

View diagram source

erDiagram
    EXPERIMENT_BUNDLE ||--|| PROPOSAL : includes
    EXPERIMENT_BUNDLE ||--o{ CIRCUIT_ARTIFACT : includes
    EXPERIMENT_BUNDLE ||--o{ TARGET_SNAPSHOT : includes
    EXPERIMENT_BUNDLE ||--o{ EXECUTION_RESULT : includes
    EXPERIMENT_BUNDLE ||--o{ COST_RECORD : includes
    EXPERIMENT_BUNDLE ||--o{ TRUST_REPORT : includes

Bundle schema:

Illustrative listing · yaml

experiment_bundle:
  bundle_id: string
  workload_id: string
  proposal_uri: string
  owner: string
  purpose: exploratory|publication|production
  approvals:
    - approver: string
      policy: string
      timestamp: timestamp
  artifacts:
    source_uri: string
    circuit_uri: string
    compiled_circuit_uri: string
    target_snapshot_uri: string
    result_uri: string
    trust_report_uri: string
  versions:
    schema: string
    compiler: string
    adapter: string
    provider_sdk: string
  costs:
    estimated: float|null
    actual: float|null

34.5 Admission-control path

Diagram loads as you read

34.5 Admission-control path · Figure 5

View diagram source

sequenceDiagram
    participant User
    participant API as Experiment API
    participant Policy as Policy service
    participant Estimate as Resource estimator
    participant Target as Target matcher
    participant Sched as Scheduler
    participant Adapter as Provider adapter
    User->>API: submit workload
    API->>Policy: authorize and budget check
    Policy-->>API: approved / denied
    API->>Estimate: estimate resources
    Estimate->>Target: request target candidates
    Target-->>Estimate: candidates with constraints
    Estimate-->>API: estimate and risks
    API->>Sched: admission request
    Sched->>Adapter: dispatch when admitted

Admission decisions should be explainable. A rejected job should return the reason and a repair suggestion.

34.6 Trust-report pipeline

Diagram loads as you read

34.6 Trust-report pipeline · Figure 6

View diagram source

flowchart TB
    Result[Result bundle] --> Validate[Validate completeness]
    Validate --> Stats[Statistical analysis]
    Stats --> Baseline[Baseline comparison]
    Baseline --> Drift[Drift and calibration analysis]
    Drift --> Cost[Cost summary]
    Cost --> Limits[Limitations]
    Limits --> Report[Trust report]

Trust-report sections:

Section	Purpose
workload summary	what was attempted
target summary	where and under what constraints
execution summary	shots, queue, runtime, errors
statistical summary	estimates and uncertainty
baseline comparison	decision context
drift analysis	hardware stability context
cost summary	budget and efficiency
limitations	what cannot be claimed

34.7 Observability map

Diagram loads as you read

34.7 Observability map · Figure 7

View diagram source

flowchart LR
    API[API spans] --> Trace[Distributed trace]
    Compiler[Compiler spans] --> Trace
    Scheduler[Scheduler spans] --> Trace
    Adapter[Adapter spans] --> Trace
    Provider[Provider job IDs] --> Trace
    Trace --> Incident[Incident analysis]
    Metrics[Metrics] --> Dashboard[Dashboards]
    Logs[Logs] --> Incident

Key dashboards:

Dashboard	Audience
platform health	SRE and operations
target quality	algorithm and hardware teams
queue and throughput	platform and product
experiment portfolio	leadership and product
cost and capacity	FinOps and management
trust-report backlog	data and publication teams

34.8 Deployment environments

Diagram loads as you read

34.8 Deployment environments · Figure 8

View diagram source

flowchart TB
    Dev[Development] --> Sim[Simulation staging]
    Sim --> HardwareStaging[Hardware staging]
    HardwareStaging --> Prod[Production]
    Prod --> Archive[Long-term archive]

Environment policy:

Environment	Allowed work
development	local tests, schema changes, mock adapters
simulation staging	full workflow on simulators
hardware staging	limited real-backend validation
production	approved workloads and customer-facing jobs
archive	immutable artifacts and reports

34.9 Failure containment

A quantum platform should fail closed when evidence is incomplete.

Diagram loads as you read

34.9 Failure containment · Figure 9

View diagram source

flowchart TB
    Failure[Failure] --> Submission[Submission failure]
    Failure --> Execution[Execution failure]
    Failure --> Metadata[Metadata missing]
    Failure --> Statistical[Statistical failure]
    Failure --> Trust[Trust report failure]
    Metadata --> Hold[Hold result from publication]
    Statistical --> Hold
    Trust --> Hold

Containment policies:

missing metadata blocks trust-report completion,
failed baselines block publication claims,
stale calibration triggers warning or rerun,
schema mismatch blocks ingestion,
cost anomaly triggers review,
security policy violation cancels execution.

34.10 Platform maturity path

Diagram loads as you read

34.10 Platform maturity path · Figure 10

View diagram source

gantt
    title Reference platform maturity path
    dateFormat  YYYY-MM-DD
    section Foundation
    Experiment bundle schema       :a1, 2026-04-19, 90d
    Provider adapter abstraction   :a2, 2026-05-01, 120d
    section Governed execution
    Admission control              :b1, 2026-07-01, 120d
    Trust reports                  :b2, 2026-08-01, 150d
    section Scale
    Cost engine                    :c1, 2026-10-01, 150d
    Portfolio dashboards           :c2, 2026-11-01, 150d
    section FT readiness
    Resource estimator integration :d1, 2027-01-01, 240d
    Logical workload API           :d2, 2027-06-01, 365d

34.11 Chapter checklist

A reference platform needs:

user-facing experiment API,
policy service,
resource estimator,
compiler and target matcher,
scheduler and admission control,
provider adapters,
immutable artifact store,
trust-report generator,
observability and incident process,
cost and capacity engine,
portability and exit strategy.

Diagram loads as you read

34.11 Chapter checklist · Figure 11

View diagram source

flowchart LR
    API[API] --> Platform[Reference platform]
    Policy[Policy] --> Platform
    Scheduler[Scheduler] --> Platform
    Store[Artifact store] --> Platform
    Trust[Trust reports] --> Platform
    Observability[Observability] --> Platform