Observing the Quantum Compiler through Automatic Experiment Tracking for Qiskit

arXiv:2608.05041v1 [quant-ph] 5 Aug 2026

Observing the Quantum Compiler through Automatic Experiment Tracking for Qiskit Vlad Stirbu

Arianne Meijer–van de Griend

University of Jyväskylä Jyväskylä, Finland vlad.a.stirbu@jyu.fi

University of Helsinki Helsinki, Finland ariannemeijer@gmail.com

Abstract—Understanding the effectiveness of quantum compilation techniques requires visibility into the entire transpilation process, not just the final circuit metrics. This demonstration presents an MLflow-inspired autologging framework for Qiskit that automatically captures compiler provenance, including transpilation stages, pass-level execution data, backend characteristics, compiler configuration, and execution results. The framework extends the QProv provenance model with compilerspecific information and stores the collected data in an MLflow Tracking Server for analysis and visualization. By eliminating manual instrumentation, the proposed approach improves compiler observability and supports reproducible evaluation of quantum compilation workflows. Index Terms—quantum compilers, observability, experiment tracking

This paper presents an automatic compiler observability tool for Qiskit that brings MLflow-inspired autologging capabilities to quantum compilation experiments. By transparently instrumenting the transpilation workflow, the tool automatically records compiler provenance without requiring extended modifications to the user code. The collected information is integrated into a structured experiment log and complemented by visualizations, such as transpilation timelines, that help researchers analyze compiler behavior, compare optimization strategies, and reproduce quantum compilation experiments.

I. I NTRODUCTION

The design of the proposed framework is guided by three principles that aim to balance ease of adoption with comprehensive compiler observability. • Minimal developer effort. The primary objective is to minimize the effort required to instrument quantum applications. Inspired by MLflow autologging, the framework automatically intercepts key stages of the Qiskit transpilation and execution workflow, collecting provenance transparently without requiring developers to modify their application code. Enabling experiment tracking therefore consists of a single call to activate autologging, allowing existing quantum programs to benefit from comprehensive provenance collection with minimal changes. • Comprehensive provenance. The framework is designed to capture the complete context of a compilation experiment while remaining compatible with the QProv provenance model. Existing QProv entities describing the quantum program, execution environment, backend, and results are preserved, while compiler-specific information is incorporated through schema extensions rather than modifications. In particular, the framework augments the Compilation section with transpilation stage plans and pass-level execution records, providing sufficient information to reconstruct and analyze the compilation process while maintaining interoperability with QProvbased tools and analyses. • Extensibility to other SDKs. Although the current implementation targets Qiskit, the architecture is designed to support additional quantum software development kits.

Quantum compilation has become a critical component of the quantum software stack, bridging high-level quantum programs and the hardware-specific circuits that can be executed on today’s quantum processors. As quantum compilers continue to evolve, researchers increasingly evaluate new synthesis, mapping, routing, and optimization techniques targeting diverse hardware architectures and compiler configurations. Consequently, benchmarking and resource estimation have become central activities in quantum compilation research, requiring software tools that support systematic experimentation and reproducible evaluation. Despite this need, evaluating compilation techniques requires considerably more than reporting the final circuit depth, gate count, or execution fidelity. Understanding why a compiler produced a particular result requires visibility into the complete compilation process: which transpiler passes were executed, how each pass transformed the circuit, the execution time of individual passes, the characteristics of the target backend, the compiler configuration, and the provenance of the entire experiment. Although frameworks such as Qiskit expose much of this information internally, collecting it currently requires substantial manual instrumentation, making comprehensive experiment tracking difficult to adopt consistently and increasing the effort required to reproduce and compare compilation studies. This work has been supported by the Academy of Finland (project DEQSE 349945) and Business Finland (EM4QS 155/31/2024).

II. D ESIGN A. Principles

Qiskit program

run

Simulator/QPU

design autologging

Developer

view

MLflow UI

MLflow Tracking Server

Fig. 1. System architecture

The autologging functionality is implemented independently of application logic, allowing SDK-specific instrumentation to be added while preserving a common provenance model and experiment storage format. This separation facilitates future support for platforms such as Qrisp1 and PennyLane2 , enabling a consistent observability experiment tracking experience across different quantum programming ecosystems. B. System architecture MLflow [1] provides a mature experiment tracking infrastructure including structured metadata storage, artifact management, comparison of multiple runs, and an interactive user interface. Reusing this infrastructure avoids developing a dedicated provenance database while enabling immediate analysis capabilities familiar from machine learning. Although other experiment management platforms3 have also been explored for quantum computing, they provide a less mature ecosystem for provenance tracking and lack the broad community adoption and extensibility of MLflow for integrating compiler observability into existing quantum software workflows. The proposed system architecture consists of four main components: (1) a Python-based quantum application developed using Qiskit, (2) an automatic observability layer that instruments the application through MLflow-inspired autologging, (3) an MLflow Tracking Server for persisting experiment metadata and provenance information, and (4) the MLflow user interface for exploring and analyzing the recorded experiments. The autologging layer transparently intercepts key stages of the Qiskit transpilation and execution APIs, automatically collecting compiler provenance and execution results as the application is transpiled and executed on either a simulator or a physical quantum processing unit (QPU). The collected information is stored as an MLflow experiment, enabling reproducible execution, systematic comparison of compilation runs, and interactive visualization of compiler behavior without requiring manual instrumentation of the application code. The system architecture is depicted in Fig. 1. C. Logged information The information captured by the proposed tool builds upon the provenance model defined by QProv [2], ensuring that the recorded experiments are compatible with an existing quantum provenance schema while extending it with compiler-specific 1 https://www.qrisp.eu 2 https://pennylane.ai 3 https://github.com/AqueductHub

information. The base set of logged attributes includes metadata describing the quantum program, execution environment, backend, transpilation configuration, execution results, and generated artifacts. This provides a comprehensive description of the experiment that supports reproducibility and comparison across compilation runs. To improve compiler observability, we extend the Compilation section of QProv with two additional entities: C6 Plan and C7 Passes. The C6 Plan records the transpilation plan constructed by the compiler prior to execution. It captures the sequence of compilation stages together with the associated compiler passes and any control-flow constructs (e.g., conditional execution or iterative optimization loops) that determine how the transpiler processes the quantum circuit. This information exposes the intended compilation strategy independently of the actual runtime behavior. The C7 Passes entity captures the outcome of each compiler pass executed during transpilation. For every pass, the tool records the resulting circuit together with key circuit metrics inherited from QProv (Q4–Q7 and C5), as well as compilerspecific metadata including the pass name and the transpilation stage to which the pass belongs. Collectively, these records enable detailed analysis of how individual passes transform the circuit, identify performance bottlenecks, and reconstruct the complete compilation process for visualization and debugging purposes. III. D EMONSTRATION A. How to use Using the proposed compiler observability framework requires only enabling the autologging functionality before executing a standard Qiskit workflow. Fig. 3 shows a minimal example in which a quantum circuit generated with the Munich Quantum Toolkit (MQT) Bench [3] is transpiled and executed on an IQM simulator. Once autologging is enabled, the framework transparently instruments the transpilation and execution pipeline, requiring no modifications to the application logic. During execution, the MLflow experiment run and records the information defined by QProv together with the compiler observability extensions introduced in this paper. The collected provenance is stored in the MLflow Tracking Server, where it can be inspected through the web interface or consumed programmatically for further analysis. This workflow preserves the familiar Qiskit programming model while eliminating the manual instrumentation traditionally required to capture detailed compiler provenance. Consequently, researchers can focus on evaluating compilation techniques rather than implementing custom logging infrastructure, making it easier to reproduce experiments and compare different compiler configurations. B. Visualizations The collected provenance data and derived visualization is collected as artifacts and can be explored through the MLflow user interface or rendered using dedicated components. Fig. 4 presents a transpilation timeline that combines pass execution

Quantum Provenance

Quantum Circuit

Quantum Computer

Compilation

Execution

Q1 Used Gates Q2 Used Measurements Q3 Execution Order Q4 Circuit Width Q5 Circuit Depth Q6 Circuit Size Q7 Applied Encoding

QC1 Number of Qubits QC2 Decoherence Times QC3 Qubit Connectivity QC4 Gate Set QC5 Gate Fidelities QC6 Gate Times QC7 Readout Fidelities

C1 Qubit Assignments C2 Gate Mappings C3 Optimisation Goals C4 Random Seed C5 Compilation Time C6 Plan C7 Passes

E1 Input Data E2 Output Data E3 Number of Shots E4 Intermediate Results E5 Number of Iterations E6 Execution Time E7 Applied ErrorMitigation

Fig. 2. Quantum provenance taxonomy capturing key metadata across the quantum computing stack, adapted from [2]. Items marked bold represent extensions added to support the compiler observability case.

import mlflow from mqt.bench import BenchmarkLevel, get_benchmark from q8s.runtime.mlflow.qiskit import autolog

compilation experiments. C. Experiment comparisons with MLflow

autolog() from iqm.qiskit_iqm.fake_backends.fake_aphrodite import ,→ IQMFakeAphrodite from qiskit.transpiler import generate_preset_pass_manager mlflow.set_experiment("qiskit-transpilation")

with mlflow.start_run(): qc = get_benchmark( benchmark="qft", level=BenchmarkLevel.ALG, circuit_size=30, ) backend = IQMFakeAphrodite() manager = generate_preset_pass_manager( optimization_level=3, backend=backend, ,→ seed_transpiler=42 ) tqc = manager.run(qc) job = backend.run(tqc, shots=1024, memory=True) result = job.result()

The MLflow user interface enables researchers to compare multiple compilation experiments without requiring custom analysis tools. Since each transpilation run is recorded as a separate experiment, the UI provides tabular and graphical views of the captured parameters, metrics, and artifacts, allowing differences between compiler configurations to be identified quickly. For example, Fig. 5 illustrates this capability by comparing two executions of the same quantum circuit transpiled using optimization levels 2 and 3. While conventional experiment tracking reveals that optimization level 3 produces a smaller circuit than level 2, it does not explain why. By selecting either run, the collected pass-level provenance and transpilation timeline expose which compiler passes were executed, where circuit depth changed, and which optimization stages dominated compilation time. This enables researchers to attribute improvements to specific compiler transformations rather than only comparing final metrics.

result.get_counts()

IV. C ONTRIBUTIONS Fig. 3. Sample Qiskit program with compiler observability. Highlighted lines show changes needed to enable the functionality.

times, circuit evolution, and compiler stages, providing an intuitive view of how the transpiler transforms the circuit throughout the compilation process. Such visualizations help identify expensive compiler passes, understand the impact of individual transformations, and compare different transpilation strategies. Beyond the timeline presented in this demonstration, the recorded provenance can be used to generate a variety of other visualizations, including compiler pipeline graphs, pass dependency graphs, circuit metric evolution, backend performance comparisons, and dashboards for analyzing multiple

This demonstration paper presents an automatic compiler observability framework that improves the observability of the quantum compilation process. The work makes the following contributions: • Automatic compiler observability for Qiskit, through MLflow-inspired autologging enabling transparent collection of provenance information from transpilation and execution workflows in an unified experiment record without requiring manual instrumentation of user applications. • Extensions to the QProv provenance model that capture compiler-specific information, including the transpilation stage plan and pass-level execution records, allowing the complete compilation process to be reconstructed.

pre_init

400 350

init

layout

routing

translation

Transpilation Pass Timeline

optimization

scheduling

Runtime (ms) Depth Size

2500 2000

10000 8000

250

6000

200

1000

4000

500

2000

0

0

150 100 50 000 : Co 00 ntain 002 1: Unit sInstr : Hig ary uctio 005 : Re h S mov 0 Lev ynth n eDia 004 03: Ba elSynt esis : g E o 006 nalG lide sisTran hesis : Re ate Perm slat mo sB ut or 008 : Co 007 veIden eforeM ations ntra : In tity eas c 009 tIdle verse Equiv ure : Co Wir Can alen mm esIn cell t a u 010 tative Contro tion : C Ca lFlo 011 onsolidncellat w : Sp ate ion 014 lit2 Blo : Ba rrie 012 QUnita cks rBe fore 013 : SetLa ries Fina : VF you lM 2L t 015 easure ayout : Sa me br nts 017 016: C eLayou he : t 018 VF2Pos ckMap 01 : F tL 020 9: UnitilterOp ayout : Hig ary Nod hLe Syn es 022 021: B velSynthesis : Ch asis the eck Tran sis 023 GateD slato 024 : Gate irectio r : Ba Dire n sisT ctio ra n 025 nslator : De 027 0 2 8 : M 0 2 6 : pt h in : S 031 030: 029Consoli imumP ize : Op Rem : U dat oin tim ove nitar eBlo t iz I y c d 033 032: Ce1qGa entity Synthe ks : Co om tesD Equ sis ntra mu eco ivale ctId tativ mp nt leW eCa ositio ires nce n 034 InCont llation : Ga rolF tesI low 035 nBasis : De 037 0 3 8 : M 0 3 6 : pt h in : S 041 040: 039Consoli imumP ize : Op Rem : U dat oin tim ove nitar eBlo t iz I y c d e S e 043 042: C 1qGa ntity ynthe ks : Co om tesD Equ sis ntra mu eco ivale t ctId ativ mp nt leW eCa ositio ires nce n 044 InCont llation : Ga rolF tesI low 045 nBasis : De 047 0 4 8 : M 0 4 6 : pt h in : S 051 050: 049Consoli imumP ize : Op Rem : U dat oin tim ove nitar eBlo t iz Id y c 053 052: Ce1qGa entity Synthe ks : Co om tesD Equ sis ntra mu eco ivale ctId tativ mp nt leW eCa ositio ires nce n 054 InCont llation : Ga rolF tesI low 058 055 nBasis : IQ :D MO 05 059 ptim 7: M 056 epth : IQ ize inim : Siz MNa Sing um e iveR leQu Poin eso bitG t n at ate orM s ovin g

0

Circuit size

1500

Circuit depth

Runtime (ms)

300

Transpiler pass

Fig. 4. Transpilation pass timeline rendering based on the information collected by Qiskit autologger

based workflows. V. T OOL AVAILABILITY The framework is publicly available as open-source software. The source code is hosted in a Git repository4 , while the package is distributed through the Python Package Index (PyPI), allowing installation via pip5 . VI. C ONCLUSIONS AND FUTURE WORK

Fig. 5. Visualizing experiment comparison metrics with MLflow UI

•

Visualization support that transforms the collected provenance into interactive views, such as transpilation timelines, demonstrating how experiment tracking can aid in understanding, debugging, and comparing compilation strategies.

Together, these contributions provide a practical foundation for reproducible quantum compilation experiments while reducing the effort required to instrument and analyze Qiskit-

This paper presented an observability framework for quantum compilation that brings MLflow-inspired autologging to Qiskit workflows. By automatically capturing compiler provenance, the proposed approach improves the observability and reproducibility of quantum compilation experiments while eliminating the need for manual instrumentation. As this work is intended as a community tool, we are particularly interested in feedback from quantum software practitioners regarding the usefulness of the collected provenance, the proposed visualizations, and additional compiler insights that would support their development and research workflows. We hope this work encourages broader adoption of reproducible, observable quantum compiler experimentation. Future work will focus on extending the autologging framework beyond Qiskit to support additional quantum software development kits, including Qrisp and PennyLane. This will enable a unified experiment tracking experience across multiple quantum programming ecosystems and facilitate comparative studies of compilation and execution workflows. We also plan to investigate additional visualization techniques and analyses that further enhance compiler observability and support the debugging and optimization of quantum software. 4 https://github.com/qubernetes-dev/runtime 5 https://pypi.org/project/q8s.runtime/

R EFERENCES [1] M. Zaharia, A. Chen, A. Davidson, A. Ghodsi, S. A. Hong, A. Konwinski, S. Murching, T. Nykodym, P. Ogilvie, M. Parkhe et al., “Accelerating the machine learning lifecycle with mlflow.” IEEE Data Eng. Bull., vol. 41, no. 4, pp. 39–45, 2018. [2] B. Weder, J. Barzen, F. Leymann, M. Salm, and K. Wild, “Qprov: A provenance system for quantum computing,” IET Quantum Communication, vol. 2, no. 4, pp. 171–181, 2021. [Online]. Available: https://ietresearch.onlinelibrary.wiley.com/doi/abs/10.1049/qtc2.12012 [3] R. Wille, L. Berent, T. Forster, J. Kunasaikaran, K. Mato, T. Peham, N. Quetschlich, D. Rovara, A. Sander, L. Schmid, D. Schoenberger, Y. Stade, and L. Burgholzer, “The MQT handbook: A summary of design automation tools and software for quantum computing,” in IEEE International Conference on Quantum Software (QSW), 2024.

Related documents

• Extracting high fidelity quantum computer hardware from random systems#420804
• Automated Quantum Software and AI Engineering#124121
• Qlippy: A Retrieval-Augmented GenAI Assistant for Reproducible Quantum Workflows and Experiment Tracking#971994
• Accelerating Quantum Dense-Output Simulation through Locality#1154363
• Randomized and Diverse Input State Generation for Quantum Program Testing#155357