Prometheus Quantum Hypervisor is the execution-intelligence layer developed by Prometheus Dynamics. It evaluates how a logical workload can be physically realized for a specific QPU, selects an execution candidate, and connects that decision to measured hardware results.
The controlled multi-QPU study submits an identical logical circuit simultaneously to Fez, Kingston, and Marrakesh. The measured physical result changes materially with the target processor, and the relative performance of the execution strategies can change with it.
For the 20-qubit broadcast, each target QPU receives an identical logical circuit submitted simultaneously to Fez, Kingston, and Marrakesh. Each compiler receives the same 16,384-shot allocation, and the resulting physical executions are recorded from the corresponding IBM jobs.
Prometheus vs 0.0227 for SABRE O3 and 0.0022 for TKET.
Prometheus vs 0.0249 for SABRE O3 and 0.0021 for TKET.
Prometheus vs 0.0293 for SABRE O3 and 0.0067 for TKET.
.png)
.png)
.png)
Raw IBM job responses are preserved, packaged deterministically, fingerprinted with SHA-256, and verified through a separate integrity process. The public evidence record is designed so post-capture modification of the preserved artifacts is detectable.
Prometheus operates at the point where a logical circuit becomes a real hardware execution. That matters when the physical processor, workload structure, and compilation choice can materially change the measured result.
In the controlled 20Q study, the same workload class produced 0.0981 measured fidelity with Prometheus on Kingston versus 0.0249 for SABRE O3.
On Marrakesh, Prometheus reached 0.0904 fidelity while SABRE O3 reached 0.0641 for the same 21Q broadcast workload family.
Prometheus reached 0.0275 fidelity versus 0.0002 for SABRE O3 in the 22Q Fez broadcast result.
Prometheus sits around the compilation stack rather than exposing another general-purpose compiler as the product. It connects the logical workload to a specific physical processor, evaluates execution candidates, and keeps the proprietary selection mechanism protected.
Start with the logical circuit and execution requirements.
Consider multiple compilation and routing paths for the target environment.
Incorporate hardware information into the physical compilation decision.
Send the chosen physical compilation to the QPU and inspect the resulting measurements.
A 9-qubit dense all-to-all graph forces a sparse processor to reconcile a highly connected logical workload with limited physical connectivity. This earlier single-job comparison shows how a different physical realization can change measured hardware outcomes.
SABRE produced a valid routed circuit using 90 two-qubit gates and a physical depth of 145. Its measured state fidelity in this comparison was 0.5738.
TKET produced a valid physical circuit, but in this benchmark it required 123 two-qubit gates and reached a physical depth of 165. Its measured state fidelity was 0.5248.
Prometheus selected a different physical compilation with 74 two-qubit gates and a depth of 109. That execution produced a measured state fidelity of 0.7466.
The three compilation paths were evaluated through a single SamplerV2 hardware job on IBM Marrakesh rather than through separate jobs taken at different times. This controls for execution-window differences such as changing calibration conditions and timing between runs, keeping the comparison tied to one physical execution record.
Prometheus grew out of real-hardware experiments examining how physical placement, routing cost, hardware conditions, and measured output interact. The public record contains five experimental programs, randomized instances, multi-QPU studies, IBM execution evidence, aggregate results, and explicit limitations.
The repository separates individual experiments so hypotheses can be tested under different workloads, scales, topologies, and physical processors.
Prometheus research does not assume that lower routing cost always means better hardware output. The experiments test that relationship directly, look for repeatability across randomized instances, examine scaling boundaries, and compare behavior across IBM Heron processors. The public record also retains mixed and negative outcomes rather than only favorable examples.
View the public research record →Tests whether physical routing cost and observed output-distribution behavior remain coupled on real hardware. One QFT-8 experiment on ibm_kingston showed a more concentrated output despite substantially greater physical routing cost.
Matched randomized QAOA and CrossEnt instances test whether observed behavior survives beyond manually selected circuits.
Sweeps workload size and algorithm family to identify both favorable topological regimes and routing-penalty regimes rather than assuming that extra routing is always beneficial.
A 13-qubit topology-stress benchmark examined whether a substantially different physical realization could avoid the ground-state collapse observed in a depth-optimized baseline.
Related workloads were examined across Fez, Kingston, and Marrakesh to test whether global device statistics are enough to describe the quality of a particular physical execution.
The next stage is broader independent evaluation: real workloads, additional hardware, repeat measurements, technical integration, and the resources needed to move the system beyond an internal research program.
Prometheus can be evaluated against workloads that are sensitive to physical topology, routing, and hardware conditions. The goal is to determine where execution intelligence creates measurable value on workloads that matter outside the laboratory.
Prometheus has an established real-hardware research record across multiple IBM processors and workload scales. The next step is external workloads, broader hardware coverage, repeat measurements, and independent hands-on evaluation.
UPLINK execution endpoints are currently restricted. External technical evaluation can be scoped around your workload, target hardware, and the level of evidence you need to inspect.
Start with a real logical workload, its execution objective, and the processors or hardware conditions you want evaluated.
Agree on the comparison, target QPU, measurements, and evidence package appropriate for the evaluation.
Execute the selected workload through the evaluation environment and compare measured results against the agreed baseline.
Review the physical realization, execution results, provenance, and preserved evidence associated with the evaluation.
The industry's effective quantum computational capacity is not determined by the physical qubit count printed on the processor. It is determined by how much useful computation survives physical execution.
Both IBM (via SABRE O3) and Quantinuum (via TKET) have developed world-class general-purpose compilers. However, both stacks were engineered under a fundamental architectural assumption: they treat physical hardware as static geometry rather than an evolving, noisy environment.
IBM's SABRE optimizes aggressively for mathematical circuit depth and physical gate counts, but assumes that all couplers on the heavy-hex lattice behave equally according to static calibration tables. When mapping dense, highly connected algorithms, SABRE frequently routes critical computational traffic directly through degraded physical couplers, causing fatal phase decoherence across long gate sequences.
Quantinuum's TKET is exceptionally powerful at algebraic simplification and single-qubit rotation reduction. However, when confronted with complex, non-native multi-qubit graphs on sparse superconducting hardware, TKET's default architectural mapping passes generate massive, bloated SWAP gate chains. These chains rapidly push circuit execution duration beyond the hardware's coherence lifetime, collapsing the quantum state into uniform white noise.
Prometheus does not treat compilation as a one-way translation step. It treats physical execution as a continuous optimization problem. By adaptively synthesizing physical topology around live hardware decay profiles, Prometheus selectively detours traffic away from critical path congestion. This minimizes idle spectator decoherence and ensures quantum phase coherence survives before the physical microwave pulses ever execute.
To demonstrate clear superiority over industry baselines, we broadcasted an identical, dense 18-node complete graph simultaneously across three distinct 156-qubit IBM Heron processors (Fez, Kingston, and Marrakesh). To ensure uncompromising scientific fairness, all compilers operated under identical shot allocations (16,384 shots) with uniform Twirled Readout Error Extinction (TREX) applied equally across all returned distributions.
| Hardware Backend | Observed Metric | IBM Baseline (SABRE O3) | Prometheus Hypervisor | Net Physical Advantage |
|---|---|---|---|---|
| IBM Kingston 156-Qubit Heron QPU |
Circuit Depth | 370 layers | 265 layers | -105 Layers (-28.4%) |
| Two-Qubit Gates | 439 gates | 323 gates | -116 Gates (-26.4%) | |
| Physical State Fidelity | 0.1819 | 0.2709 | +48.92% Relative Improvement | |
| IBM Marrakesh 156-Qubit Heron QPU |
Circuit Depth | 458 layers | 330 layers | -128 Layers (-27.9%) |
| Coupler Congestion | 49.14 index | 15.16 index | -69.1% Congestion Relief | |
| Physical State Fidelity | 0.1037 | 0.1444 | +39.20% Relative Improvement | |
| IBM Fez 156-Qubit Heron QPU |
Physical State Fidelity | 0.1270 | 0.1362 | +7.24% Relative Improvement |
Usage-based subscription for enterprise quantum research labs, financial institutions, and pharmaceutical teams. Charges per compilation pass based on physical risk reduction and depth elimination.
Multi-processor orchestration software for enterprises with dedicated cloud QPU reservations. Automatically dispatches complex workloads to the optimal physical backend based on live coherence conditions.
Licensing the Prometheus hypervisor directly to quantum hardware manufacturers and cloud brokers (AWS Braket, Azure Quantum, IBM Quantum) as an embedded, native pre-execution layer.
The core execution intelligence engine is complete, documented across 33 IBM QPU deployments, and proven on real hardware. We are raising seed capital to expand multi-architecture hardware coverage, onboard external enterprise pilot workloads, and harden our high-throughput API gateway.