1 Introduction↩︎

Quantum computing promises major advances in domains such as cryptography, optimization, materials discovery, and machine learning by enabling solutions to problems that are intractable for classical computers [1]–[4]. By leveraging quantum superposition and entanglement, quantum computers have the theoretical potential to deliver dramatic speedups over traditional architectures, motivating major investments from governments, industry, and academia in both quantum hardware and software stacks [5]–[7].

Yet hardware noise remains the primary barrier to practical quantum computing [5]. Gate errors, readout errors, and crosstalk can corrupt nearly every computation on today’s noisy intermediate-scale quantum (NISQ) devices. To execute a useful program, a quantum compiler must map the circuit to the device’s native gate set, assign logical qubits to physical qubits, and route interactions through the hardware coupling graph [8].

Modern compilers make these decisions using calibration-derived noise models. Such models periodically summarize measured device characteristics, including gate error rates, readout fidelities, and coupling information. They therefore enable noise-aware compilation strategies that avoid apparently weak qubits or couplings. Their effectiveness, however, depends on an implicit assumption that the calibration summaries faithfully predict circuit behavior at execution time.

That assumption is often wrong in practice. Calibration-derived noise models are largely context-free. They estimate the average error of individual gates or qubits in isolation, but do not capture how errors change under actual execution context. In particular, they miss execution-dependent effects such as crosstalk [9] between simultaneously active qubits, correlated errors across neighboring couplers, and schedule-dependent interactions with decoherence. As a result, two compiled circuit variants may appear similarly good under the compiler’s noise model, yet behave very differently on real hardware: one executes with acceptable fidelity, whereas the other fails, even though both have the same fidelity prediction under calibration models [10], [11]. The compiler cannot distinguish between them because the relevant error mechanisms are absent from its incomplete noise model.

Consequently, a noise-aware compiler such as Qiskit may still generate and select circuit variants that contain harmful local abnormal patterns overlooked by calibration-based noise models. In our study of IBM’s two backends: ibm_fez and ibm_marrakesh, we find evidence that these are not isolated anomalies, but recurring backend-specific patterns: specific local gate structures mapped onto specific physical neighborhoods that repeatedly exhibit abnormally high error across different circuits and over multiple days. For example, Figure 1 shows on ibm_marrakesh a 4-gate sequence rz\(\to\)x\(\to\)rz\(\to\)cz on two coupled qubits; disrupting it with a single commuting gate swap reduces TVD from 0.058 to 0.032, a 44.5% reduction in excess hardware noise, even though no individual gate in the sequence has an unusually high calibrated error rate. This suggests that real hardware exposes stable, reusable signals about which circuit structures are likely to perform poorly, beyond what is reflected in standard calibration snapshots. If a compiler could retain such signals in a pattern database, it could transform compiled circuits to disrupt known abnormal patterns and steer compilation toward more reliable alternatives.

Isolating such execution-dependent patterns, however, is challenging. First, whether a reduced circuit segment still preserves the same abnormal behavior cannot be decided by a simple binary oracle, but instead requires a statistical comparison between expected and observed outcomes. Second, quantum hardware is inherently unstable: calibration drift and transient fluctuations can easily obscure or mimic true recurring patterns. Pattern extraction therefore requires a method that can distinguish persistent abnormal patterns from ephemeral noise while remaining practical under limited hardware budgets. More importantly, without such a method, quantum compilers remain unable to convert past compilation failures into reusable knowledge: they may continue generating semantically equivalent circuit variants that contain the same abnormal patterns, even when these patterns have repeatedly performed poorly on the target backend.

We present QRisk, a framework for discovering and exploiting persistent abnormal patterns from real hardware executions to improve quantum compilation. QRisk operates in two stages. In the offline stage, it applies a delta-debugging-like reduction procedure to isolate compact circuit fragments that preserve the discrepancy, then validates these fragments across repeated runs and calibration windows to retain only persistent patterns. In the online stage, it scans a compiled circuit for occurrences of known patterns and applies targeted commuting gate swaps to disrupt them, producing a semantically equivalent circuit free of known abnormal patterns.

This paper makes three contributions.

• We present QRisk, a framework that discovers execution-derived persistent abnormal patterns by isolating compact discrepancy-preserving circuit fragments and validating their persistence across calibration windows. On two IBM backends (ibm_fez and ibm_marrakesh), the framework identifies 4-gate patterns that persist across multiple calibration windows over months.

• We validate the discovered patterns through cross-window repetition: independent delta debugging runs in separate calibration windows rediscover the same pattern in 8 out of 10 runs on ibm_fez and 10 out of 10 runs on ibm_marrakesh.

• We evaluate the discovered patterns through controlled scaling experiments using commuting gate swaps on semantically equivalent circuits. On both backends, disrupting patterns reduces excess hardware noise (\(-\)​24% on ibm_fez, \(p = 0.0007\); \(-\)​45% on ibm_marrakesh, \(p < 0.0001\)). Cross-hardware testing on a third backend confirms the patterns are backend-specific.

The rest of this paper is organized as follows. Section 2 provides background on quantum circuits, noise modeling, and compilation, and presents a motivating example. Section 3 details the QRisk framework, including the offline pattern discovery and verification stage and the online pattern-guided circuit transformation stage. Section 4 evaluates QRisk on two IBM backends. Section 5 discusses scope, physical interpretation, and limitations. Section 6 surveys related work, and Section 7 concludes.

2 Background and Motivation↩︎

In this section, we provide the background necessary to understand QRisk. We introduce quantum circuits (Section 2.1), calibration-based noise modeling (Section 2.2), and quantum compilation (Section 2.3). We then present a motivating example that exposes the gap between noise-model predictions and real hardware behavior (Section 2.4).

2.1 Quantum Circuits↩︎

A quantum computation operates on qubits, the quantum analogue of classical bits. Unlike a classical bit, a qubit can exist in a superposition of the \(|0\rangle\) and \(|1\rangle\) states; measuring it collapses the superposition and returns a classical outcome. Computations are expressed as quantum circuits: sequences of quantum gates applied to one or more qubits. Single-qubit gates (e.g., \(X\), \(H\), \(R_z\)) manipulate individual qubits, while two-qubit entangling gates (e.g., CX, ECR) create correlations between qubit pairs.

Mathematically, each quantum gate corresponds to a unitary matrix, and a quantum circuit denotes the matrix product of the gates it contains. Two circuits are therefore considered equivalent if they implement the same overall unitary transformation, even if they use different quantum gate sequences. This notion of equivalence is central to quantum compilation: the compiler may rewrite a circuit into a different but semantically equivalent form in order to satisfy hardware constraints or improve execution quality. For example, the same logical computation may be realized using different decompositions, qubit mappings, or gate orderings, all of which preserve the intended functionality while changing how the circuit interacts with the underlying hardware.

2.2 Quantum Noise Modeling↩︎

Every gate and measurement on NISQ hardware is imperfect. Errors arise from imprecise control pulses, unwanted coupling to the environment (decoherence), and interactions between neighboring qubits (crosstalk) [5]. To account for these errors during compilation, compiler developers use noise models from periodic calibration data. A noise model records per-gate error rates, per-qubit readout fidelities, and \(T_1\)/\(T_2\) coherence times for each physical qubit. Noise-aware compilers use this information to favor low-error qubits and couplers during mapping and routing [12], [13].

A depolarizing channel models gate infidelity: its strength is set to the calibrated error rate (minus the portion already accounted for by thermal relaxation), and it is applied as a 1-qubit or 2-qubit channel depending on the gate arity. A thermal relaxation channel models \(T_1\) amplitude damping and \(T_2\) phase damping during the gate’s execution. For multi-qubit gates, each qubit receives its own independent single-qubit relaxation channel, tensored together with no correlated relaxation. A readout channel applies an independent classical bit-flip to each measurement qubit.

These noise models, however, are inherently context-free. They characterize each gate and qubit independently, ignoring context-dependent effects: crosstalk between simultaneously driven qubits, correlated errors across neighboring couplers, and the interplay between gate scheduling and decoherence.

2.3 Quantum Compilation↩︎

On real quantum hardware, qubits are physical objects with limited connectivity, and not every pair of qubits can interact directly. Instead, interactions are constrained by the device’s coupling graph. A quantum compiler maps a logical circuit onto such hardware by performing three key tasks: (1) qubit mapping, assigning logical qubits to physical qubits; (2) gate routing, inserting SWAP operations so that two-qubit gates act only on connected qubits; and (3) gate decomposition, rewriting operations into the device’s native gate set [8], [14].

These compilation choices directly affect execution fidelity. Even when two compiled circuits are semantically equivalent, they may use different physical qubits, couplers, gate orderings, and SWAP sequences, causing them to accumulate different levels of error. Because of this, modern quantum compilers often use noise models in Section 2.2 to guide mapping and routing decisions, favoring candidates that appear more reliable according to estimated gate and readout errors. As mentioned in Section 2.2, the gap between what the noise model predicts and what the hardware actually produces can be substantial [10], [11]. Two candidates that appear similarly good under the compiler’s noise model may behave very differently on real hardware if one contains abnormal patterns. This gap between model-guided compilation and real-device behavior motivates techniques that can identify and remember recurring abnormal patterns from hardware executions.

2.4 Motivating Example↩︎

Consider a 3-qubit Grover search circuit with one ancilla, compiled to physical qubits 97, 106, 107, and 108 on IBM’s ibm_fez at Qiskit optimization level 3. Qubit 107 couples to all three others. The compiled circuit contains 151 native-gate operations (58 rz, 63 sx, 2 x, 28 cz) plus 3 measurements.

We compile this circuit multiple times and produce 50 semantically equivalent variants. The Qiskit noise simulator that leverages noise model predicts nearly identical error for all of them. This is expected: all variants use the same physical qubits and the same gate types, so the per-gate noise model produces the same prediction.

On hardware, however, the variants diverge. Some match the noise model’s prediction closely, while others show up to 24% more hardware error than the model expects. This gap persists across repeated executions in the same calibration window. The noise model cannot explain it.

Examining the high-error variants reveals a common 4-gate subsequence:

None of these four gates has an unusually high calibrated error rate. The excess error comes from the sequence: single-qubit rotations on two coupled qubits immediately followed by a two-qubit gate between them. The noise model, which scores each gate independently, cannot flag this structure. The compiler treats all 50 variants as equally good, even though a subset consistently performs worse.

3 Approach↩︎

The motivating example in Section 2.4 shows that compiled circuits can contain local gate sequences that cause abnormally high error on hardware, yet appear harmless to the calibration-based noise model. We thus hypothesize that if such sequences recur across circuits and persist across calibration windows, they can serve as actionable signals for effective quantum compilation. The goal of QRisk is to discover these recurring patterns from hardware executions and use them to guide quantum compilation.

QRisk has two stages: an offline stage (Section 3.1) that discovers and verifies abnormal, execution-dependent patterns from noise-model-to-hardware mismatches, and an online stage (Section 3.2) that uses those patterns to transform compiled circuits. Figure 2 shows the pipeline. We explain each step using the Grover circuit from Section 2.4 as a running example.

3.1 Offline Stage: Pattern Identification and Verification↩︎

Two properties of quantum hardware make pattern discovery challenging. First, quantum measurement is inherently stochastic: whether a reduced circuit still exhibits the abnormal behavior cannot be answered by a binary pass/fail oracle, but requires statistical comparison of output distributions. Second, hardware noise drifts over time as calibrations change, so a single observation may reflect a transient fluctuation rather than a persistent pattern.

The offline stage takes a compiled circuit that shows a large gap between its noisy simulation and its real hardware output, and produces a set of verified abnormal patterns. It proceeds in two phases. The first phase, search, uses delta debugging to locate short gate sequences responsible for the gap, with a dynamic oracle that addresses the stochastic nature of quantum outputs. The second phase, verification, repeats the search across multiple calibration windows to retain only persistent patterns. In this way, the search phase addresses the oracle challenge, while the verification phase filters out transient artifacts caused by hardware drift.

3.1.1 Pattern Search via Delta Debugging↩︎

The search phase adapts delta debugging (DDMin) [15] to quantum circuits. In classical software engineering, DDMin systematically removes subsets of a failing input to find a minimal subset that still triggers the failure. We apply the same principle to gate sequences: instead of removing lines of code, we remove segments of gates; instead of checking whether a test case crashes, we check whether removing a segment reduces the gap between the noise model’s prediction and the hardware’s actual behavior.

3.1.1.1 Partitioning the circuit into moments.

Operating at single-gate granularity would require too many oracle calls, each involving a real hardware execution. It would also be conceptually misguided: the calibration-based noise model already captures per-gate error rates, so a single flagged gate carries no new information. The patterns we seek are context-dependent effects that arise from the interaction of multiple gates.

We partition the circuit by moments. A moment groups all gates that can execute in parallel: starting from the linear operation sequence produced by the compiler, each gate is assigned to the earliest moment in which all of its qubits are free. A single moment may contain one operation or several operations on disjoint qubits. We then group consecutive moments into fixed-size segments (default: 3 moments per segment), and each segment serves as one unit for DDMin to remove or retain. Figure 3 illustrates this partitioning on a small example circuit. For the running example, the 151-operation Grover circuit contains 107 moments (parallelism is low because most gates involve the hub qubit), yielding approximately 36 segments of 3 moments each.

3.1.1.2 Ratio-based discrepancy oracle.

Each time DDMin removes a set of segments, the oracle must decide whether the remaining circuit still contains excess hardware noise. The most direct measure would be the Total Variation Distance (TVD) between the noise model’s prediction and the hardware output, \(\mathrm{TVD}(P_{\text{noisy}}, P_{\text{hw}})\). TVD is defined as \(\mathrm{TVD}(p, q) = \frac{1}{2}\sum_{x \in \{0,1\}^n} |p(x) - q(x)|\), where \(p(x)\) and \(q(x)\) are the probabilities of observing bitstring \(x\) under two distributions. However, removing segments shortens the circuit, and shorter circuits accumulate less total error. The raw TVD therefore decreases even when the removed segments are not abnormal, creating a systematic bias toward flagging every segment.

To eliminate this bias, we normalize by the noise model’s own prediction of total error. The oracle computes the ratio of actual hardware error to noise-model-predicted error: \[R(C') = \frac{\mathrm{TVD}(P_{\text{ideal}}(C'),\; P_{\text{hw}}(C'))}{\mathrm{TVD}(P_{\text{ideal}}(C'),\; P_{\text{noisy}}(C'))}.\] This requires three executions per oracle call: an ideal simulation, a noisy simulation using the backend’s most recent calibration data (via Qiskit Aer), and a hardware execution. Both numerator and denominator shrink proportionally as segments are removed, so the ratio stays stable unless the removed segments contain genuine excess error. When \(R \approx 1\), the noise model fully explains the hardware error. When \(R > 1\), there is excess hardware noise. If removing a segment causes the ratio to drop, that segment is responsible for part of the excess.

3.1.1.3 Calibrating the threshold from shot noise.

The ratio \(R\) itself fluctuates due to shot noise, so the oracle needs a threshold to distinguish genuine excess hardware noise from random variation. We calibrate this threshold per circuit before the main DDMin loop. We run two independent noisy simulations (with no real hardware involved) and compute their ratio five times: \[R_{\text{null}} = \frac{\mathrm{TVD}(P_{\text{ideal}},\; P_{\text{noisy,2}})}{\mathrm{TVD}(P_{\text{ideal}},\; P_{\text{noisy,1}})}.\] Because both distributions come from the same noise model with no real hardware involved, any deviation from \(R_{\text{null}} = 1.0\) is due entirely to shot noise. This gives a null distribution: the range of ratio fluctuations expected when there is no excess hardware noise. The threshold is the 2-sigma upper bound of this null distribution minus 1.0: \(\tau = \overline{R_{\text{null}}} + 2\,\sigma(R_{\text{null}}) - 1.0\). Only ratio drops exceeding \(\tau\) are treated as evidence of excess hardware noise. If the full circuit’s baseline ratio satisfies \(R(C) \leq 1.0 + \tau\), the noise model already explains the hardware behavior within shot noise, and the algorithm returns an empty result without running DDMin.

3.1.1.4 Guarding against small-denominator instability.

As DDMin removes segments, the circuit becomes shorter and the noise model predicts less total error, so the denominator \(\mathrm{TVD}(\text{ideal}, \text{noisy})\) shrinks. When the denominator approaches the level of pure shot noise, small random fluctuations in the denominator cause large swings in the ratio, making the oracle unreliable. We set a floor using the same calibration runs from threshold calibration: \(\mathrm{TVD}_{\min} = 2 \times \overline{\mathrm{TVD}(\text{noisy}_1, \text{noisy}_2)}\). The quantity \(\mathrm{TVD}(\text{noisy}_1, \text{noisy}_2)\) measures the variation between two independent samples from the same noise model, which is pure shot noise (approximately 0.006 at 8,192 shots). Any denominator below twice this level no longer carries a meaningful signal. DDMin skips reduction steps where the denominator falls below this floor.

DDMin maintains a candidate set of segments and a partition count \(n\). It narrows the set when removing a group causes \(R\) to drop, or when removing the complement causes \(R\) to drop. It also narrows to a group when that group alone preserves the elevated ratio. Algorithm 4 gives the full procedure.

3.1.1.5 Running example: localizing the pattern in grover algorithm.

The 151-operation Grover circuit spans 107 moments and is partitioned into approximately 36 segments of 3 moments each. The oracle first measures the full circuit’s baseline ratio: \(R(C) = 1.3\), which exceeds the calibrated threshold (\(1.0 + \tau\)), confirming the presence of excess hardware noise.

DDMin begins by splitting the 36 segments into two halves and removing the first half. If the ratio of the remaining circuit stays high, the abnormal segments lie in the second half, and the first half is discarded. The algorithm repeats this binary search, progressively narrowing the candidate set. At each step, the oracle runs an ideal simulation, a noisy simulation, and a hardware execution on the reduced circuit to recompute \(R\).

After several narrowing rounds, DDMin converges to a single segment covering moments 14–16 (4 operations). Removing this segment causes the ratio to drop close to 1.0; keeping it preserves the elevated ratio. The segment is exactly the 4-gate pattern shown in Section 2.4. Moment 14 contains two parallel single-qubit gates on qubits 107 and 108, moment 15 contains one rotation on qubit 107, and moment 16 contains the two-qubit gate between them.

3.1.2 Pattern Verification via Cross-Window Repetition↩︎

A single DDMin run is not sufficient evidence of a persistent hardware effect. Shot noise can make a harmless segment look abnormal in one execution, and calibration drift can make a genuinely abnormal segment appear normal in another. A candidate pattern discovered once may reflect a transient fluctuation rather than a real hardware characteristic. Trusting such a one-time observation would pollute the pattern database with false positives. In our experiments, approximately 29% of flagged segments appeared in only one out of three runs and were discarded as transient noise.

A recurring abnormal pattern should not depend on a single observation. Alghmadi et al. [16] establish this principle in the context of performance testing: rather than relying on any individual measurement, they determine whether an observed phenomenon recurs across repeated, independent observation periods. Similar methodologies for non-deterministic cloud systems [17], [18] confirm that measurements subject to environmental variation require testing across multiple time intervals before results can be trusted. We apply the same reasoning to quantum hardware. Instead of asking whether a single DDMin run produces a statistically significant ratio, we ask whether independent DDMin runs in different calibration windows repeatedly rediscover the same candidate pattern. Repeated rediscovery across independently calibrated hardware sessions is evidence of a persistent hardware effect; a pattern that appears only once is discarded as noise.

Concretely, QRisk runs DDMin on the same circuit once per week, each in a different calibration window. Each run performs its own baseline measurement and threshold calibration, then searches for abnormal segments from scratch. The per-run oracle threshold \(\tau\) filters out random shot-noise fluctuations within a single run, but a pattern enters the database only if it is independently flagged in other runs. The flagged gate subsequence, together with its qubit assignment and backend identifier, is stored as a database entry.

3.1.2.1 Running example: verifying persistence.

We ran DDMin on the Grover circuit 10 times across independent calibration windows from November 2025 to March 2026 on ibm_fez. The segment covering moments 14–16 (the 4-gate pattern) was flagged in 8 out of 10 runs (80%), the highest consistency among all segments. This consistent signal across independently calibrated hardware sessions over 4 months provides strong evidence that the pattern reflects a persistent hardware effect rather than transient noise.

3.2 Online Stage: Pattern-Guided Circuit Transformation↩︎

The offline stage produces a pattern database of persistent abnormal gate sequences. The online stage uses this database to guide compilation. Given a source quantum program and a target backend, QRisk first compiles the program once using the standard compiler (Qiskit optimization level 3). It then scans the compiled circuit for occurrences of known patterns and applies targeted gate reorderings to disrupt them. This mechanism can be implemented as a dedicated Qiskit compilation pass, allowing pattern-aware transformations to be incorporated directly into the existing compiler workflow.

3.2.0.1 Disrupting patterns via commuting gate swaps.

Two adjacent gates in a circuit can be safely swapped whenever they commute as operators. This holds when both gates are diagonal in the computational basis (e.g., rz and cz), even if they share a qubit. In this case, swapping the two gates preserves the circuit’s semantics and depth; only the gate ordering changes.

For each pattern occurrence found in the circuit, QRisk identifies commuting gate pairs within or adjacent to the pattern and swaps them to break the contiguous subsequence. The transformation terminates when no pattern occurrence remains, or when no further commuting swap can disrupt the remaining occurrences. Because every swap preserves semantic equivalence, the output circuit computes the same function as the input.

3.2.0.2 Running example: disrupting the pattern.

The compiled Grover circuit (151 operations) contains one occurrence of the 4-gate pattern at positions 34–37. QRisk disrupts this pattern with a single commuting swap. On qubit 107’s timeline, rz(107,0.393) and cz(108,107) are adjacent (the intervening sx(108) acts only on qubit 108 and occupies a separate parallel moment). Both rz and cz are diagonal in the computational basis, so they commute even though they share qubit 107. Swapping them yields the transformation shown in Figure 5.

The original 4-gate subsequence no longer appears as a contiguous block. The circuit is semantically equivalent but free of the abnormal pattern.

4 Evaluation↩︎

In this section, we evaluate QRisk empirically. We describe the experimental setup (Section 4.1), then evaluate whether the offline stage can discover abnormal patterns (Section 4.2) and whether those patterns persist across calibration windows (Section 4.3). Finally, we assess whether disrupting the patterns through commuting gate swaps reduces excess hardware noise (Section 4.4).

4.1 Setup↩︎

The QRisk prototype is implemented in Python on top of Qiskit [19]. Table 1 summarizes the key parameters.

4.1.0.1 Backends and simulation.

We run experiments on two IBM quantum computers: ibm_fez and ibm_marrakesh, both 156-qubit Heron processors. Circuits are compiled with Qiskit’s transpiler at optimization level 3, producing circuits in each backend’s native gate set. Noisy simulation uses Qiskit Aer with a noise model built from the backend’s most recent calibration data. Each execution uses 8,192 shots.

4.1.0.2 Workload.

All experiments use 3-qubit Grover search circuits with one ancilla qubit (4 physical qubits total) to isolate the recurring abnormal hardware patterns. We evaluate QRisk on different qubit layouts and backends to test generalization.

4.1.0.3 Metric.

Our primary metric is \(\mathrm{TVD}(\text{noisy}, \text{real})\), the discrepancy between what the noise model predicts and what the hardware actually produces (see Section 3.1.1 for the TVD definition). Higher values indicate more excess hardware noise.

4.2 Pattern Discovery↩︎

We evaluate whether QRisk’s offline stage can discover abnormal patterns from hardware executions.

4.2.0.1 Discovery on ibm_fez.

We compiled a 3-qubit Grover circuit (with one ancilla qubit) to physical qubits 97, 106, 107, and 108 on ibm_fez (qubit 107 couples to all three others; 28 CZ gates). The compiled circuit contains 36 segments of 3 moments each, with a baseline discrepancy ratio \(R = 1.3\). A single DDMin run converges in 5 steps and identifies 3 abnormal segments out of 36. Table 6 lists the candidate segments from this representative run. The candidates cluster in a contiguous region (segments 4–6), suggesting a localized source of excess hardware noise. No single CZ qubit pair was dramatically enriched in abnormal segments (enrichment ranged from 0.67x to 1.26x), suggesting the issue is not a simple qubit-pair calibration problem but involves the sequential context of gates.

4.2.0.2 Discovery on ibm_marrakesh.

To test whether QRisk can discover patterns on a different backend, we ran the pipeline independently on ibm_marrakesh with a different qubit layout (qubits 6, 7, 8, 17). The compiled circuit contains 37 segments with a baseline ratio \(R = 1.38\). A single DDMin run converges in 6 steps and identifies 3 abnormal segments. Table 7 lists the candidate segments. As on ibm_fez, the candidates cluster in a contiguous region (segments 6–8).

4.3 Pattern Verification↩︎

We evaluate whether the discovered patterns persist across independent calibration windows.

4.3.0.1 Cross-window verification on ibm_fez.

We ran QRisk on the same Grover circuit 10 times across independent calibration windows from November 2025 to March 2026 on ibm_fez. Table 2 summarizes the abnormal segments identified in each run. Segment 5, which contains the 4-gate pattern, was flagged in 8 out of 10 runs (80%), the highest consistency among all segments. The adjacent segments 4 and 6 were flagged in 70% and 60% of runs respectively. Segments outside the 3–7 region appeared in at most 20% of runs, indicating they are transient artifacts filtered out by repeated verification.

4.3.0.2 Cross-window verification on ibm_marrakesh.

We performed the same repeated verification on ibm_marrakesh across 10 independent calibration windows from November 2025 to April 2026. Table 3 summarizes the results. Segment 7, which contains the 4-gate pattern, was flagged in all 10 out of 10 runs (100%), the highest consistency among all segments. The adjacent segments 6 and 8 were flagged in 50% and 60% of runs, respectively. Segments outside the 6–8 region appeared in at most 20% of runs.

Finding. On two independent backends, QRisk discovers 4-gate patterns that persist across multiple calibration windows. On ibm_fez, segment 5 (the 4-gate pattern) was flagged in 8 out of 10 runs over 4 months. On ibm_marrakesh, segment 7 (a different 4-gate pattern) was flagged in 10 out of 10 runs over 5 months.

4.4 Pattern-Guided Circuit Transformation Effectiveness↩︎

We evaluate whether disrupting discovered patterns through commuting gate swaps reduces excess hardware noise on hardware. For each backend, we generate 10 compiled circuits that contain 3 occurrences of the discovered pattern. For each of them, we use commuting gate swaps to generate semantically equivalent variants where 0, 1, and 2 survive as contiguous subsequences. All variants have the same gate composition, circuit length, and computation. We executed them (40 total per backend) in a single calibration window, with execution order shuffled to control for hardware drift.

4.4.0.1 Scaling on ibm_fez.

The circuit has 453 operations with 3 occurrences of the 4-gate pattern. Starting from the original circuit (3 occurrences, \(\mathrm{TVD}(\text{simulator}, \text{real}) = 0.066\)), QRisk progressively eliminates pattern occurrences via commuting gate swaps. Each elimination reduces hardware noise: \(0.066 \to 0.059 \to 0.052 \to 0.050\), a 24% reduction when all 3 occurrences are disrupted (Figure 8 (a)). The noise model predicts nearly identical error across all groups, confirming that the excess is entirely due to hardware noise not captured by the model. In short, we eliminate all 3 patterns in the target circuit in less than 1 second.

4.4.0.2 Scaling on ibm_marrakesh.

The circuit has 474 operations with 3 occurrences of the ibm_marrakesh pattern. We generated 40 variants (10 per group) using the same methodology. Starting from 3 occurrences (\(\mathrm{TVD}(\text{simulator}, \text{real}) = 0.058\)), QRisk reduces hardware noise from \(0.058 \to 0.045 \to 0.033 \to 0.032\), a 45% reduction when all occurrences are eliminated (Figure 8 (b)). The noise model again predicts constant noise rate across groups (\(\mathrm{TVD}(\text{ideal}, \text{simulator}) \approx 0.084\)).

4.4.0.3 Transformation result.

The mean \(\mathrm{TVD}(\text{noisy}, \text{real})\) on ibm_fez drops from 0.066 (3 occurrences) to 0.050 (0 occurrences), a 24% reduction in excess hardware noise. On ibm_marrakesh, it drops from 0.058 to 0.032, a 45% reduction. In both cases, the noise model predicts identical quality for all variants, so the improvement is entirely due to avoiding execution-dependent errors that the noise model misses. The transformation itself is purely classical and takes under one second on a single CPU core.

4.4.0.4 Statistical significance.

Table 4 reports statistical tests across all 40 individual circuits per experiment (\(N{=}40\) per backend). Both ibm_fez and ibm_marrakesh show statistically significant Spearman correlation between pattern count and excess hardware noise (\(p < 0.01\)), and significant Mann-Whitney U tests between the 0-occurrence and 3-occurrence groups. The Kingston cross-hardware control (discussed below) shows no significant effect, as expected.

4.4.0.5 Noise model blindness.

The noise model’s prediction \(\mathrm{TVD}(\text{ideal}, \text{noisy})\) shows no correlation with pattern count on any backend (Table 4, middle columns). The calibration-based noise model assigns nearly identical predicted error to all variants regardless of how many pattern occurrences they contain. This confirms that the patterns represent a class of error that per-gate noise models fundamentally cannot capture.

4.4.0.6 Nonlinear scaling behavior.

On both backends, the transition from 0 to 1 pattern occurrence produces a small increase that falls within the per-group standard deviation (fez: +0.002, marrakesh: +0.001), while the transitions from 1 to 2 and from 2 to 3 produce substantially larger jumps (fez: +0.007 each step, marrakesh: +0.012 and +0.013). This nonlinear onset is consistent across both backends. A single pattern occurrence contributes hardware error on the order of the shot-noise floor (standard deviations range from 0.003 to 0.018), so its effect is difficult to distinguish from random variation. As occurrences accumulate, the cumulative excess grows well beyond this floor: on ibm_fez, from +0.002 (1 occurrence) to +0.016 (3 occurrences); on ibm_marrakesh, from +0.001 to +0.026. The pattern does not need to be individually catastrophic to matter: its effect is small per occurrence but compounds across a circuit.

4.4.0.7 Cross-hardware control on ibm_kingston.

To check whether the discovered patterns reflect chip-specific defects rather than universal gate-sequence properties, we ran the same ibm_fez scaling circuits (453 ops, pattern count 0–3, 10 per group) on a third backend (ibm_kingston, 156-qubit Heron) using the same qubit positions (97/106/107/108). Figure 8 (c) shows no monotonic trend: \(0.056 \to 0.055 \to 0.053 \to 0.059\). The overall change from 0 to 3 occurrences is +6%, well within the per-group standard deviation. The Spearman correlation is \(\rho = 0.187\) (\(p = 0.248\)), far from significant. The noise model predicts nearly identical error across all groups (\(\mathrm{TVD}(\text{ideal}, \text{noisy}) \approx 0.075\)). The pattern that causes 24% excess hardware noise on ibm_fez produces no measurable effect on a different chip at the same qubit positions, confirming that the pattern is backend-specific. This result also serves as a false-positive control: the same experimental methodology, applied to a backend where the pattern is not abnormal, correctly returns no signal.

5 Discussion↩︎

In this section, we discuss how QRisk integrates into broader compilation workflows (Section 5.1), what the discovered patterns may reveal about the underlying hardware (Section 5.2), and the limitations of the current transformation strategy (Section 5.3).

5.1 Scope and Integration↩︎

QRisk does not replace the noise model. It supplements it with empirical evidence about local gate sequences that the per-gate model cannot capture. The approach is most effective when the compiled circuit contains patterns that can be disrupted by commuting gate swaps. QRisk acts as a post-compilation transformation layer: it does not modify the compiler’s mapping or routing decisions, only the gate ordering in the final circuit. A future compiler could incorporate pattern-derived risk directly into layout and routing decisions; the current design isolates the marginal value of the pattern database as a controlled first step.

The pattern database is backend-specific and must be rebuilt for each target quantum computer. Our cross-hardware experiment (Section 4.4) confirms this: a pattern verified on ibm_fez produces no effect on ibm_kingston at the same qubit positions. The database is also time-sensitive. Patterns persist across calibration windows over weeks in our experiments, but hardware upgrades or recalibrations could invalidate entries. Periodic re-validation is needed in a production deployment.

5.2 Physical Interpretation↩︎

The pattern database is empirical compiler knowledge, not a physical explanation of device behavior. A database entry records that a specific gate subsequence on a specific qubit neighborhood has repeatedly produced an abnormal error rate. This evidence is operationally useful even without knowing the root cause.

The physical mechanism likely involves one or more of: crosstalk between microwave drive lines on adjacent qubits [9], non-Markovian memory effects where residual qubit excitation from one gate affects the next [21], or coherent error accumulation in specific gate orderings. The backend-specificity of the patterns (different chips produce different patterns on the same qubit positions) is consistent with chip-level fabrication variation.

5.3 Transformation Scope and Extensions↩︎

The online stage currently disrupts patterns using commuting gate swaps: a gate slides past consecutive neighbors via diagonal-basis commutation rules (Section 3.2). This approach is sufficient for the patterns discovered in our evaluation, where at least one gate in each pattern has commuting neighbors that allow it to be moved outside the contiguous pattern. The transformation preserves the circuit’s gate composition and depth exactly.

This strategy has a clear limitation: if a pattern contains no commuting gate pair, commuting gate swaps cannot disrupt it. For example, a pattern consisting entirely of non-commuting gates on the same qubit (e.g., sx followed by cz on a shared qubit) would be immune to reordering. We have not encountered such patterns in our experiments, but they may arise on other backends or with different circuit families.

6 Related Work↩︎

In this section, we situate QRisk within four areas of related work: quantum program testing and debugging, hardware noise characterization, noise-aware compilation, and delta debugging.

6.0.0.1 Quantum program testing and debugging.

Several lines of work address fault detection and localization in quantum programs, including assertion-based checking, metamorphic testing [22], [23], differential testing [24], and failure localization [25]–[27]. Ramalho et al. [28] survey the field. These techniques aim to diagnose faults in a single program or execution. QRisk shares the goal of reducing anomalous behavior to interpretable evidence, but uses the result differently: the output is not a bug report but a reusable pattern database that guides future compilation.

6.0.0.2 Hardware noise characterization.

Calibration data, process tomography, randomized benchmarking [29], [30], and simulator derived noise models [10] provide per-gate and per-qubit error estimates that underpin noise-aware compilation. Crosstalk characterization [9], [21] has shown that simultaneously driven qubits produce correlated errors not captured by independent noise channels, but this knowledge has not been systematically fed back into compilation decisions. QRisk targets exactly this gap: it discovers context-dependent error patterns from real executions that calibration-based models miss.

6.0.0.3 Noise-aware compilation and candidate selection.

Noise-aware compilation uses backend calibration data to guide qubit mapping, routing, and gate scheduling [12]–[14], [31]–[33]. These techniques select low-error qubits and couplers based on per-gate error rates. ForeSight [34] generates multiple routing candidates and ranks them by estimated gate count to reduce SWAP overhead. QRisk differs in two ways: it scores circuits by hardware-derived pattern evidence rather than calibration estimates, and it captures structural risks (gate-sequence effects) that per-gate scoring cannot represent.

6.0.0.4 Delta debugging and program reduction.

Delta debugging (DDMin) [15] finds a minimal failure-inducing subset of an input by systematically removing elements. Extensions include hierarchical reduction (HDD) [35], probabilistic search (ProbDD) [36], caching-based acceleration (RCC) [37], and syntax-aware reduction (Perses) [38] with later refinements [39]–[43]. QRisk inherits the core insight that large failing artifacts can be reduced to compact suspicious fragments, but adapts the technique to a stochastic setting: the oracle compares output distributions rather than checking a binary pass/fail condition, the signal must be distinguished from shot noise and hardware drift, and the goal is not to minimize a single failing input but to extract a reusable pattern for compilation guidance.

7 Conclusion↩︎

Quantum compilers generate equivalent circuits but have no way to remember which gate sequences repeatedly cause excess noise on hardware. Calibration-based noise models score each gate independently and cannot capture context-dependent effects. QRisk fills this gap by using delta debugging to isolate short gate sequences that produce excess hardware noise, validating their persistence across calibration windows, and storing them in a backend-specific pattern database. At compilation time, QRisk scans a compiled circuit for known patterns and applies targeted commuting gate swaps to disrupt them, producing a semantically equivalent circuit with fewer abnormal patterns.

We evaluated QRisk on two IBM backends. On ibm_fez, disrupting a 4-gate pattern reduces excess hardware noise by 24% (Spearman \(\rho = 0.515\), \(p = 0.0007\)). On ibm_marrakesh, disrupting a different pattern reduces it by 45% (\(\rho = 0.711\), \(p < 0.0001\)). Both patterns persist across multiple calibration windows over months, while the noise model predicts identical error for all equivalent circuits. Testing the ibm_fez pattern on a third backend (ibm_kingston) shows no effect, confirming that the patterns are backend-specific. Pattern-guided circuit transformation achieves these reductions with negligible classical overhead.

References↩︎