Quantum Execution Hypervisor

The execution layer between your workload and the QPU.

Prometheus Dynamics is a hardware-aware quantum execution hypervisor. It coordinates compilation, routing, hardware information, and execution decisions so workloads can be mapped to physical processors with greater awareness of the environment they will enter.

Hardware-Aware Execution Layer
Secure Endpoint
Hypervisor
Execution Control Layer
Multi-QPU
Heterogeneous Hardware
Adaptive
Hardware-Aware Decisions
Physical
Real-QPU Validation
The Platform

More than a compiler.

Prometheus provides an execution layer around the compilation stack. It connects the logical workload to the physical processor while keeping the implementation details of the execution-selection system protected.

Quantum Execution Hypervisor
A control layer for turning a logical workload into an optimized physical compilation for a target quantum processor.
Execution Layer
Workload
Application stays above the hardware
Quantum workloads enter at the logical level while the execution system handles processor-specific concerns below the application.
Compilation
Compilation becomes an execution choice
Prometheus can evaluate multiple physical realizations rather than treating a single compiler output as the endpoint.
Hardware
Processor conditions inform placement
Hardware information can be incorporated into the selection of the physical execution used for the workload.
Execution
The chosen compilation reaches the QPU
The selected physical compilation is dispatched to real hardware and assessed through measured execution evidence.
01

Accept the workload

Start with the logical circuit and execution requirements.

02

Evaluate possibilities

Consider multiple compilation and routing paths for the target environment.

03

Coordinate with hardware

Incorporate hardware information into the physical compilation decision.

04

Dispatch and measure

Send the chosen physical compilation to the QPU and inspect the resulting measurements.

Measured Benchmark

The Dense All-to-All Routing Bottleneck.

A 9-qubit dense all-to-all graph requires every qubit to interact with every other qubit. On a sparse heavy-hex processor, standard compilers inject massive walls of SWAP gates to force these interactions, destroying the state fidelity. Here is the physical result of using Prometheus instead.

Three execution strategies
SABRE O3 and TKET provide general-purpose compilation baselines. Prometheus operates as an execution hypervisor around compilation and routing, selecting a physical realization before dispatch.
Workload9-Qubit Dense (All-to-All) TargetIBM Marrakesh (156Q) PrimitiveSamplerV2 IBM jobdadl5jd1ierc738l1420
Single-Job Hardware Validation
SABRE O3
General-purpose routing baseline
BASELINE

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.

Depth145
2Q gates90
State fidelity0.5738
HOP0.6975
TKET
General-purpose compilation baseline
BASELINE

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.

Depth165
2Q gates123
State fidelity0.5248
HOP0.7339
Prometheus
Quantum execution hypervisor
SELECTED

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.

Depth109
2Q gates74
State fidelity0.7466
HOP0.8425
Why the single-job design matters

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.

Measured execution results
Metric
SABRE O3
TKET
PROMETHEUS
DELTA VS BEST BASELINE
Physical depth
145
165
109
−24.83%
Two-qubit gates
90
123
74
−17.78%
State fidelity
0.5738
0.5248
0.7466
+30.12%
Heavy Output Probability
0.6975
0.7339
0.8425
+14.80%
Total Variation Distance
0.4572
0.5241
0.3015
−34.04%
Cross-Entropy Benchmark
38.3213
31.1110
50.1079
+30.76%
Hardware-weighted cost
0.0510
0.0694
0.0318
−37.65%
Favorable changeUnfavorable changeDelta is relative to the strongest baseline for each metric.
What the benchmark shows

The distinction is not whether the baseline can compile the circuit.

SABRE and TKET both produced executable circuits. This benchmark shows a different outcome when the physical compilation selected by Prometheus is executed on the same processor.

01

SABRE O3

The stronger of the two baseline state-fidelity results in this run, with 145 physical depth and 90 two-qubit gates.

02

TKET

The deepest of the three executions at 165 and the highest two-qubit gate count at 123 in this comparison.

The practical difference

A compiler produces a physical circuit. Prometheus chooses the physical compilation before execution.

This is one physical example from a broader body of comparative experiments. It is not a claim that every workload will produce the same numerical improvement. It demonstrates the problem Prometheus is built to address: the best physical execution is not always completely described by routing cost alone.

Research & Experimental Record

The hypervisor was built from hardware experiments, not assumptions.

Prometheus grew out of an experimental program examining how physical placement, routing cost, hardware conditions, and measured output interact on real quantum processors. The public research record contains five experimental programs, randomized instances, multi-QPU studies, IBM execution evidence, aggregate results, and explicit limitations.

5
Experimental programs in the public research record

The repository separates individual experiments so hypotheses can be tested under different workloads, scales, topologies, and physical processors.

A scientific development loop

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 →
01 · DISTRIBUTION

Distributional concentration

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.

QFT-8 · 100,000 shots · ibm_kingston
02 · ROBUSTNESS

Randomized instance robustness

Matched randomized QAOA and CrossEnt instances test whether observed behavior survives beyond manually selected circuits.

40 matched instances · N=6–9 · ibm_marrakesh
03 · SCALING

Micro-gradient scaling

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.

QFT / QAOA · scaling boundaries
04 · TOPOLOGY

Topological mapping

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.

13 qubits · 80,064 shots · ibm_kingston
05 · MULTI-QPU

Three-QPU mechanistic sweep

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.

3 IBM Heron processors · workload-dependent study
Randomized validation

The experiments were pushed beyond one hand-picked circuit.

In the randomized-instance study, the same logical problems were independently compiled with SABRE O3, TKET, and Prometheus and executed on the same IBM Heron processor. Prometheus recorded higher measured Hellinger fidelity than SABRE O3 in 30 of 40 matched instances. The result is explicitly described in the research record as evidence that the observed behavior is not confined to a small manually selected set, not as universal superiority.

30 / 40Matched instances above SABRE
N = 6–9Randomized workload sizes
Why the research matters

Routing cost is only part of the physical story.

The research repeatedly tests a narrower proposition: minimizing routing cost alone may be insufficient to predict hardware execution quality.

  • Higher routing cost can sometimes coincide with better measured fidelity.
  • The sign of the effect can change with workload size and topology.
  • Global device statistics can miss useful local structure in the physical graph.
  • The same execution philosophy can behave differently on different QPUs.

Public evidence standard

The research repository is designed as an experimental record rather than a public release of the proprietary Prometheus implementation. It preserves enough evidence to inspect the experiments while keeping the execution-selection mechanism protected.

IBM result payloadsReturned execution results are retained where supplied in the research archive.
ProvenanceSafe metadata and SHA-256 evidence indexing support post-publication verification.
Mixed outcomesFavorable, mixed, and negative results remain part of the public experimental record.
Protected implementationProprietary formulation, weighting, heuristics, and physical trajectory artifacts are intentionally withheld.
The public research record explicitly does not claim universal superiority, guaranteed fidelity improvement, or that a single physical variable completely determines execution quality.
Why the Hypervisor Matters

Software and hardware need a better bridge.

A quantum workload may be logically identical while its physical execution changes substantially with topology, hardware conditions, compiler choices, and scale. Prometheus exists in the layer where those software and hardware concerns meet.

For researchers
Benchmark the physical result
Compare execution strategies against real measurements rather than judging a physical circuit from one structural metric.
For platform teams
Add intelligence above the compiler
Introduce a hardware-aware execution layer without requiring application teams to redesign the logical workload.
For enterprise workloads
Use existing QPU capacity more effectively
Treat physical execution quality as an engineering problem, not simply a routing-count problem.
For future processors
Keep the bridge adaptable
The execution layer can evolve as processors, calibration behavior, and compilation environments change.
Get Started

Request access to test Prometheus against your own circuits.

UPLINK execution endpoints are currently restricted. Contact sales to request free trial access, then submit your workload for comparative evaluation on physical quantum hardware.

1

Create an IBM Account

Prometheus dispatches comparative jobs through IBM Quantum. An IBM Quantum account may be required for execution, but UPLINK access is separately controlled by Prometheus Dynamics.

Sign up at IBM Quantum →
2

Authorize execution

Use the credentials required by the execution environment. Keep account credentials private.

3

Request UPLINK Access

UPLINK access is currently restricted. Contact sales to request free trial access to the Prometheus Execution Studio.

Contact Sales →
4

Execute and compare

Compare the physical circuit and measured hardware outputs against your selected baseline.

Enterprise Integration

Add an execution intelligence layer to your quantum stack.

Prometheus Dynamics provides hardware-aware execution infrastructure for teams that need more useful results from existing quantum processing capacity.