How MENOS Executes

Every job goes through the same stages, whether it is a two-qubit circuit or a hundred-qubit one.

1. Convert     Qiskit QuantumCircuit  →  KIR                (Python, menos.qiskit.convert)
2. Validate    KIR well-formed, measurements terminal, output requested
3. Reduce      light-cone reduction: drop operations outside the output's causal past
4. Analyze     interaction graph → connected components; cut search (expectation only)
5. Estimate    each candidate engine prices the job: feasible?, peak bytes, work units
6. Plan        cheapest feasible candidate wins; dense then chooses CPU or CUDA by seconds
7. Execute     run each region on its engine; recombine exactly
8. Monitor     (only with a time budget) compare elapsed time with the budget at safe boundaries
9. Replan      (only on an overrun) observe → same planner → restart, or refuse
10. Report     Result, with explain()

Stages 1 to 6 happen before any simulation work. Stages 8 and 9 exist only for jobs that set a time budget; a job without one runs stage 7 unmonitored and pays nothing for them.

A worked example

Take the 100-qubit brickwork circuit from the MPS example, asked for counts.

1. Convert and validate. 100 qubits, 100 classical bits, measurements at the end.
2. Reduce. Counts on every qubit: the light cone covers everything, so nothing is dropped.
3. Analyze. One connected component.
4. Estimate. The dense engine is refused (checked_pow2: n = 100 exceeds the maximum of 62). The stabilizer engine is refused (operation 0 (ry) is not a Clifford gate). MPS is feasible with a small peak memory.
5. Plan. direct_mps is the only feasible candidate, so it wins.
6. Execute. The MPS engine runs the gates and samples 32 shots.
7. Report. exact=True; 49,792 bytes actually used.

What changes the path

If…	Then…
the circuit splits into independent qubit groups	a factorized plan runs each group on its own engine
you request only an expectation value	Pauli, tensor-network and cut strategies become candidates
you request a statevector	only the dense engine is feasible
a memory budget is too small for every candidate	planning fails with ResourceExceeded before any allocation
a time budget is set	the run is monitored and may be replanned
a CUDA device is usable and faster by the calibrated model	the dense region runs on it

Next

Analyze, Estimate, Plan, Execute, then Monitor and Replan.