TraceQ: Quantum Circuit & Debug Trace Reconstruction

Updated 4 July 2026

TraceQ is a trace-based framework that reconstructs quantum circuit execution structures from minimal binary patch activity traces in FTQC.
It employs reconstruction heuristics like adjacent edge activation and DFS backtracking to resolve ambiguities and detect subroutines through exact subgraph matching.
In software debugging, TraceQ serves as a trace-query model that enables comprehensive, time-ordered exploration of complete program execution traces.

TraceQ denotes a trace-centered approach to recovering or querying execution structure from low-level observations. In fault-tolerant quantum computing, TraceQ is a concrete framework that reconstructs a quantum circuit’s logical dataflow from minimal surface-code access traces, using only binary activity information for patches over time, and then identifies known subroutines by exact subgraph matching (Trochatos et al., 20 Aug 2025). In software debugging and program exploration, the same name is used as a hypothetical label for a trace query engine or query-based debugger whose primary object is a complete execution trace—“every statement in order of execution along with the values of any variables and other expressions it contains”—rather than a conventional source-ordered stepper (Chiplunkar et al., 10 Apr 2026). These usages share a common premise: execution traces can be treated as structured, queryable artifacts from which higher-level control flow, dataflow, and behavioral hypotheses can be derived.

1. Nomenclature and conceptual scope

The primary published use of the name TraceQ is in the fault-tolerant quantum computing literature, where it is introduced as a “trace-based reconstruction framework” for recovering the two-qubit gate-level dataflow of lattice-surgery surface-code programs from minimal access traces (Trochatos et al., 20 Aug 2025). The paper’s central questions are whether one can recover the logical dependency structure of a quantum program from binary patch-activity traces alone, and whether one can efficiently identify known subroutines such as QFT or adders from those traces. The reported answer is affirmative for a broad class of synthetic FTQC benchmarks.

A second usage appears in work on trace-centric software debugging, where “TraceQ” is explicitly presented as a hypothetical system name for a trace query engine or query-based debugger. In that setting, the trace is a complete time-ordered history of executed statements, values, function calls, returns, and control-flow structure; the proposed system centers browsing and querying over that trace rather than over a live process with breakpoints (Chiplunkar et al., 10 Apr 2026).

A concise comparison of these two usages is given below.

Usage	Domain	Central trace object
TraceQ	Surface-code FTQC	Time-indexed patch-activity matrices and reconstructed gate DAG
“TraceQ”-like system	Software debugging	Complete execution trace of statements, values, and nesting

This suggests a shared design orientation: traces are not auxiliary logs but first-class objects from which semantically richer structures are reconstructed or queried.

2. TraceQ in fault-tolerant quantum computing

In the FTQC setting, TraceQ operates on lattice-surgery surface-code executions in which logical qubits are represented by patches on a $2\text{D}$ grid, and logical operations are implemented by merging and splitting patches. The paper defines access traces as time-indexed matrices over the patch grid that record which patches are active at each time step. At the minimal level studied by TraceQ, called Level-1 or L1, each timestep $t$ is represented by a binary matrix

$M_t \in \{0,1\}^{d \times d},$

where $M_t[r,c] = 1$ means patch $(r,c)$ is active and $M_t[r,c] = 0$ means it is idle (Trochatos et al., 20 Aug 2025).

The access traces are deliberately minimal. They are agnostic to which logical qubit is where, which two patches are interacting, routing paths, and gate type. Nonetheless, the framework argues that the resulting space-time patterns encode enough information to recover when, where, and how logical qubits interact. TraceQ therefore attempts to reconstruct an approximate Level-3 trace from L1 data and then derive a directed acyclic graph in which nodes are logical two-qubit gates and edges represent temporal or data dependencies induced by shared logical qubits.

The paper defines three trace levels. L1 records only patch activity. L2 augments this with free/busy status of patch boundaries. L3 augments L2 further with patch roles and an ambiguity bit. In the L3 representation, the paper uses a 7-bit encoding whose most significant bit is an ambiguity flag; the next bits encode whether a patch is a control qubit, target qubit, or connection patch; and the last four bits encode directional connectivity to neighbors. TraceQ’s reconstruction problem is to infer as much of this L3-level information as possible starting only from L1 traces (Trochatos et al., 20 Aug 2025).

The target output is a two-qubit gate DAG. The full trace is written as

$\mathcal{T} = \{ M_1, M_2, \dots, M_T \},$

and TraceQ reconstructs from it a DAG whose nodes represent candidate two-qubit gates and whose edges encode per-qubit ordering constraints. Because multiple disjoint paths may be active in one time slice and because L1 traces are inherently ambiguous, the reconstructed DAG is explicitly ambiguity-aware: ambiguous trace entries may induce multiple candidate gate nodes corresponding to different valid path configurations (Trochatos et al., 20 Aug 2025).

3. Reconstruction heuristics, algorithms, and empirical behavior

TraceQ’s reconstruction pipeline has three main algorithmic layers: trace generation for evaluation, heuristic recovery of L3-like information from L1, and DAG reconstruction followed by subroutine detection. The heuristic stage begins with adjacent edges activation, which marks the edge between neighboring patches as active whenever both patches are active. The paper notes that this heuristic is intentionally generous and “can significantly over-label edges due to the inherent ambiguity of L1 trace.” It then applies local logical-qubit identification, using a $3 \times 3$ convolution kernel to identify active patches with exactly one active neighbor as likely logical endpoints. Finally, a temporal co-occurrence heuristic exploits the fact that logical qubit positions are stationary across timesteps: once a patch is confidently identified as a logical qubit in one timestep, it is treated as such across other timesteps where it is active (Trochatos et al., 20 Aug 2025).

After these steps, TraceQ partitions the inferred adjacency structure into connected components. Within each component it distinguishes known paths from ambiguous regions. For ambiguous entries, it runs depth-first search with backtracking to enumerate all valid non-overlapping path configurations that pair logical endpoints, avoid crossing inactive logical qubits, and explain all active patches in the L1 pattern. For each valid solution, directional connectivity is extracted and encoded into the reconstructed L3 representation. The resulting per-timestep structures are then lifted into a global DAG by maintaining per-qubit histories and inserting dependency edges whenever a qubit participates in successive gate nodes (Trochatos et al., 20 Aug 2025).

Subroutine detection is formulated as exact subgraph isomorphism. The reconstructed program DAG is treated as a large directed graph $G$ , while each known subroutine is represented as a smaller DAG $H$ . The paper uses VF3 for exact subgraph matching and reports that, because matching is exact, there are zero false positives in the experiments: all detected subgraphs correspond to actual inserted subroutines (Trochatos et al., 20 Aug 2025).

The evaluation uses 20 synthetic benchmarks composed from FTQC-relevant subroutines, including adders, product circuits, QFT, and Trotterization steps generated with pyLIQTR. Each benchmark is perturbed by 30 random permutations of qubit indices, giving $t$ 0 different circuits, and is evaluated on three layouts: Square Sparse, Compact, and Intermediate. The reported aggregate subroutine recovery rates differ substantially across layouts.

Layout	Subroutine recovery	Runtime characteristics
Square Sparse	74%	Higher ambiguity; some DFS outliers exceed 100 s and reach about 250 s
Compact	95%	DFS completes in < 1 second for all perturbations; no timeouts
Intermediate	88%	DFS completes in < 1 second; no timeouts

The paper attributes the difficulty of Square Sparse instances to higher ambiguity caused by more routing space and more parallelism. It further reports a strong positive correlation between the number of ambiguous endpoints and DFS runtime. Compact and Intermediate layouts typically stay below 100 ambiguous endpoints and maintain sub-second DFS runtimes, while Square Sparse instances can reach about 600 ambiguous endpoints and multi-hundred-second DFS (Trochatos et al., 20 Aug 2025).

Beyond reconstruction accuracy, the paper frames TraceQ as a side-channel demonstration. It argues that even a single trace per program execution is sufficient, and that processing can be done fully offline, to recover substantial information about a quantum program’s circuit structure and embedded subroutines. From that perspective, minimal binary access traces are treated not merely as diagnostic artifacts but as sensitive observations that can leak algorithmic structure (Trochatos et al., 20 Aug 2025).

4. TraceQ as a trace-query model for software debugging

In software debugging, the hypothetical TraceQ model is grounded in a different trace object: a complete execution trace of a conventional program. The underlying proposal is that a debugging or program-exploration tool should make “a complete history of the program’s execution” its primary abstraction, and that the user should see “every line as executed (in time order) rather than as written (in syntax order)” (Chiplunkar et al., 10 Apr 2026). This is positioned against both traditional step debuggers, which present source code in lexical order and expose time through step commands, and logging, which yields temporal sequences of custom messages whose control flow is often implicit.

The implied trace model is a linear event sequence

$t$ 1

where each event corresponds to one executed statement or subexpression and carries a source location, a time index, environment or value information, and structural links such as parent frame, children, or block boundaries. Because of those structural links, the stack trace at any point can be recovered as “the sequence of enclosing function calls,” while loops, recursion, and nested evaluations can be rendered as a tree of blocks flattened into a time-ordered list (Chiplunkar et al., 10 Apr 2026).

The hypothetical TraceQ system is motivated by a distinction between hypothesis generation and hypothesis testing. Step debuggers, breakpoints, and logging are described as effective for testing a known suspicion at a known point, but weak for generating new hypotheses when one does not yet know where to look or what to inspect. A trace-centric tool is proposed to support hypothesis generation by exposing the whole execution narrative, including dataflow and control flow, in a directly navigable form (Chiplunkar et al., 10 Apr 2026).

The paper outlines query and navigation capabilities that a TraceQ-like system should support. These include indexing by time, by lexical location, and by structural position in the control-flow tree. It proposes structural queries over control flow and values, such as “the first iteration of a given loop in which a given variable is assigned the value null,” or “references to a given variable inside a given recursive function, but not inside its calls to other functions.” Internally, such queries are suggested to use a tree-based selector language analogous to CSS or XPath, with a drag-and-drop interface for composition and direct text editing for advanced users (Chiplunkar et al., 10 Apr 2026).

The corresponding user interface is trace-first. The left pane is the primary trace interface, the vertical axis is time, method and loop headers form a sticky contextual stack, and stepping is replaced by scrolling through a pre-recorded execution. Source code remains present in a second pane for lexical context, and selecting a line in source highlights all of its executions in the trace, while selecting a trace entry jumps back to source (Chiplunkar et al., 10 Apr 2026).

Several other systems in the provided literature illuminate the broader methodological setting in which TraceQ sits. A closely related benchmark direction is TraceEval, an execution-verified multi-language benchmark for code semantic reasoning that formalizes the task of predicting the runtime call graph covered by a particular execution. Its ground truth is defined from a language-specific dynamic tracer as the execution-covered call graph

$t$ 2

where $t$ 3 is the set of validation inputs produced by a harness (Li et al., 10 May 2026). The benchmark contains 10,583 real-world programs from 1,600+ open-source repositories across Python, JavaScript, and Java, and evaluates 10 LLMs in zero-shot settings. The strongest model, Claude-Opus-4.6, reaches an average F1 of 72.9%, while fine-tuning Qwen2.5-Coder-32B on the train split reaches 71.2%, within 1.7 F1 of that zero-shot result (Li et al., 10 May 2026). For TraceQ-like code-semantic systems, this provides an execution-grounded evaluation pattern centered on dynamic trace witnesses rather than static approximations.

An older systems analogue is PreciseTracer, which targets request tracing in black-box multi-tier services. It reconstructs per-request Component Activity Graphs from OS-level SEND and RECEIVE events without source-code access or protocol knowledge, and the paper reports 100% path accuracy on RUBIS under the tested conditions (Zhang et al., 2010). In a different domain, TRacer models account-based blockchain transactions as a directed, weighted, temporal, multi-relationship graph and treats transaction tracing as localized graph search using personalized PageRank. On 20 tracing cases across Ethereum, BSC, and Polygon, it reports 92.31% recall with an average output size of 0.87 K nodes, outperforming BFS, Poison, Haircut, and vanilla APPR baselines on the reported metrics (Wu et al., 2022). At the level of formal semantics, “Generic Trace Logics” develops a coalgebraic framework for reasoning about trace equivalence rather than bisimilarity, defining trace logics as pairs $t$ 4 with

$t$ 5

and showing that such logics are invariant under the corresponding trace semantics (Kissig et al., 2011).

These systems are not instances of TraceQ itself, but they delineate a broad trace-centric landscape: execution-grounded supervision for code reasoning, causal-path reconstruction in distributed services, graph-based tracing on blockchain transaction graphs, and generic logical formalisms for trace semantics.

6. Limitations, security implications, and prospective directions

The FTQC TraceQ framework operates under strong assumptions. It assumes accurate L1 traces with no missing entries or bit-flips, known layout structure and grid size, a focus on two-qubit gates, and traces that abstract away physical noise and decoder failures. Its evaluation traces are generated using a particular A*-based router and greedy scheduler, so different routing or scheduling strategies could alter ambiguity patterns and reconstruction difficulty. The paper explicitly identifies DFS path enumeration as the main bottleneck in highly ambiguous layouts, especially Square Sparse, and does not evaluate robustness to incomplete or noisy traces (Trochatos et al., 20 Aug 2025).

The security implications follow directly from the positive reconstruction results. The paper proposes that per-patch, per-timestep activity traces can act as a side channel through which an observer recovers subroutines or even whole programs. Suggested mitigations are correspondingly trace-centric: restricting or aggregating trace granularity, introducing randomized routing, and limiting access to control-stack data. The paper also points to extensions involving T gates, magic-state access patterns, lower-level lattice-surgery operations, and improved pruning of the DFS search space (Trochatos et al., 20 Aug 2025).

The software-debugging TraceQ model has a different limitation profile. The tracing paper explicitly scopes itself to human-scale programs: up to a few thousand lines of code, runs lasting at most a few seconds, limited use of large libraries, and no emphasis on concurrency or distributed execution. Its back-of-the-envelope estimate assumes a Python interpreter executing $t$ 6 lines per second for 2 seconds and a trace size of 1 kB per executed line, yielding about 2 GB of trace data; the paper presents this not as a guarantee but as a feasibility argument for debugging and exploration workloads (Chiplunkar et al., 10 Apr 2026). It also highlights information overload, the need for lexical context, and the possibility that functional languages may be better served by call-tree tracing than by imperative statement-level traces.

In adjacent benchmark work, TraceEval exposes another limitation relevant to TraceQ-like systems: dynamic ground truth is input-dependent. Execution-covered call graphs deliberately exclude edges that are statically possible but not exercised by the generated harness input, and the paper’s error analysis shows that models often over-predict such untaken branches or mis-handle runtime type dispatch (Li et al., 10 May 2026). This suggests that any generalized TraceQ for code reasoning must be explicit about whether it targets observed behavior under one execution, observed behavior over many executions, or a broader static semantics.

Taken together, the literature presents TraceQ less as a single fixed artifact than as a family of trace-first methodologies. In FTQC, it is a concrete reconstruction framework that turns binary access traces into a two-qubit gate DAG and subroutine matches. In software debugging, it is a hypothetical but technically detailed design for browsing and querying complete execution histories. Across both settings, the governing principle is consistent: the trace is treated as a structured object from which semantically meaningful behavior can be reconstructed, queried, and, in some settings, leaked (Trochatos et al., 20 Aug 2025).