NxM-Version Programming for Quantum Software: High-Level Components across Frameworks and Engines

AI summary

Overview

Research area: Quantum Software Engineering, specifically high-level quantum programming tooling, cross-framework interoperability, and multi-version (N-version) execution of quantum programs.

Technical level: Intermediate. The paper assumes familiarity with quantum circuits and gates (Grover's algorithm, Toffoli, QFT adders) and with dataflow programming concepts, but its central argument is about software engineering practice rather than quantum theory.

Scope (1 sentence): The paper presents Quanifi, a library of 108 Apache NiFi processors wrapping five quantum frameworks and two execution-only backends, and evaluates an N×M execution scheme that runs N framework implementations of an algorithm on M execution engines to attribute disagreements to a specific implementation, engine, or implementation–engine pair.

What This Paper Is About

Writing quantum software today requires both quantum mechanics knowledge and fluency in the specific APIs of frameworks such as Qiskit, Cirq, Qrisp, pyQuil and PennyLane, each of which reaches hardware through its own toolchain. The authors apply the low-code/dataflow idea — assembling pre-built blocks on a visual canvas instead of writing code — to quantum computing, packaging each framework's high-level routines as configurable components in Apache NiFi that exchange circuits as OpenQASM 2.0. Because several frameworks implement the same algorithm and several engines can execute the same circuit, the paper crosses these two axes into an N×M matrix of runs, so that a wrong answer can be traced to a builder, to an engine, or to one specific builder–engine pair.

Key Contributions

1. Quanifi processor library. A library of 108 NiFi processors: 80 framework-specific processors wrapping routines from Qiskit, Cirq, Qrisp, PennyLane and pyQuil (as circuit builders, all-in-one algorithms, or execution processors), plus 28 framework-agnostic processors for analysis, comparison, reporting, problem encoding, hardware submission and testing. Amazon Braket and Microsoft Q#/QDK are supported as execution-only backends.
2. Cross-framework interoperability through OpenQASM 2.0. Because every circuit builder can emit QASM2 and every simulator and hardware gateway accepts it, a circuit built by one framework (for example Cirq) can be executed by another framework's simulator or backend, with a shared FlowFile attribute contract (circuit.format, circuit.num_qubits, circuit.depth, sim.shots, sim.top_result, sim.top_probability).
3. N×M program execution. A single NiFi flow that runs each of N framework implementations on each of M engines, producing N×M labelled paths so that failures across a row point to one builder, across a column to one engine, and in a single cell to a builder–engine pair.
4. An evaluation on real quantum computers that found three real defects, one of which the provider confirmed and fixed.

Main Findings

• Two-qubit Grover worked across the board. On the first valid batch per device, every builder reached a success probability between 0.92 and 0.96 for the two-qubit marked states, within 0.05 of the readout baseline, on IBM's ibm_kingston (156 qubits), IQM's garnet (20 qubits) and Quantum Inspire's Tuna-17 (17 qubits), at 1024 shots per circuit.
• Four-qubit Grover was dominated by device noise. On garnet and Tuna-17 the four-qubit success probabilities fell between 0.05 and 0.12, against 0.0625 for a random guess, so the builders could not be meaningfully compared; on ibm_kingston the values ranged from 0.384 to 0.543 against a readout baseline of 0.942 to 0.955.
• Fewer two-qubit gates did not reliably predict a better result. The raw four-qubit circuits already differed (56, 88 and 112 two-qubit gates for Qiskit, PennyLane and Cirq), optimisation left those counts unchanged, and routing added between 18 and 96 gates depending on builder and device — enough to reorder the builders by gate count on garnet and Tuna-17. The one difference above the 0.10 margin (Qiskit ahead of PennyLane by 0.16 on 0110 on ibm_kingston) disappeared in three later batches on new calibrations, where no two builders differed by more than 0.04.
• Identical runs were stable within a batch. The absolute differences between each Qiskit circuit and its exact null replicate ranged from 0.005 to 0.019 on ibm_kingston, 0.004 to 0.012 on garnet, and 0.004 to 0.018 on Tuna-17, all twelve below 0.02; the authors note this describes within-batch variation and does not establish stability across calibrations.
• Defect 1 — a device applying Rx in the wrong direction. On Tuna-17, Cirq's circuits returned incorrect answers for both two-qubit cases: for the marked state 11 the device returned 00 in 94% of shots, and for 10 it returned 01, with success probabilities of 0.006 and 0.012. Cirq emits u3 gates, which the Quantum Inspire adapter rewrote using Rx; negating the Rx angles restored the marked state with probability 0.93, and a three-gate probe whose outcome depends on the Rx sign gave the opposite of its simulation in 93.5% of shots. The result returned no error. Cirq's circuit was also the longest, with 17 gates against 12 for Qiskit and 11 for PennyLane, all three with three two-qubit gates.
• Defect 2 — an adapter advertising unsupported gates. The Quantum Inspire adapter builds its target from a static gate mapping rather than the device's declared gate set, advertising cx, cp and swap for Tuna-17, whose declared two-qubit gate set contains only CZ. Both Quantum Inspire reports were open without maintainer confirmation as of 20 September 2026; working around both defects (transpiling to the declared gate set, excluding Rx) raised Cirq's two-qubit success to 0.93 while the other builders changed by at most 0.02.
• Defect 3 — a cloud service modifying the circuit. A Qiskit-compiled ripple-carry adder on Rigetti's Cepheus-1-108Q returned wrong sums for two of seven inputs: 3+0 gave 111010 (encoding 5) in 44 to 48% of shots across four repeats, while the correct 111100 appeared in at most 3 of 512 shots, and 1+3 gave 100000 (encoding 0). Simulating the circuit with every Rz gate removed reproduced the device's output for all seven inputs. In Experiment 2 on garnet, the same circuit files sent directly through IQM Resonance returned the correct answer as the most frequent outcome with probabilities between 0.73 and 0.88, while through Open Quantum the decomposed CDKM adder gave a wrong sum for 1+0 (probability 0.86), PennyLane's adder returned 00 for every input except 0+0 (probabilities 0.99 to 1.00), the QFT adder's correct-answer probability fell to 0.22–0.31 against 0.25 for random guessing, and undecomposed Toffoli versions succeeded on both routes. No job reported an error or warning. The provider confirmed the defect, traced it to a QASM parsing function, and fixed it on 17 September 2026; all reported Open Quantum results predate the fix.
• Comparison cost. A case requires N×M executions instead of N or M, and comparing every pair of results requires NM(NM−1)/2 comparisons, or 36 for the nine paths in the hardware experiment.

Methodology in Plain English

The authors built Quanifi as a set of plugins for Apache NiFi, an open-source tool where users drag processors onto a canvas and connect them into a pipeline; each processor consumes a unit of data, transforms it, and passes it on. In Quanifi, that unit of data is the quantum artifact itself — a serialised circuit or, after simulation, the measurement counts as JSON — with metadata such as qubit count and circuit depth travelling as attributes. Each processor wraps a real routine from a real framework, so the algorithm logic is the framework's own code rather than a reimplementation, which keeps it traceable when something needs debugging.

Since every builder can write OpenQASM 2.0 and every engine accepts it, the authors use it as the bridge format. (They explain this choice: support for importing OpenQASM 3 is still partial — Qiskit describes its importer as "in its infancy", and in an independent benchmark Qiskit's native parser accepted 2 of 11 OpenQASM 3 test programs against 11 of 11 for the reference parser, while Cirq's importer is also experimental.) Two adjustments were needed: enabling Qiskit's qasm2.LEGACY_CUSTOM_INSTRUCTIONS mapping for gate names emitted by other frameworks, and having the Braket processors transpile incoming circuits down to natively implemented gates rather than inlining gate definitions, because of a global-phase interpretation mismatch that split a four-qubit Grover peak between the marked state and its neighbour.

For evaluation, a GenerateFlowFile processor starts the flow, QuantumTestCaseSource supplies a table of input cases, SplitJson creates one FlowFile per case, and processor properties read values such as the marked state from those attributes. Each case fans out to all builders and then to all engines, and the results meet at QuantumSuccessProbabilityOracle for comparison. For hardware, each device has a submission processor and a polling processor, with job identifiers carried in the FlowFile and NiFi provenance recording builder, device and batch.

Experiment 1 crossed three Grover builders with three quantum computers on four marked states, with 20 circuits per device per batch (12 builder circuits, four readout baselines that prepare the marked state directly, and four null replicates that duplicate the Qiskit circuit). Experiment 2 sent identical circuit files simultaneously to garnet by two routes — directly via IQM Resonance and via the Open Quantum cloud service — with three one-bit adders on four inputs, a standalone Toffoli gate submitted both as ccx and decomposed, and the Grover circuits at 512 shots per circuit. Statistical comparison used a one-sided two-proportion z-test with a Holm correction at a significance level of 0.05 plus a required 0.10 difference. Cost was measured only as circuit runs and shots, not financial cost or waiting time.

Why This Matters

Impact on research. Quantum programs return distributions over measurement outcomes, and a wrong run looks just like a correct one, so deciding whether a result is right is hard. N-version programming and differential testing address this by comparing independent implementations, but quantum software has a second axis — the engine that executes the circuit. The paper shows that crossing both axes turns a vague "the answer is wrong" into a specific attribution, and that this attribution found three defects that single-axis comparison would have missed: Cirq's circuits worked on the other devices, and the other builders worked on Tuna-17, so only the cell isolate the fault.

Real-world applications (as suggested by the work):

• Conformance testing of quantum cloud services and vendor adapters, since two of the three defects were in the service layer in front of the hardware rather than in the hardware itself.
• Validating results from a new device or a new provider route against a known device, as Experiment 2 did by reaching garnet both directly and through Open Quantum.
• Building portable quantum pipelines where the algorithm is specified once at the component level and the framework or backend can be swapped.
• Lowering the entry barrier for developers who know dataflow tools but not the five framework APIs, in the same way SPSS, KNIME, LabVIEW and Node-RED lowered barriers in other domains.

Industry relevance. The defects described are silent failures — the cloud service returned no error or warning, and several wrong answers were more probable than the correct answers obtained through the direct route. For providers, the results point to specific classes of bug worth guarding against: adapters that advertise static gate sets instead of the device's declared set, gate translation that silently substitutes a gate with different semantics, and parsing or transpilation in a service that alters a submitted circuit. The paper notes that the reusable implementation is maintained in the framework repository and that the scripts, archived results, processor snapshot, tests and figures are in a separate replication package, whose supplementary gallery presents executed flows with canvas screenshots, settings and saved outputs without requiring a running NiFi instance.

Future Directions

• Cost and scalability of the matrix. The paper measures cost only as runs and shots; whether N×M execution is practical when N and M grow, and how to prune the matrix without losing attribution power, is left open. Financial cost and queue waiting time were not measured.
• Automated fault localisation. Attribution currently works at the granularity of builder, engine, or builder–engine pair, followed by targeted manual investigation (simulating intermediate stages, negating angles, removing Rz gates). Automating that narrowing-down step is a natural next step.
• Interoperability beyond OpenQASM 2.0. The choice of QASM2 was forced by the immaturity of OpenQASM 3 importers in Qiskit and Cirq and by Braket's phase interpretation; better QASM3 import support would widen the space of circuits that can cross frameworks, and the paper's own gate-name and phase workarounds would need revisiting.
• Comparison when the expected output is unknown. The experiments rely on cases where the correct answer is known (marked states, adder sums, the 111 Toffoli outcome). Extending disagreement detection to algorithms whose expected distribution is not known in advance — the general motivation for N-version programming — remains a challenge.
• Confirmation of the outstanding reports. Both Quantum Inspire reports were open without maintainer confirmation as of 20 September 2026, so the Rx rotation behaviour and the static gate-set mapping await external resolution.

Target Audience

Quantum software engineers and tooling developers who work across multiple SDKs and backends; researchers in quantum software engineering interested in testing, verification and fault localisation for quantum programs; cloud quantum providers and hardware vendors concerned with adapter correctness and silent failure modes; and software engineers with dataflow or low-code experience who want an entry point into quantum programming without learning five framework APIs. Readers seeking quantum algorithm theory or hardware physics will find little of that here — the contribution is engineering practice.

Authors’ abstract

Quantum computing has in recent years evolved from a purely theoretical field to an active area in both academia and industry. As a result, Quantum Software Engineering has emerged as an area that aims to organize the process of building, testing, and running quantum software. However, writing quantum software still requires programming with quantum gates and qubits, as well as knowledge specific to quantum software frameworks such as Qiskit, Cirq, Qrisp, pyQuil and PennyLane, each of which reaches quantum hardware through its own toolchain. We present Quanifi, which packages the high-level routines of these frameworks as components on the Apache NiFi dataflow canvas. The components exchange circuits as OpenQASM 2.0, so a circuit built by one framework can be executed by another. This allows for two types of redundancy: several frameworks implement the same algorithm, and several engines (simulators or real hardware) execute the same circuit. We describe N$\times$M program execution, which crosses the two: a single NiFi flow runs each of the $N$ implementations on each of the $M$ engines, and because every result is labelled with its implementation and its engine, a disagreement can be linked to an implementation, to an engine, or to a single implementation-engine pair. We ran Grover's algorithm built by three frameworks on three quantum computers from IBM, IQM and Quantum Inspire, and a matrix of three adder builders on one IQM device reached through two routes. N$\times$M execution helped us discover three real defects: an incorrect gate-set declaration in the Quantum Inspire adapter, execution consistent with negated $R_x$ angles on Tuna-17, and circuit modification through Open Quantum. The latter two returned wrong answers without reporting an error. We reported all three defects and Open Quantum's provider confirmed and fixed its QASM parsing defect.