PhoenixFlight for Hybrid Quantum-Classical Workloads
Govern the classical control plane around quantum applications.
Important Positioning: PhoenixFlight does not execute quantum circuits directly and does not replace quantum providers (like IBM Quantum, AWS Braket, or Azure Quantum). It provides a Dynamic Membership control layer for routing and auditing workloads across classical workers, simulators, quantum provider adapters, and agentic optimization workflows.
Why quantum workloads fit DMA
Hybrid quantum-classical workloads are an excellent Dynamic Membership Architecture (DMA) use case because execution participants are fundamentally fluid:
- QPUs are scarce and highly queue-dependent.
- Simulators are often used as fallbacks or precursors before real QPU execution.
- Provider capability, pricing, and availability can change dynamically.
- Classical preprocessing, optimization, and post-processing agents are integral parts of the workload.
- Governance, budget constraints, geographic data policies, and execution audit trails are critical for enterprise adoption.
DMA Mapping
| DMA Primitive |
Quantum Workload Interpretation |
| Identity |
Experiment ID, Flight Packet ID, quantum job ID, provider adapter ID |
| Discovery |
Discover simulators, provider adapters, backend capabilities, queue status, policy eligibility |
| Assignment |
Route workload to simulator, provider adapter, classical worker, or optimization agent |
| Migration / Handoff |
Move workflow state, retry queued jobs, fall back from QPU to simulator, transfer context between agents |
| Retirement |
Complete, cancel, archive, or drain quantum jobs and provider sessions |
| Governance |
Enforce provider access, budget, data policy, trust thresholds, audit, lineage |
Reference Architecture
Application / Notebook / API
↳ PhoenixFlight Control Plane
↳ Flight Packet
↳ Policy + Governance Engine
↳ Quantum Adapter Layer
↳ Simulator / External QPU Provider (Mock Demo)
↳ Result Store + Flight Recorder Audit
Example Lifecycle
- Register simulator, provider adapter, optimization agent, and result validator as dynamic members.
- Create a Flight Packet for a quantum optimization experiment.
- Discover eligible execution paths.
- Assign first run to a simulator.
- Escalate or route to a QPU provider adapter if policy allows.
- Fall back if queue, cost, policy, or availability changes.
- Preserve experiment context and audit lineage.
- Retire completed jobs and archive results.
Current Status
This is a strategic use-case and reference architecture direction. The current PhoenixFlight MVP demonstrates local dynamic membership, governed assignment, handoff, retirement, bundling, and audit. Quantum provider adapters are proposed roadmap extensions.