Quantum Software Stack

Short Definition

A quantum software stack is the collection of representations, transformations, runtime services, control interfaces, and evidence records that turn a scientific or computational task into operations on a quantum system and turn the resulting detector records into a qualified answer.

The word stack is useful, but a simple vertical list is incomplete. Some work happens before execution, some must happen while quantum state is still coherent, and some happens after many experimental trials. Calibration, characterization, and execution data also flow upward and change later compilation decisions. A realistic stack is therefore a directed graph with feedback, not a one-way ladder.

A complete path may include

1. an application question and success criterion;
2. an algorithm with input, output, and approximation semantics;
3. a logical program or circuit;
4. a fault-tolerant realization, when error correction is used;
5. target-specific synthesis, placement, routing, and scheduling;
6. a pulse or controller program;
7. analog hardware response and detector inference;
8. classical postprocessing, uncertainty analysis, and provenance.

This page owns the interfaces between those layers: what artifact crosses each boundary, what meaning must be preserved, what target information is consumed, and what evidence must be retained. Circuit Model owns circuit semantics and resource conventions. Universal Gate Sets owns universality and approximation by gate alphabets. Control, Readout, and Calibration owns waveform delivery, detector inference, calibration dependencies, and drift. Hardware Overview owns the physical target contract. Later pages in this chapter develop individual compiler passes, intermediate representations, simulators, and control methods.

One Computation, Three Coupled Planes

A useful architecture separates three coupled planes.

• The translation plane lowers intent into increasingly target-specific artifacts.
• The execution plane dispatches instructions, enforces timing, receives measurements, and performs deadline-bound classical decisions.
• The evidence plane records versions, target state, raw outcomes, acceptance rules, uncertainty, and validation results.

The stack is a lowering path with feedback. Compilation consumes a versioned target contract; real-time measurements can select later operations; and execution evidence updates calibration, compiler policy, and the scientific claim.

None of the planes can be omitted from an end-to-end claim. A compiler output without a target snapshot is ambiguous. A pulse schedule without detector and branch semantics is incomplete. A final number without raw-record provenance cannot establish what was executed.

A Typed Boundary Contract

Let the artifact at layer $i$ be

$$\mathsf A_i = \bigl( x_i,\, \Sigma_i,\, \mathcal C_i,\, \Pi_i \bigr).$$

Here:

• $x_i$ is the representation itself, such as source code, a circuit graph, an instruction stream, a schedule, or a result table;
• $\Sigma_i$ gives its semantics: what physical or mathematical behavior the artifact denotes;
• $\mathcal C_i$ states constraints and assumptions;
• $\Pi_i$ carries provenance, including versions, hashes, timestamps, and transformation records.

A lowering or analysis pass has the schematic form

$$\tau_i: \bigl( \mathsf A_i,\, \Theta_i \bigr) \longmapsto \mathsf A_{i+1},$$

where $\Theta_i$ is the target information visible at that boundary. A hardware-independent pass may use only gate identities. A mapper needs a connectivity graph. A scheduler needs durations and concurrency exclusions. A pulse lowering needs calibrated waveform definitions and controller limits.

For an exact semantics-preserving transformation, the denotations agree on the declared input class. Approximate synthesis or physical lowering instead needs a metric and a budget:

$$d\!\left( \llbracket x_{i+1}\rrbracket_{\Theta_i}, \llbracket x_i\rrbracket \right) \leq \epsilon_i.$$

The brackets mean “behavior denoted by,” not merely textual evaluation. The appropriate behavior might be a unitary channel, a quantum instrument with classical branches, an output distribution, or an estimator. The distance $d$ must match that behavior. Matrix equality is insufficient for a program with measurement, reset, timing, or classical control.

If compatible operational distances are used at every boundary, a triangle inequality can support a conservative ledger such as

$$\begin{aligned} \epsilon_{\mathrm{sem}} &\leq \epsilon_{\mathrm{alg}} +\epsilon_{\mathrm{synth}} +\epsilon_{\mathrm{lower}} +\epsilon_{\mathrm{impl}}. \end{aligned}$$

This expression is a bookkeeping structure, not an automatic experimental error bar. Model mismatch, drift, leakage, correlated faults, and postselection can violate the assumptions used to assign individual terms.

Layer Map

The same application can have several valid decompositions. The following map names the artifacts that should nevertheless be distinguishable.

Layer	Primary artifact	Meaning that must survive	Typical hidden failure
application	problem instance, observable, tolerance, success rule	what question is being answered	optimizing a proxy that is not the stated task
algorithm	mathematical procedure, oracle and data-access contract	correctness and complexity assumptions	treating state preparation or data loading as free
logical program	typed quantum–classical program or ideal circuit	register order, operations, measurement, branches	losing bit order, branch, or parameter semantics
error-corrected circuit	logical gates, syndrome operations, factories, decoder contract	encoded computation and failure budget	counting logical gates but omitting factories or cycles
compiled physical circuit	native operations, placement, routing, schedule	target-equivalent operation under constraints	reporting unscheduled depth or stale topology
pulse schedule	frames, waveforms, acquisitions, timing, conflicts	calibrated control intent	assuming a gate label uniquely fixes a waveform
controller program	executable instructions and real-time branches	deterministic dispatch and deadline behavior	host-side logic arrives after the coherence deadline
hardware response	fields, device dynamics, analog records	actual physical experiment	confusing requested controls with delivered controls
measurement data	classified outcomes plus raw or reduced records	sample identity and acceptance semantics	silently discarding shots or remapping classical bits
postprocessing	estimator, uncertainty, diagnostics, report	answer under declared statistical assumptions	quoting sampling error while omitting implementation bias

The distinction between a logical and physical layer does not imply that every system exposes every intermediate artifact. A service may combine several passes or keep pulse definitions private. The scientific contract still needs enough metadata to identify the semantics, target, transformation policy, and execution conditions.

Application and Algorithm Contracts

Compilation cannot repair an underspecified task. Before a gate is chosen, the application layer should state:

• the problem instance and input encoding;
• the output object, such as a sample, bit string, energy estimate, or decision;
• an accuracy, confidence, or success condition;
• allowed approximation and failure probability;
• the baseline and resource boundary for any performance claim;
• whether adaptation, postselection, or repeated trials are allowed.

The algorithm layer then supplies a mathematical route under explicit access assumptions. A query algorithm may assume an oracle. A chemistry algorithm may assume integrals and a prepared initial state. A variational workflow may assume a classical optimizer and repeated expectation estimates. Those assumptions become software and hardware obligations at lower layers.

For example, Quantum Phase Estimation defines an eigenphase-estimation task. A stack must additionally decide how controlled powers are synthesized, whether measurements are terminal or adaptive, which precision and success probability are required, and where classical branch decisions execute. An asymptotic algorithm statement does not fix those choices.

Logical Programs Are More Than Gate Lists

A useful logical representation must preserve all operations that affect the meaning of the computation:

• quantum and classical data types;
• allocation, reset, measurement, and release;
• tensor-factor and classical-bit order;
• gate parameters and units;
• loops, calls, and classical control flow;
• mid-circuit outcomes and branch conditions;
• timing constraints when they are semantically relevant;
• declared approximation tolerances;
• observable and output mappings.

The no-cloning theorem also changes ordinary compiler intuitions. An optimizer cannot duplicate an unknown quantum value to avoid recomputation. Measurement converts quantum information into a classical record but generally changes the state. Deallocation is not merely dropping a pointer if residual entanglement with live data remains.

An intermediate representation need not be a text file. It may be an in-memory graph, static single-assignment form, region-based program, circuit DAG, or timed instruction structure. What matters is that its operations, types, control flow, and legality rules have a defined semantics.

Intermediate Representations and Interfaces

No single interface spans every layer. Rich high-level forms support abstraction and analysis; lower forms expose target constraints and timing. Premature lowering loses structure that an optimizer could use. Refusing to lower leaves decisions too late for deterministic execution.

Circuit Intermediate Representations is the canonical treatment of representation levels, quantum and classical value models, static single assignment and regions, gate alphabets, capability profiles, lowering invariants, and portability. For the full stack, the important requirement is that every boundary identify its representation and specification version, accepted profile, input and output schema, target assumptions, and preservation obligation. A shared format name alone does not establish that two systems can execute the same behavior.

The Target Is a Versioned State, Not a Device Name

A compiler target is richer than a qubit count or design connectivity diagram. At time $t$, write a target contract schematically as

$$\begin{aligned} \Theta(t) =\bigl(&G_{\mathrm{active}}(t), \mathcal B(t), \mathcal D(t), K(t),\\ &\mathcal M(t), \mathcal R(t), \mathcal F(t), \mathcal L(t)\bigr). \end{aligned}$$

The components can include:

• active topology $G_{\mathrm{active}}$, including disabled resources;
• native operation library $\mathcal B$;
• operation durations and alignment rules $\mathcal D$;
• a concurrency or conflict model $K$;
• characterized error and leakage information $\mathcal M$;
• measurement, reset, and branch capabilities $\mathcal R$;
• calibrated frames, phases, and pulse definitions $\mathcal F$;
• controller memory, bandwidth, and latency limits $\mathcal L$.

The contract must identify its validity interval and calibration epoch. A compiler run against yesterday’s target can be syntactically successful and operationally poor today. Conversely, recompiling every circuit against the latest scalar fidelity table can introduce instability unless uncertainty, drift rate, and pass policy are controlled.

For a modular machine, the target also includes link inventory, heralding, memory age, and contention. Modular Architectures owns those resource and availability models. The software stack consumes a versioned view of them. Distributed Quantum Computing owns the cross-QPU specialization: partitioning, teledata and telegates, entanglement-aware scheduling, failure semantics, and the resulting application-level resource ledger. The present page owns the artifact, interface, and provenance contracts common to local and distributed targets.

Compiler Passes and Their Order

A pass should declare more than its name. A useful contract is

$$\mathsf P_k = \bigl( \operatorname{pre}_k,\, \tau_k,\, \operatorname{post}_k,\, \Delta\mathbf C_k,\, \pi_k \bigr),$$

where the first two fields state preconditions and transformation, the third states guaranteed postconditions, $\Delta\mathbf C_k$ records cost changes, and $\pi_k$ identifies implementation and configuration.

Common pass classes include:

1. parsing, type checking, and canonicalization;
2. inlining, loop handling, and classical simplification;
3. gate or instruction synthesis;
4. algebraic circuit optimization;
5. logical-to-physical allocation;
6. routing or movement insertion;
7. timing and resource-constrained scheduling;
8. frame, pulse, or controller lowering;
9. validation and executable packaging.

Passes generally do not commute. Decomposing a two-qubit gate before choosing an orientation can expose different cancellations than mapping first. Routing can create adjacent inverse gates, so a post-routing optimizer may help. Scheduling can reveal crosstalk conflicts that force a different mapping. Pulse-aware cancellation can be invalid if it ignores virtual-frame state.

The pipeline should therefore record pass order and fixed points. “Optimization level 3” is not a reproducible scientific description unless the corresponding pass set, versions, random seeds, target snapshot, and stopping criteria are known.

Optimization Is Multiobjective

There is no universal “best compiled circuit.” A cost vector might be

$$\begin{aligned} \mathbf C ={}& \bigl( N_q,\, D,\, N_{2q},\, T_{\mathrm{sched}}, \\ &\qquad P_{\mathrm{fail}},\, B_{\mathrm{class}},\, M_{\mathrm{anc}},\, E_{\mathrm{control}} \bigr). \end{aligned}$$

It includes qubits, depth, entangling operations, scheduled duration, modeled failure probability, classical bandwidth, ancillas, and control energy or another infrastructure cost. Different applications and machines assign different priorities.

A scalar objective

$$J=\mathbf w^{\mathsf T}\mathbf C$$

is meaningful only when the weights and normalizations are declared. Otherwise one should retain a Pareto set. A shorter circuit may use noisier edges. A lower-depth schedule may increase simultaneous-operation crosstalk. A fault-tolerant layout with more qubits may reduce runtime by adding parallel factories.

Compilers sometimes estimate a success proxy using

$$P_{\mathrm{succ}}^{(\mathrm{ind})} = \prod_{j=1}^{M} \bigl(1-p_j\bigr).$$

This expression assumes independent error events with meaningful per-operation probabilities. It can rank candidates under that model, but it does not capture coherent accumulation, leakage, spectator effects, correlations, drift, or postselection. Noise in Quantum Information owns the distinction between a compiler noise model and the implemented channel.

Static, Near-Time, and Real-Time Classical Work

“Hybrid quantum–classical” covers several distinct latency regimes.

Regime	Typical work	Timing consequence
compile time	synthesis, mapping, scheduling, resource estimation	can take seconds to hours if the artifact remains valid
submission time	parameter binding, capability checks, executable packaging	occurs before a job enters or leaves a queue
near time	batching, optimizer updates, experiment selection	may occur between circuit executions
real time	measurement classification, reset, feedforward, decoder decisions	must meet a hardware or coherence deadline
postprocessing time	estimators, mitigation, uncertainty, verification	occurs after records are available

Moving a computation to a faster processor does not make it real time unless the data path, synchronization, and dispatch path also meet the deadline. For a measurement-conditioned operation, a minimal latency ledger is

$$\begin{aligned} t_{\mathrm{ff}} ={}& t_{\mathrm{acq}} +t_{\mathrm{digitize}} +t_{\mathrm{classify}}\\ &+t_{\mathrm{decide}} +t_{\mathrm{dispatch}} +t_{\mathrm{propagate}}. \end{aligned}$$

The branch is feasible only if

$$t_{\mathrm{ff}} \leq t_{\mathrm{deadline}},$$

including jitter and a declared margin. A host callback after the job returns is postprocessing, not feedforward. Experimental dynamic circuits show why controller architecture and software are part of algorithm performance, not merely laboratory plumbing.

Branch Semantics and Quantum Instruments

Mid-circuit measurement creates both a state update and a classical record. If outcome $m$ selects a later channel $\mathcal C_m$, the overall operation is not one unitary. It is an instrument-valued computation with branches

$$\mathcal J_m = \mathcal C_m\circ\mathcal I_m, \qquad p_m = \operatorname{Tr}\!\left[ \mathcal J_m(\rho) \right].$$

Here $\mathcal I_m$ is the outcome-resolved measurement operation. Correct lowering must preserve the outcome labels, state-update rule, branch condition, and output record. Quantum Instruments is the canonical home for this formalism.

Mid-Circuit Measurement and Feedforward owns the ideal branch semantics and resource audit that lowering must preserve; this page owns representation, capability negotiation, runtime placement, and executable latency.

Frame updates deserve similar care. A virtual $z$ rotation may change a tracked phase rather than emit a physical pulse. Removing or moving later operations without carrying that frame state can change the implemented computation even when the visible gate count decreases.

Fault-Tolerant Lowering Is a Distinct Branch

A fault-tolerant stack does not simply replace every logical gate by a longer physical gate sequence. It introduces code- and architecture-specific resources:

• encoded preparations and measurements;
• repeated syndrome-extraction schedules;
• decoder throughput and latency;
• Pauli or Clifford frame tracking;
• logical movement, lattice surgery, or teleportation;
• non-Clifford state injection and distillation;
• factory placement, routing, storage, and verification;
• code-distance selection and a computation-wide failure budget.

For a distilled resource with supply rate $\lambda_T(t)$ and scheduled demand $a_T(t)$, a simple inventory model is

$$\begin{aligned} \frac{dB_T}{dt} &= \lambda_T(t)-a_T(t), \\ 0\leq B_T(t)&\leq B_{\max}. \end{aligned}$$

The computation stalls when demand arrives with $B_T=0$, unless the schedule can perform other work. Increasing factory count can reduce stalls but consumes qubits, routing capacity, control bandwidth, and power.

A conservative logical-failure allocation may use a union bound,

$$\begin{aligned} P_{\mathrm{fail}} \leq{}& P_{\mathrm{data}} +P_{\mathrm{factory}} +P_{\mathrm{route}}\\ &+P_{\mathrm{decoder}} +P_{\mathrm{I/O}}. \end{aligned}$$

Each term still needs an operational definition and evidence. Surface Code develops repeated syndrome histories, decoding, logical operations, and overhead for that code family. The present page owns how those artifacts enter the end-to-end software contract.

Runtime and Service Boundaries

After compilation, a runtime must preserve execution semantics under queues, batches, retries, failures, and partial results. A job contract should state:

• executable and parameter hashes;
• target and capability profile;
• requested trials or stopping rule;
• randomization and seed policy;
• queue, start, and completion timestamps;
• timeout, cancellation, and retry semantics;
• whether calibration may change between batches;
• accepted, rejected, and missing trial counts;
• result ordering and classical-register schema;
• error codes and partial-result policy.

Exactly-once submission is not the same as exactly-once physical execution. A network retry can duplicate a request unless job identifiers are idempotent. A controller fault may execute part of a schedule without returning records. The runtime must distinguish “not accepted,” “accepted but not started,” “partially executed,” “executed with missing data,” and “complete.”

For long jobs, batching changes the statistical model. If calibration drifts between batches, outcomes are not identically distributed. Randomizing circuit order and retaining timestamps can make drift diagnosable; averaging away the batch boundary cannot.

Worked End-to-End Example: A Two-Qubit Correlator

Suppose the application asks for

$$C = \langle Z_0Z_1\rangle$$

after preparing a parameterized state $U(\boldsymbol\theta)\lvert 00\rangle$. The application contract specifies $\boldsymbol\theta$, a target uncertainty, confidence convention, and whether mitigation is allowed.

Algorithm artifact

The algorithm prepares the state, measures both qubits in the computational basis, and repeats. For trial $s$, define

$$Y_s = (-1)^{b_{0,s}\oplus b_{1,s}} \in\{-1,+1\}.$$

The logical program must fix which classical bits contain $b_0$ and $b_1$. Reversing a printed bit string is harmless only if the mapping is reversed consistently.

Compiled artifact

The compiler binds logical qubits to physical resources, synthesizes $U(\boldsymbol\theta)$ into the target gate set, inserts movement if needed, schedules gates and measurements, and records:

• the logical-to-physical map;
• native gate and pulse-library versions;
• pass sequence and random seeds;
• active topology and calibration snapshot;
• scheduled duration and operation counts.

The controller executes the schedule for $N$ accepted trials. The result record retains raw or minimally processed outcomes, batch boundaries, timestamps, classification version, and rejection reasons.

Estimator artifact

With counts $n_{00},n_{01},n_{10},n_{11}$,

$$\widehat C = \frac{ n_{00}+n_{11}-n_{01}-n_{10} }{N}.$$

For independent, identically distributed $\pm1$ trials, an estimated standard error is

$$\widehat{\operatorname{SE}}(\widehat C) = \sqrt{ \frac{1-\widehat C^2}{N-1} }.$$

If $N=10\,000$, with $5\,400$ even-parity and $4\,600$ odd-parity outcomes, then

$$\widehat C=0.080, \qquad \widehat{\operatorname{SE}}(\widehat C) \simeq 0.010.$$

A normal approximation would give a nominal 95% sampling interval of roughly $0.080\pm0.020$. That interval does not include compilation bias, gate error, readout bias, drift, or model misspecification. If readout mitigation or postselection is applied, the estimator, acceptance rate, covariance, and uncertainty calculation must all be reported.

This small example exposes the full stack. A mathematically correct correlator can still be wrong because of bit-order metadata, stale mapping, omitted trials, a changed classifier, or an unjustified statistical model.

Separate Statistical Error from Implementation Bias

Let $\mu_{\mathrm{target}}$ be the quantity defined by the ideal task, $\mu_{\mathrm{impl}}$ the expectation generated by the implemented experiment, and $\widehat\mu$ the finite-sample estimator. Then

$$\widehat\mu-\mu_{\mathrm{target}} = \bigl( \widehat\mu-\mu_{\mathrm{impl}} \bigr) + \bigl( \mu_{\mathrm{impl}}-\mu_{\mathrm{target}} \bigr).$$

The first term is sampling fluctuation under a chosen data model. The second is implementation bias, which can include algorithmic truncation, synthesis error, noise, drift, misclassification, and postprocessing assumptions. Increasing the shot count shrinks the first term but does not automatically shrink the second.

A trustworthy stack carries both ledgers. Confidence intervals should identify their sampling assumptions. Validation evidence should bound or diagnose implementation bias. Claims, Hype, and Evidence Standards gives the broader contract for separating theorem, simulation, experiment, benchmark, resource estimate, and application claim.

Portability Has Several Meanings

Portability claim	What it means	What it does not guarantee
source portability	another frontend accepts the source language	identical library semantics or numerical behavior
IR portability	another tool accepts the serialized representation	support for every operation or profile
semantic portability	outputs denote the same task within tolerance	equal gate counts, latency, or fidelity
target portability	a backend can lower the program to its native controls	that the target has enough resources to execute it well
performance portability	costs remain acceptable across targets	identical optimization choices
evidence portability	provenance and result schemas remain interpretable	that experiments at different times are identically distributed

Portability is often achieved by retaining several abstraction levels. A high-level artifact preserves intent; a target-independent circuit supports cross-tool analysis; a target-specific executable supports replay on one configuration. Keeping only the lowest artifact can make future retargeting impossible. Keeping only source code can make a published execution irreproducible.

Verification and Validation

Compiler correctness and hardware validity require different tests.

Frontend and IR tests

• parse and reject malformed programs deterministically;
• enforce type, ownership, and capability rules;
• test serialization round trips;
• preserve source locations and diagnostic context;
• check measurement and classical-register schemas.

Transformation tests

• prove or test pass preconditions and postconditions;
• compare small exact circuits up to global phase;
• use randomized and property-based program generation;
• perform differential tests across independent implementations;
• preserve branch probabilities and conditional outputs for dynamic programs;
• verify schedule resource and timing constraints.

For two unitary circuits, one small-system check is

$$\min_{\phi\in\mathbb R} \left\| U-e^{i\phi}V \right\|.$$

It is inapplicable when either program measures, resets, discards, or branches. Then one must compare channels, instruments, or observable output distributions. Exact state-vector comparison also scales exponentially, so large-program assurance combines formal proofs for trusted passes, structural invariants, specialized equivalence methods, randomized tests, and end-to-end canaries. Verified optimizers such as VOQC demonstrate that useful circuit passes can carry machine-checked semantic proofs, but a verified pass does not verify an unmodeled controller or device.

Runtime and hardware-in-the-loop tests

• validate executable capability before queueing;
• run timing and controller-memory checks;
• use canary circuits for mapping, phase, measurement, and branch semantics;
• compare requested and delivered schedule identifiers;
• detect stale calibrations and disabled resources;
• exercise interruption, retry, and partial-result paths;
• monitor distributions and residuals across batches.

The final validation object is the complete path from declared task to accepted claim. Component tests are necessary but do not substitute for that path.

Provenance and Reproducibility

A reproducibility manifest should be machine-readable and travel with the result. At minimum, retain:

1. problem instance, parameters, and source hash;
2. dependency lockfile and host environment;
3. compiler, simulator, runtime, and firmware versions;
4. pass order, options, random seeds, and IR snapshots;
5. target identifier, capability profile, and calibration snapshot;
6. mapping, schedule, pulse-library, and executable hashes;
7. queue, execution, and batch timestamps;
8. raw-record location and checksums;
9. accepted, rejected, retried, and missing trial counts;
10. postprocessing code, estimator, uncertainty method, and output hash.

Content-addressed artifacts help show which input produced which output. They do not make a noisy experiment deterministic. Reproducibility means that the workflow and evidence can be reconstructed and that expected statistical or drift-induced variation is specified. It does not mean that a future device must emit the same bit string.

For long-lived research, retain both the human-readable report and the machine-readable manifest. A screenshot of a dashboard, an unversioned notebook, or a provider job URL alone is not an archival record.

A Practical Stack Audit

Before accepting an end-to-end result, walk the path in order.

1. Task: Is the input, output, tolerance, and success rule explicit?
2. Algorithm: Are oracle, data-access, approximation, and classical costs included?
3. Semantics: Are register order, measurement, reset, branch, and parameter units fixed?
4. Lowering: Does every pass state preconditions, target data, and semantic obligation?
5. Target: Is topology, operation library, timing, calibration, and controller capability versioned?
6. Schedule: Are dependencies, conflicts, frames, and deadline margins verified?
7. Runtime: Are batching, retries, partial results, and acceptance rules visible?
8. Data: Are raw outcomes, bit mappings, timestamps, and classifier versions retained?
9. Inference: Are sampling uncertainty and implementation bias separated?
10. Evidence: Can the source-to-result artifact graph be reconstructed?

Failure at an early step cannot be repaired by a polished final plot.

Common Mistakes

• Calling a software development kit the whole stack. A client library may expose several layers, but control firmware, target state, runtime services, and evidence storage remain part of the system.
• Treating compilation as one opaque function. Pass order, target snapshot, seeds, and cost objectives affect the output.
• Equating syntax support with semantic support. Parsing a construct does not establish that a backend executes its timing or branch semantics.
• Using device name and qubit count as a target description. Active topology, native operations, conflicts, timing, calibration, and controller limits are required.
• Reporting unscheduled circuit depth as runtime. Durations, concurrency, measurement, reset, feedforward, queueing, and repeated trials all matter.
• Assuming fewer gates means lower error. Gate type, edge quality, idle exposure, coherent cancellation, leakage, and crosstalk can reverse the ranking.
• Moving real-time logic to the host. A fast host response can still miss the quantum deadline because acquisition, network, and dispatch latencies dominate.
• Ignoring virtual frames. Removing visible pulses without tracking phase state changes later operations.
• Compiling a fault-tolerant circuit as if logical gates were physical gates. Syndrome cycles, factories, routing, decoder timing, and failure allocation are separate resources.
• Dropping rejected or missing trials. Selection changes the estimator and can bias the result.
• Quoting shot noise as total uncertainty. More shots do not remove implementation bias or drift.
• Publishing only final source code. Reproduction also needs the compiler, target, executable, raw records, and analysis manifest.
• Assuming one optimization objective is universal. The meaningful output may be a Pareto set rather than one circuit.
• Claiming compiler verification validates hardware. Software proof obligations stop at the modeled interface.

Exercises

1. A report provides a high-level circuit, the device name, and final counts, but no physical mapping, compiler version, or calibration timestamp. Which stack claims can still be checked, and which cannot?

Solution

The logical circuit can be checked for internal gate and measurement semantics if its register order and gate definitions are complete. The final counts can be reanalyzed if their classical-bit schema and acceptance rule are known.

One cannot reconstruct target-specific synthesis, mapping, routing, scheduling, or the active device conditions. Therefore gate counts, depth, runtime, noise-aware choices, and hardware attribution cannot be reproduced. The logical artifact and output table do not establish which physical experiment connected them.

2. Two exact compiler passes satisfy $\llbracket\tau_1(x)\rrbracket=\llbracket x\rrbracket$ and $\llbracket\tau_2(x)\rrbracket=\llbracket x\rrbracket$. Must they produce the same cost when applied in opposite orders?

Solution

No. Semantic preservation does not imply that the transformations commute or have identical cost effects:

$$\tau_2\!\circ\tau_1(x) \neq \tau_1\!\circ\tau_2(x)$$

as representations, even though both can denote the same computation. Decomposition can expose cancellations; routing can create new adjacent gates; and scheduling can constrain later rewrites. Pass order is therefore part of the optimization configuration and provenance.

3. Four compatible approximate lowerings have certified distances $2\times10^{-4}$, $5\times10^{-4}$, $10^{-3}$, and $3\times10^{-4}$. Give a conservative composed bound and state one reason it may not be a complete experimental error estimate.

Solution

The triangle inequality gives

$$\epsilon_{\mathrm{sem}} \leq 2.0\times10^{-3}.$$

This is conservative and valid only for compatible metrics and domains. Unmodeled drift, leakage, correlated faults, detector bias, or a mismatch between the certified model and the physical device can add error not present in the four terms.

4. A feedback path uses $300$ ns acquisition, $80$ ns digitization, $120$ ns classification, $40$ ns decision logic, $90$ ns dispatch, and $70$ ns propagation. The deadline is $900$ ns and the required engineering margin is $15\%$ of the deadline. Is the path admissible?

Solution

The nominal path is

$$\begin{aligned} t_{\mathrm{ff}} &= (300+80+120)\,\mathrm{ns} \\ &\quad +(40+90+70)\,\mathrm{ns} \\ &= 700\ \mathrm{ns}. \end{aligned}$$

The margin is $0.15(900\ \mathrm{ns})=135\ \mathrm{ns}$, so the admissible latency is $765$ ns. Since $700$ ns is below $765$ ns, the nominal design meets the requirement with $65$ ns remaining. Jitter and worst-case rather than mean latencies must still be checked.

5. A compiler estimates candidate success as a product of independent gate success probabilities. Give two physical effects that can make the ranking unreliable even when every marginal gate error estimate is accurate.

Solution

Coherent overrotations can add constructively or cancel depending on sequence and phase, so a product of marginal probabilities misses circuit structure. Simultaneous-operation crosstalk can make a gate’s error depend on the schedule and spectator states. Leakage persistence, common-mode drift, and correlated radiation events are other valid examples.

6. A dynamic program measures a qubit and applies $X$ when the result is one. Why is unitary matrix comparison insufficient for validating a compiler pass that rewrites this fragment?

Solution

Measurement is not a unitary operation on the program’s visible state. It produces an outcome distribution, updates the conditional quantum state, and creates a classical record used by the branch. Validation must compare the outcome-resolved instrument or, at minimum, every branch probability and conditional output channel. A unitary matrix has no place to encode those semantics.

7. A magic-state factory produces one state every $12$ code cycles. The scheduled computation consumes bursts of five states every $50$ cycles. Does the average supply exceed average demand, and is that alone sufficient to avoid stalls?

Solution

The supply rate is $1/12\simeq0.0833$ states per cycle. The average demand is $5/50=0.10$ states per cycle, so supply is already insufficient on average and the buffer will eventually empty.

Even if average supply exceeded demand, it would not alone prevent stalls. Burst timing and buffer capacity matter. The inventory must contain five usable states at each burst, including losses, verification failures, and routing latency.

8. One backend accepts an OpenQASM program but lowers unsupported dynamic branches by splitting it into host-controlled jobs. Another executes the branches in its controller. Which portability claims hold?

Solution

Both may provide source or syntax portability. Semantic portability holds only if splitting preserves the task’s behavior and no deadline is part of the contract. Real-time target portability does not hold: the host-controlled backend cannot implement a coherence-bound branch merely by accepting the source. Performance portability also need not hold because queue and network latency can dominate the split execution.

9. In the correlator example, $N=2\,500$ accepted trials give $n_{00}+n_{11}=1\,450$ and $n_{01}+n_{10}=1\,050$. Compute $\widehat C$ and its estimated standard error under the independent-trial model.

Solution

The estimator is

$$\widehat C = \frac{1450-1050}{2500} = 0.16.$$

Therefore

$$\widehat{\operatorname{SE}}(\widehat C) = \sqrt{ \frac{1-0.16^2}{2499} } \simeq 0.0197.$$

This quantifies sampling fluctuation under the stated model, not readout, compilation, or drift bias.

10. Design a minimal archival bundle for a published hardware run whose compiler uses randomized routing and whose execution spans three calibration epochs.

Solution

The bundle should contain the task and source artifact; dependency and compiler versions; pass list, options, and routing seeds; the input and output IR or their content hashes; one target and calibration snapshot for each epoch; the logical-to-physical map and executable hash for every compiled batch; batch timestamps and job identifiers; raw outcomes with bit schemas, acceptance flags, and checksums; and versioned postprocessing code with estimator and uncertainty configuration.

Because the target changed, outcomes must remain partitioned by epoch for drift checks. A single pooled count table is not sufficient archival evidence.

References

1. F. T. Chong, D. Franklin, and M. Martonosi, “Programming languages and compiler design for realistic quantum hardware,” Nature 549, 180–187 (2017), doi:10.1038/nature23459.
2. A. JavadiAbhari et al., “ScaffCC: Scalable compilation and analysis of quantum programs,” Parallel Computing 45, 2–17 (2015), doi:10.1016/j.parco.2014.12.001.
3. T. Häner, D. S. Steiger, K. Svore, and M. Troyer, “A software methodology for compiling quantum programs,” Quantum Science and Technology 3, 020501 (2018), doi:10.1088/2058-9565/aaa5cc.
4. A. W. Cross et al., “OpenQASM 3: A broader and deeper quantum assembly language,” ACM Transactions on Quantum Computing 3, Article 12 (2022), doi:10.1145/3505636.
5. QIR Alliance, “QIR specification: representation of quantum programs within LLVM IR,” active community specification, accessed August 2026, github.com/qir-alliance/qir-spec.
6. R. S. Smith, M. J. Curtis, and W. J. Zeng, “A practical quantum instruction set architecture,” arXiv:1608.03355 (2016), doi:10.48550/arXiv.1608.03355.
7. C. Lattner et al., “MLIR: Scaling compiler infrastructure for domain specific computation,” in 2021 IEEE/ACM International Symposium on Code Generation and Optimization, 2–14 (2021), doi:10.1109/CGO51591.2021.9370308.
8. A. J. McCaskey, D. I. Lyakh, E. F. Dumitrescu, S. S. Powers, and T. S. Humble, “XACC: A system-level software infrastructure for heterogeneous quantum–classical computing,” Quantum Science and Technology 5, 024002 (2020), doi:10.1088/2058-9565/ab6bf6.
9. X. Fu et al., “An experimental microarchitecture for a superconducting quantum processor,” in Proceedings of MICRO 2017, 813–825 (2017), doi:10.1145/3123939.3123952.
10. X. Fu et al., “eQASM: An executable quantum instruction set architecture,” in 2019 IEEE International Symposium on High Performance Computer Architecture, 224–237 (2019), doi:10.1109/HPCA.2019.00040.
11. T. Alexander et al., “Qiskit Pulse: Programming quantum computers through the cloud with pulses,” Quantum Science and Technology 5, 044006 (2020), doi:10.1088/2058-9565/aba404.
12. A. D. Córcoles et al., “Exploiting dynamic quantum circuits in a quantum algorithm with superconducting qubits,” Physical Review Letters 127, 100501 (2021), doi:10.1103/PhysRevLett.127.100501.
13. E. Bäumer et al., “Efficient long-range entanglement using dynamic circuits,” PRX Quantum 5, 030339 (2024), doi:10.1103/PRXQuantum.5.030339.
14. P. Murali, J. M. Baker, A. Javadi-Abhari, F. T. Chong, and M. Martonosi, “Noise-adaptive compiler mappings for noisy intermediate-scale quantum computers,” in Proceedings of ASPLOS 2019 (2019), doi:10.1145/3297858.3304075.
15. A. Cowtan, S. Dilkes, R. Duncan, A. Krajenbrink, W. Simmons, and S. Sivarajah, “On the qubit routing problem,” in 14th Conference on the Theory of Quantum Computation, Communication and Cryptography, Article 5 (2019), doi:10.4230/LIPIcs.TQC.2019.5.
16. K. Hietala, R. Rand, S.-H. Hung, X. Wu, and M. Hicks, “A verified optimizer for quantum circuits,” Proceedings of the ACM on Programming Languages 5, Article 37 (2021), doi:10.1145/3434318.
17. M. Beverland, V. Kliuchnikov, and E. Schoute, “Surface code compilation via edge-disjoint paths,” PRX Quantum 3, 020342 (2022), doi:10.1103/PRXQuantum.3.020342.
18. M. E. Beverland et al., “Assessing requirements to scale to practical quantum advantage,” arXiv:2211.07629 (2022), doi:10.48550/arXiv.2211.07629.
19. J. P. G. van Dijk et al., “Impact of classical control electronics on qubit fidelity,” Physical Review Applied 12, 044054 (2019), doi:10.1103/PhysRevApplied.12.044054.
20. B. Weder, J. Barzen, F. Leymann, and D. Vietz, “QProv: A provenance system for quantum computing,” IET Quantum Communication 2, 171–181 (2021), doi:10.1049/qtc2.12012.
21. M. A. Nielsen and I. L. Chuang, Quantum Computation and Quantum Information, 10th anniversary ed., Cambridge University Press (2010), doi:10.1017/CBO9780511976667.

Further Connections

• Quantum Information and Computation places software, compilation, control, benchmarking, and resource estimation in the full operational volume.
• Reporting Standards defines the evidence manifest, version identity, access status, and provenance edges that connect artifacts across the stack.
• Circuit Model defines register order, gates, measurements, classical control, and logical, compiled, and physical resource layers.
• Circuit Intermediate Representations defines the typed representation, capability, lowering, and portability contracts carried between stack layers.
• Gate Decomposition develops structure-aware, one- and two-qubit, dense-unitary, and finite-alphabet synthesis with explicit cost and verification contracts.
• Circuit Optimization develops semantics-preserving cleanup, dependency-aware commutation, phase-polynomial and Clifford methods, abstract depth reduction, and translation validation.
• Qubit Mapping and Routing places program qubits, legalizes interactions under target connectivity, tracks map evolution, and emits a verifiable output permutation.
• Error-Aware Compilation turns dated calibration evidence and uncertainty into auditable choices among legal placements, routes, schedules, and gate realizations.
• Pulse-Level Control turns selected gate intent into a typed, timed, frame-aware program of waveform plays, waits, acquisitions, and controller-visible events.
• Calibration Loops keeps target records operational through dependency-aware experiments, drift monitoring, held-out acceptance, atomic publication, and rollback.
• Optimal Control for Quantum Processors compares model-based, reduced-basis, black-box, hybrid, and learning-based searches and carries their candidates through deployment and qualification.
• Quantum Circuit Simulation executes ideal and dynamic circuit IRs using exact state vectors or structure-aware methods with explicit output, accuracy, and resource contracts.
• Stabilizer Simulation turns Clifford closure into bit-packed execution, repeated-shot Pauli-frame sampling, detector records, and a versioned simulator–decoder boundary.
• Tensor-Network Simulation maps typed circuits to MPS or spacetime contractions and carries path search, slicing, sampling, approximation, and resource evidence into the result record.
• Noise Simulation binds versioned noise assumptions to the compiled timeline, selects a suitable execution engine, and records numerical, sampling, truncation, and model error.
• Resource Estimation Tools turns a versioned application, logical program, fault-tolerance model, and hardware scenario into auditable qubit, time, reliability, and tradeoff records.
• Reproducible Notebooks inventories the volume’s planned executable artifacts and defines their convention, environment, validation, provenance, and admission contracts.
• Universal Gate Sets develops exact and approximate universality, synthesis precision, and the distinction between native, compiled, and logical alphabets.
• Multi-Qubit Gates supplies native-versus-compiled gate contracts and connectivity costs.
• Noise in Quantum Information separates characterized components, compiler models, effective channels, and workload-level error.
• Surface Code develops the code cycles, decoder, logical operations, and overhead consumed by a fault-tolerant stack.
• Hardware Overview defines the physical encodings, native controls, topology, timing, infrastructure, and logical-performance target.
• Control, Readout, and Calibration develops the closed loop from waveform intent through detector inference and calibration state.
• Modular Architectures adds stochastic link inventory, queueing, cross-module scheduling, and fault domains to the target contract.
• Claims, Hype, and Evidence Standards defines the evidence needed for theorem, simulation, benchmark, resource, experimental, and application claims.