Pith. sign in

REVIEW 3 major objections 7 minor 65 references

Quantum software needs systematic experiment tracking that logs circuits, calibrations, noise, and error-mitigation intermediates—not only classical ML parameters.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · grok-4.5

2026-07-31 19:37 UTC pith:3CTV4XYI

load-bearing objection Useful QSE tooling demo with honest logs; the case study shows data collection more clearly than it shows that quantum-specific tracking drove better decisions. the 3 major comments →

arxiv 2607.24264 v1 pith:3CTV4XYI submitted 2026-07-27 quant-ph cs.SE

Systematic Experiment Tracking in Quantum Software: A Case Study of Reservoir Computing with Error Mitigation

Otso Kinanen , Valter Uotila , Vlad Stirbu This is my paper
classification quant-ph cs.SE
keywords experiment trackingquantum software engineeringquantum software developmentquantum reservoir computingerror mitigationquantum provenancereproducibility
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper argues that quantum software development requires experiment tracking beyond ordinary machine-learning logs. Noisy hardware, drifting calibrations, compilation choices, and multi-stage error mitigation mean developers must record quantum provenance—circuit structure, qubit maps, decoherence and gate fidelities, shots, measurement data, and mitigation intermediates—together with parameters and metrics. The authors demonstrate the practice on a realistic pipeline: quantum reservoir computing for chaotic time-series prediction, run on a noisy five-qubit simulator and cleaned with tensor-network error mitigation. Stage-by-stage logging supported debugging, hyperparameter choices, artifact reuse, and cross-validated accuracy close to the exact baseline. They generalize that the same tracking discipline improves decision-making and reproducibility across quantum software work.

Core claim

Systematic experiment tracking that captures quantum provenance (circuits, compilation maps, hardware calibration, shots, measurement and error-mitigation intermediates) plus ordinary parameters and metrics assists practitioners in collecting experimental data and improving decision-making for quantum software engineering. In a multi-stage quantum reservoir computing case study with error mitigation, those logs enabled debugging, parameter tuning, cross-stage data reuse, and prediction quality near the exact simulation baseline.

What carries the argument

Quantum-adapted experiment tracking: run-level recording of a quantum provenance taxonomy (circuit gates and depth, computer calibration metrics, compilation maps and seeds, execution shots and times, error-mitigation settings) together with stage artifacts, so each pipeline stage’s inputs, noise model, and outputs stay queryable and comparable.

Load-bearing premise

The benefits seen while building one small noisy-simulator reservoir-computing pipeline will generalize to other quantum projects and to real hardware without a controlled comparison of tracked versus untracked work.

What would settle it

Develop the same quantum pipeline twice—once with full provenance and artifact logging, once without—and compare debug effort, ability to reproduce results after recalibration, and final model quality on real hardware; if the two arms do not differ, the central claim fails.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Logged measurement data and dual frames can be reused for post-hoc mitigation and classical readout without re-running circuits.
  • Scientific reports can attach run-level quantum provenance so others can interpret results despite drifting calibrations.
  • Tracking tools need quantum-specific logging for circuits, noise models, and calibration snapshots, not only classical ML hooks.
  • Failed quantum runs become diagnosable because intermediate artifacts and error tracebacks are stored with each experiment.
  • Teams gain a practical reason to host shared tracking servers for large quantum measurement datasets.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Classical-shadows and tensor-network mitigation pipelines will push trackers toward efficient blob storage and fast retrieval, not only relational parameter tables.
  • Versioning calibration data per run would let long queue-scheduled jobs be stratified by hardware state, separating algorithm instability from device drift.
  • In-circuit assertion-style probes, if wired into the same run log, could connect classical experiment tracking with quantum debugging practice.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 7 minor

Summary. The manuscript argues that quantum software development requires experiment-tracking practices beyond those of classical ML, and demonstrates this via a design-science case study: a five-qubit noisy-simulator quantum reservoir computing (QRC) pipeline for Mackey-Glass time-series prediction, with classical-shadows POVM tomography and a custom tensor-network error mitigation (TEM) stage, all instrumented with MLflow. The authors enumerate quantum-specific provenance dimensions (circuit, compilation, calibration, execution metadata), list the parameters/artifacts logged at each of four pipeline stages (Tables I–IV), and report cross-validated R² for five readout modes (Table V), finding TEM+SNR (0.735±0.292) close to the exact baseline (0.752±0.438). They generalize the experience into recommendations for quantum development workflows, data management, and error tracing.

Significance. If the claims hold at the stated (modest) scope, the paper is a useful experience report for the quantum software engineering community: it concretely instantiates the QProv provenance taxonomy in a working MLflow-instrumented pipeline, ships public code repositories for all four stages ([45]–[47]), honestly caveats that the custom TEM is not IBM's production implementation, and documents a realistic data-management pain point (585 MB of shadow data from a five-qubit toy). The SNR-normalization observation on per-observable standard deviations is a small but interesting empirical nugget. However, the significance is limited by the evaluation: the central design-science claim — that tracking improves decision-making — is supported only by narrative experience from a single case, and the one quantitative anchor (Table V) is statistically underpowered and internally ambiguous about what it demonstrates.

major comments (3)
  1. [§III-D, Table V] The quantitative results do not support the ordering the text implies. With 5 CV splits, the TEM+SNR vs noisy+SNR gap (0.735 vs 0.656) is far inside one standard deviation of either estimate (stds 0.292 and 0.453), and the full 80/20 split actually inverts the ordering: plain noisy execution (0.9617) beats TEM+SNR (0.9585) and TEM (0.9496). The paper itself concedes 'the noise does not have a big impact on the results.' As written, the only robust effect in Table V is the SNR normalization (−0.377 → 0.656 on the noisy data), which is a classical post-hoc rescaling. The claim that 'TEM + SNR obtains results ... close to the exact results' is defensible only descriptively; no separable contribution of the error-mitigation stage — the component that consumes the quantum-specific tracked artifacts (noise model, dual frames, transpiled circuits) — is demonstrated. Either (a) increase statisti
  2. [§I (research objective) and §IV-A] The central design-science claim — that tracking 'improv[es] decision-making for better software engineering' — is evaluated only anecdotally. §IV-A contains a single sentence of evidence ('we used the logs to adjust the amount of training data and other hyperparameters while keeping the running times reasonable'), with no concrete logged artifact, query, or before/after decision shown. Notably, the one clear performance win in the paper (the SNR normalization, §III-D) is described as an observation ('We observed that this standard deviation can further improve the results') and is not attributed to the tracking infrastructure at all. For a design-science contribution, the artifact evaluation needs at least: (i) 2–3 documented, specific instances where a logged parameter/artifact/metric caused a decision that would otherwise have been impossible or slower (e.g., the error-traceback captu
  3. [§III, Tables I–IV] Several internal inconsistencies in the logged-parameter tables reduce confidence in the very provenance discipline the paper advocates. (1) Table I gives tend = 3.1, but the text (§III-A) states τ ranges from 0.1 to 2.5 with interval 0.6, which yields five steps ending at 2.5; the feature dimension (75 = 15 × 5) matches the text, so the table value appears wrong. (2) §III-D says 'we train four linear models on four different datasets' and then lists five modes (noiseless, noisy, noisy+SNR, TEM, TEM+SNR), consistent with Table IV's five modes — the 'four/four' sentence is wrong. (3) The symbol τ is overloaded for the Mackey-Glass delay (τ = 17) and the Hamiltonian evolution time (τ ∈ [0.1, 2.5]) within the same section. These are exactly the classes of discrepancy that systematic tracking is meant to catch, so their presence in the paper's own reported parameter tables is conspicuous and
minor comments (7)
  1. [§III header] Typo: 'CASE STUDY:TIME SERIES PREDICTION' — missing space after the colon.
  2. [§II-B] Typo: 'available to the developer as thequality metric set' — missing space; also 'circuits allow debugging' should read 'circuit simulations allow debugging' or similar in the sentence 'small-scale simulations, up to 20-30 qubits, circuits allow debugging'.
  3. [§III-A, Eq. (1) and surrounding] The Hamiltonian construction cites Quera's analog neutral-atom work [54] adapted to the gate model, but the adaptation (e.g., the coefficient scalings 3/4, 1/2, and (1+0.5 x_i x_{i+1})/(4π)) is justified only as 'favorable scaling.' One or two sentences on how these constants were chosen — and whether the choice was informed by tracked runs — would strengthen both the science and the tracking narrative.
  4. [§III-B] Table II reports 'measured observables 2430' and 'total measurements 4860' with 'shot repetitions 2'; please clarify whether 2430 is the number of distinct randomized measurement settings across all 875 circuits or something else, since 875 circuits × 15 observables would suggest a different count. A one-line derivation would help reproducibility.
  5. [§III-D] The SNR normalization divides by the per-observable mean standard deviation σ̄_j, which is a per-feature rescaling; please confirm that σ̄_j is computed on the training split only (not the full 175 samples) to rule out test-set leakage through the normalization, and state this explicitly.
  6. [Fig. 5] The figure plots 875 mitigated expectation values 'retrieved automatically from MLflow' but does not indicate which of the 15 observables is shown, nor overlay noisy/exact values for comparison. As presented it demonstrates retrieval, not mitigation quality; either label it as a retrieval demonstration or add the comparison traces.
  7. [References] Refs [44] and [54] are the same arXiv paper (2407.02553) listed twice; please merge. Ref [47] is dated 2024 while [45]/[46] are 2026 — verify the TEM container repository date.

Circularity Check

0 steps flagged

No significant circularity: methodological case study demonstrates tracking via an independent QRC+TEM pipeline rather than deriving outcomes from fitted identities or load-bearing self-citation.

full rationale

This is a design-science / software-engineering paper whose central claim is that systematic experiment tracking (quantum provenance plus ML parameters via MLflow) assists practitioners; the claim is supported by constructing and logging a multi-stage QRC+TEM pipeline, not by a first-principles derivation that could collapse into its inputs. Table V R² figures are ordinary empirical cross-validation scores on held-out time-series splits, not predictions forced by a fitted free parameter. SNR normalization is an observed classical post-processing choice applied after logging stds, not a self-definitional identity. Self-citations ([10], [33], [37]) supply prior toolchain/tracking background from overlapping authors but are not used as uniqueness theorems or sole evidence that tracking works; external anchors (QProv, MLflow, Filippov TEM, classical shadows/POVM literature, Mackey–Glass) carry the technical stack. No equation equates a claimed prediction to a free parameter by construction, and no ansatz is smuggled in as a forced uniqueness result. Circularity patterns 1–6 do not apply; score 0 is the honest finding.

Axiom & Free-Parameter Ledger

7 free parameters · 5 axioms · 0 invented entities

The load-bearing methodological claim rests on design-science framing and on the premise that one realistic noisy QML pipeline is sufficient to validate and generalize tracking practices. Most numeric free parameters belong to the demonstration physics/ML stack rather than to the tracking claim itself; axioms are standard NISQ and SE assumptions plus the representativeness of the chosen pipeline.

free parameters (7)
  • depolarizing p1 (single-qubit) = 0.0002
    Hand-chosen noise strength for the AerSimulator demo; affects how much TEM and SNR appear to help.
  • depolarizing p2 (two-qubit) = 0.002
    Hand-chosen two-qubit noise; central to the ‘noisy vs mitigated’ comparison narrative.
  • reservoir window size / qubit count = 5
    Fixed at 5 to match small hardware and keep runtime tractable; shapes circuit count and embedding dimension.
  • Hamiltonian evolution τ grid = 0.1..2.5 step 0.6
    Discrete τ from 0.1 to 2.5 step 0.6 chosen for the QRC embedding; not derived from first principles.
  • SNR epsilon floor = 1e-12
    Ad-hoc stabilizer in per-observable normalization ê = e/(σ̄+ε).
  • ridge α candidate set = {1e-4 ... 1000}
    Discrete grid searched for classical readout; influences reported R².
  • shot repetitions / total measurements = 2 reps, 4860 total
    Chosen measurement budget (2 reps → 4860 measurements) for shadows; trades variance vs cost.
axioms (5)
  • domain assumption NISQ hardware noise, calibration drift, and stack evolution make iterative development and provenance logging necessary for reliable outcomes.
    Stated throughout §I–II as the motivation for extending classical experiment tracking; not proved, taken as field consensus.
  • ad hoc to paper A five-qubit noisy-simulator QRC pipeline with classical shadows and custom tensor-network error mitigation is sufficiently representative of realistic quantum software pipelines to validate tracking practices.
    Explicit design choice in §III; authors note TEM may differ from production IBM function and scale is small.
  • domain assumption Design-science research (objective-centered) is an appropriate method to answer ‘how can we assist practitioners in collecting experimental data and improving decision-making’.
    Invoked in §I citing Peffers et al.; frames the whole contribution as artifact + demonstration rather than controlled experiment.
  • domain assumption Quantum provenance categories (circuit, computer, compilation, execution) from QProv capture the essential metadata that must be tracked.
    Fig. 1 and §II-C adopt QProv as starting taxonomy; extended but not re-derived.
  • domain assumption Classical shadows with local Pauli observables are efficient enough for the chosen QRC readout (many low-weight expectations).
    §III-B cites Huang et al. shadow-norm scaling; limits claimed generality to local-observable models.

pith-pipeline@v1.2.0-grok45-kimik3 · 22634 in / 3360 out tokens · 101567 ms · 2026-07-31T19:37:22.701565+00:00 · methodology

0 comments
read the original abstract

Quantum computers are more widely available than ever, making the field more accessible and widespread. Practitioners are coming from a wide range of domains, conducting experiments and research using quantum computing approaches across a variety of problems. The current literature suggests that developers follow certain methodologies in quantum software development, often with a matching set of tools provided. Yet with the novel paradigm, there are areas that remain unaddressed in practices and tools. In this article, we go into the details of experiment tracking in quantum software development. We explain the basic concept of experiment tracking and detail how, in essence, quantum computing sets demands on tracking practices. Given the experimental state of hardware and the constantly evolving software, quantum execution must be monitored, marginal gains aggregated for the best outcome, and error sources detected. In our case study, quantum reservoir computing for chaotic time series data prediction with error mitigation, we present a detailed quantum software development process and describe how experiments can be tracked throughout development. We then generalize this knowledge into the broader quantum development process.

Figures

Figures reproduced from arXiv: 2607.24264 by Otso Kinanen, Valter Uotila, Vlad Stirbu.

Figure 1
Figure 1. Figure 1: Quantum provenance taxonomy capturing key metadata across the quantum computing stack. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Example view of the graphical user interface of MLflow running in a browser [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Summary of use case actions. References refer to the [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Overall TEM-pipeline: Every gate has its associated [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: The error-mitigated expectation values across the 875 circuits retrieved automatically from MLflow. A step refers to a [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Logging quantum reservoir computed embeddings with [PITH_FULL_IMAGE:figures/full_fig_p009_6.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

65 extracted references · 3 canonical work pages

  1. [1]

    Observation of constructive interference at the edge of quantum ergodicity,

    D. A. Abanin, R. Acharya, L. Aghababaie-Beni, G. Aigeldinger, A. Ajoy, R. Alcarazet al., “Observation of constructive interference at the edge of quantum ergodicity,”Nature, vol. 646, no. 8086, p. 825–830, Oct. 2025

    2025

  2. [2]

    Quantum error correction below the surface code threshold,

    R. Acharya, D. A. Abanin, L. Aghababaie-Beni, I. Aleiner, T. I. Andersen, M. Ansmannet al., “Quantum error correction below the surface code threshold,”Nature, vol. 638, no. 8052, p. 920–926, Feb. 2025

    2025

  3. [3]

    Quantum supremacy using a programmable superconducting processor,

    F. Arute, K. Arya, R. Babbush, D. Bacon, J. C. Bardin, R. Barends et al., “Quantum supremacy using a programmable superconducting processor,”Nature, vol. 574, no. 7779, p. 505–510, Oct. 2019

    2019

  4. [4]

    Evidence for the utility of quantum computing before fault tolerance,

    Y . Kim, A. Eddins, S. Anand, K. X. Wei, E. van den Berg, S. Rosenblatt, H. Nayfeh, Y . Wu, M. Zaletel, K. Temme, and A. Kandala, “Evidence for the utility of quantum computing before fault tolerance,”Nature, vol. 618, no. 7965, p. 500–505, 6 2023

    2023

  5. [5]

    Chemistry beyond the scale of exact diagonalization on a quantum-centric supercomputer,

    J. Robledo-Moreno, M. Motta, H. Haas, A. Javadi-Abhari, P. Jurcevic, W. Kirby, S. Martiel, K. Sharma, S. Sharma, T. Shirakawa, I. Sitdikov, R.-Y . Sun, K. J. Sung, M. Takita, M. C. Tran, S. Yunoki, and A. Mezzacapo, “Chemistry beyond the scale of exact diagonalization on a quantum-centric supercomputer,”Science Advances, vol. 11, no. 25, p. eadu9991, 2025...

    doi:10.1126/sciadv.adu9991 2025

  6. [6]

    2025 quantum open source software survey results,

    Unitary Foundation Team, “2025 quantum open source software survey results,” https://unitary.foundation/posts/2025_survey_results/, Novem- ber 2025, accessed: 2026-04-24

    2025

  7. [7]

    The mqt handbook : A summary of design automation tools and software for quantum computing,

    R. Wille, L. Berent, T. Forster, J. Kunasaikaran, K. Mato, T. Peham, N. Quetschlich, D. Rovara, A. Sander, L. Schmid, D. Schönberger, Y . Stade, and L. Burgholzer, “The mqt handbook : A summary of design automation tools and software for quantum computing,” in2024 IEEE International Conference on Quantum Software (QSW), 2024, pp. 1–8

    2024

  8. [8]

    Mind the gaps: The fraught road to quantum advantage,

    J. Eisert and J. Preskill, “Mind the gaps: The fraught road to quantum advantage,” no. arXiv:2510.19928, Nov. 2025, arXiv:2510.19928 [quant-ph]. [Online]. Available: http://arxiv.org/abs/2510.19928

    Pith/arXiv arXiv 2025

  9. [9]

    A framework for quantum advantage,

    O. Lanes, M. Beji, A. D. Corcoles, C. Dalyac, J. M. Gambetta, L. Henriet, A. Javadi-Abhari, A. Kandala, A. Mezzacapo, C. Porter, S. Sheldon, J. Watrous, C. Zoufal, A. Dauphin, and B. Peropadre, “A framework for quantum advantage,” no. arXiv:2506.20658, 7 2025, arXiv:2506.20658 [quant-ph]. [Online]. Available: http: //arxiv.org/abs/2506.20658

    Pith/arXiv arXiv 2025

  10. [10]

    Toolchain for faster iterations in quantum software development,

    O. Kinanen, A. D. Muñoz-Moller, V . Stirbu, J. M. Murillo, and T. Mikkonen, “Toolchain for faster iterations in quantum software development,”Computing, vol. 107, no. 4, p. 99, 2025

    2025

  11. [11]

    Quantum software engineering: Roadmap and chal- lenges ahead,

    J. M. Murillo, J. Garcia-Alonso, E. Moguel, J. Barzen, F. Leymann, S. Ali, T. Yue, P. Arcaini, R. Pérez-Castillo, I. García-Rodríguez de Guzmánet al., “Quantum software engineering: Roadmap and chal- lenges ahead,”ACM Transactions on Software Engineering and Method- ology, vol. 34, no. 5, pp. 1–48, 2025

    2025

  12. [12]

    A design science research methodology for information systems research,

    K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A design science research methodology for information systems research,” Journal of management information systems, vol. 24, no. 3, pp. 45–77, 2007

    2007

  13. [13]

    Quantum software engineering landscape and challenges,

    M. Piattini and J. M. Murillo, “Quantum software engineering landscape and challenges,” inQuantum Software Engineering. Springer, 2022, pp. 25–38

    2022

  14. [14]

    Quantum software engineering and quantum software development lifecycle: a survey,

    K. Dwivedi, M. Haghparast, and T. Mikkonen, “Quantum software engineering and quantum software development lifecycle: a survey,” Cluster Computing, vol. 27, no. 6, pp. 7127–7145, 2024

    2024

  15. [15]

    Quantum software development lifecycle,

    B. Weder, J. Barzen, F. Leymann, and D. Vietz, “Quantum software development lifecycle,” inQuantum Software Engineering. Springer, 2022, pp. 61–83

    2022

  16. [16]

    Guidelines to use the incremental commitment spiral model for developing quantum-classical systems,

    R. Pérez-Castillo, M. A. Serrano, J. A. Cruz-Lemus, and M. Pi- attini, “Guidelines to use the incremental commitment spiral model for developing quantum-classical systems,”Quantum Information and Computation, vol. 24, no. 1&2, pp. 71–88, 2024

    2024

  17. [17]

    Agile meets quantum: a novel genetic algorithm model for predicting the success of quantum software devel- opment project,

    A. A. Khan, M. A. Akbar, V . Lahtinen, M. Paavola, M. Niazi, M. N. Alatawi, and S. D. Alotaibi, “Agile meets quantum: a novel genetic algorithm model for predicting the success of quantum software devel- opment project,”Automated Software Engineering, vol. 31, no. 1, p. 34, 2024

    2024

  18. [18]

    Quan- tum devops: Towards reliable and applicable nisq quantum computing,

    I.-D. Gheorghe-Pop, N. Tcholtchev, T. Ritter, and M. Hauswirth, “Quan- tum devops: Towards reliable and applicable nisq quantum computing,” in2020 IEEE Globecom Workshops (GC Wkshps. IEEE, 2020, pp. 1–6

    2020

  19. [19]

    Quantum cloud computing: A review, open problems, and future directions,

    H. T. Nguyen, P. Krishnan, D. Krishnaswamy, M. Usman, and R. Buyya, “Quantum cloud computing: A review, open problems, and future directions,” 2024. [Online]. Available: https://arxiv.org/abs/2404.11420

    Pith/arXiv arXiv 2024

  20. [20]

    Superconducting quantum computers: who is leading the future?

    M. AbuGhanem, “Superconducting quantum computers: who is leading the future?”EPJ Quantum Technology, vol. 12, no. 1, p. 102, 2025

    2025

  21. [21]

    Materials challenges and opportunities for quantum computing hardware,

    N. P. De Leon, K. M. Itoh, D. Kim, K. K. Mehta, T. E. Northup, H. Paik, B. Palmer, N. Samarth, S. Sangtawesin, and D. W. Steuerman, “Materials challenges and opportunities for quantum computing hardware,”Science, vol. 372, no. 6539, p. eabb2823, 2021

    2021

  22. [22]

    Formal verification of quantum programs: Theory, tools, and challenges,

    M. Lewis, S. Soudjani, and P. Zuliani, “Formal verification of quantum programs: Theory, tools, and challenges,”ACM Transactions on Quan- tum Computing, vol. 5, no. 1, pp. 1–35, 2023

    2023

  23. [23]

    On the need for effective tools for debugging quantum programs,

    O. Di Matteo, “On the need for effective tools for debugging quantum programs,” inProceedings of the 5th ACM/IEEE international workshop on quantum software engineering, 2024, pp. 17–20

    2024

  24. [24]

    Quantum error correction for beginners,

    S. J. Devitt, W. J. Munro, and K. Nemoto, “Quantum error correction for beginners,”Reports on Progress in Physics, vol. 76, no. 7, p. 076001, 2013

    2013

  25. [25]

    Quantum error mitigation,

    Z. Cai, R. Babbush, S. C. Benjamin, S. Endo, W. J. Huggins, Y . Li, J. R. McClean, and T. E. O’Brien, “Quantum error mitigation,”Reviews of Modern Physics, vol. 95, no. 4, p. 045005, 2023

    2023

  26. [26]

    Bench- marking quantum computers,

    T. Proctor, K. Young, A. D. Baczewski, and R. Blume-Kohout, “Bench- marking quantum computers,”Nature Reviews Physics, vol. 7, no. 2, pp. 105–118, 2025

    2025

  27. [27]

    Calibration and performance evaluation of a superconducting quantum processor in an hpc center,

    X. Deng, S. Pogorzalek, F. Vigneau, P. Yang, M. Schulz, and L. Schulz, “Calibration and performance evaluation of a superconducting quantum processor in an hpc center,” inISC High Performance 2024 Research Paper Proceedings (39th International Conference). Prometeus GmbH, 2024, pp. 1–9

    2024

  28. [28]

    A quantum engineer’s guide to superconducting qubits,

    P. Krantz, M. Kjaergaard, F. Yan, T. P. Orlando, S. Gustavsson, and W. D. Oliver, “A quantum engineer’s guide to superconducting qubits,” Applied Physics Reviews, vol. 6, no. 2, Jun. 2019. [Online]. Available: http://dx.doi.org/10.1063/1.5089550

    doi:10.1063/1.5089550 2019

  29. [29]

    A literature review and existing challenges on software logging practices: From the creation to the analysis of software logs,

    M. A. Batoun, M. Sayagh, R. Aghili, A. Ouni, and H. Li, “A literature review and existing challenges on software logging practices: From the creation to the analysis of software logs,”Empirical Software Engineering, vol. 29, no. 4, p. 103, 2024

    2024

  30. [30]

    Log-based software monitoring: a systematic mapping study,

    J. Cândido, M. Aniche, and A. Van Deursen, “Log-based software monitoring: a systematic mapping study,”PeerJ Computer Science, vol. 7, p. e489, 2021

    2021

  31. [31]

    Accelerat- ing the machine learning lifecycle with mlflow

    M. Zaharia, A. Chen, A. Davidson, A. Ghodsi, S. A. Hong, A. Konwin- ski, S. Murching, T. Nykodym, P. Ogilvie, M. Parkheet al., “Accelerat- ing the machine learning lifecycle with mlflow.”IEEE Data Eng. Bull., vol. 41, no. 4, pp. 39–45, 2018

    2018

  32. [32]

    Mlflow2prov: extracting provenance from machine learning experiments,

    M. Schlegel and K.-U. Sattler, “Mlflow2prov: extracting provenance from machine learning experiments,” inProceedings of the seventh workshop on data management for end-to-end machine learning, 2023, pp. 1–4

    2023

  33. [33]

    Enhancing quantum software development process with experiment tracking,

    M. Gamage, O. Kinanen, J. Muff, and V . Stirbu, “Enhancing quantum software development process with experiment tracking,” in2025 IEEE International Conference on Quantum Computing and Engineering (QCE), vol. 02, 2025, pp. 392–393

    2025

  34. [34]

    Quantum software development: a survey

    L. Jiménez-Navajas, F. Bühler, F. Leymann, R. Pérez-Castillo, M. Piat- tini, and D. Vietz, “Quantum software development: a survey.”Quantum Inf. Comput., vol. 24, no. 7&8, pp. 609–642, 2024

    2024

  35. [35]

    Quantum software experiments: A reporting and laboratory package structure guidelines proposal,

    E. Moguel, J. A. Parejo, A. Ruiz-Cortés, J. Garcia-Alonso, and J. M. Murillo, “Quantum software experiments: A reporting and laboratory package structure guidelines proposal,” in2025 IEEE International Conference on Quantum Software (QSW). IEEE, 2025, pp. 185–194

    2025

  36. [36]

    Qprov: A provenance system for quantum computing,

    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

    work page doi:10.1049/qtc2.12012 2021

  37. [37]

    Toolchain for experiment tracking in iterative quantum software development,

    O. Kinanen, M. Gamage, and V . Stirbu, “Toolchain for experiment tracking in iterative quantum software development,” in2025 IEEE International Conference on Quantum Computing and Engineering (QCE), vol. 2. IEEE, 2025, pp. 187–192

    2025

  38. [38]

    1-2-3 reproducibility for quantum soft- ware experiments,

    W. Mauerer and S. Scherzinger, “1-2-3 reproducibility for quantum soft- ware experiments,” in2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2022, pp. 1247–1248

    2022

  39. [39]

    Qef: Reproducible and exploratory quan- tum software experiments,

    V . Gierisch and W. Mauerer, “Qef: Reproducible and exploratory quan- tum software experiments,”arXiv preprint arXiv:2511.04563, 2025

    arXiv 2025

  40. [40]

    Validation of an analyzability model for quantum software: a family of experiments,

    A. Díaz-Muñoz, J. A. Cruz-Lemus, M. Rodríguez, M. T. Baldassarre, and M. Piattini, “Validation of an analyzability model for quantum software: a family of experiments,”Empirical Software Engineering, vol. 31, no. 4, p. 82, 2026

    2026

  41. [41]

    Challenges and opportunities in quantum machine learning,

    M. Cerezo, G. Verdon, H.-Y . Huang, L. Cincio, and P. J. Coles, “Challenges and opportunities in quantum machine learning,”Nature computational science, vol. 2, no. 9, pp. 567–576, 2022

    2022

  42. [42]

    A survey of quantum machine learning: Foundations, algo- rithms, frameworks, data and applications,

    F. Rodríguez-Díaz, D. Gutiérrez-Avilés, A. Troncoso, and F. Martínez- Álvarez, “A survey of quantum machine learning: Foundations, algo- rithms, frameworks, data and applications,”ACM Computing Surveys, vol. 58, no. 4, pp. 1–35, 2025

    2025

  43. [43]

    Quantum reservoir computing using arrays of rydberg atoms,

    R. A. Bravo, K. Najafi, X. Gao, and S. F. Yelin, “Quantum reservoir computing using arrays of rydberg atoms,”PRX Quantum, vol. 3, p. 030325, Aug 2022. [Online]. Available: https://link.aps.org/doi/10. 1103/PRXQuantum.3.030325

    2022

  44. [45]

    Mackey-glass quantum reservoir,

    V . Uotila, “Mackey-glass quantum reservoir,” https://github.com/ valterUo/mackey-glass-quantum-reservoir, 2026, gitHub repository, ac- cessed 2026-04-07

    2026

  45. [46]

    Povm helmi container,

    ——, “Povm helmi container,” https://github.com/valterUo/POVM_ Helmi_container, 2026, gitHub repository, accessed 2026-04-07

    2026

  46. [47]

    Tem q50 container,

    ——, “Tem q50 container,” https://github.com/valterUo/TEM_Q50_ container, 2024, gitHub repository, accessed 2026-04-07

    2024

  47. [48]

    Scalable tensor-network error mitigation for near-term quantum computing,

    S. Filippov, M. Leahy, M. A. Rossi, and G. García-Pérez, “Scalable tensor-network error mitigation for near-term quantum computing,” arXiv preprint arXiv:2307.11740, 2023

    Pith/arXiv arXiv 2023

  48. [49]

    Perspectives on utilization of measurements in quantum algorithms,

    V . Uotila, I. Salmenperä, L. Becker, A. Meijer van de Griend, A. R. Shinde, and J. K. Nurminen, “Perspectives on utilization of measurements in quantum algorithms,” in2025 IEEE International Conference on Quantum Software (QSW). IEEE, Jul. 2025, p. 01–12. [Online]. Available: http://dx.doi.org/10.1109/QSW67625.2025.00016

    arXiv 2025

  49. [50]

    Scalability of quantum error mitigation techniques: from utility to advantage,

    S. N. Filippov, S. Maniscalco, and G. García-Pérez, “Scalability of quantum error mitigation techniques: from utility to advantage,” 2024, arXiv:2403.13542 [quant-ph]. [Online]. Available: https://arxiv.org/abs/ 2403.13542

    Pith/arXiv arXiv 2024

  50. [51]

    Oscillation and chaos in physiological control systems,

    M. C. Mackey and L. Glass, “Oscillation and chaos in physiological control systems,”Science, vol. 197, no. 4300, pp. 287–289, 1977. [Online]. Available: https://www.science.org/doi/abs/10.1126/science. 267326

    doi:10.1126/science 1977

  51. [52]

    ReservoirPy: an Efficient and User-Friendly Library to Design Echo State Networks,

    N. Trouvain, L. Pedrelli, T. T. Dinh, and X. Hinaut, “ReservoirPy: an Efficient and User-Friendly Library to Design Echo State Networks,” inICANN 2020 - 29th International Conference on Artificial Neural Networks, Bratislava, Slovakia, Sep. 2020. [Online]. Available: https://inria.hal.science/hal-02595026

    2020

  52. [53]

    Opportunities in quantum reservoir computing and extreme learning machines,

    P. Mujal, R. Martínez-Peña, J. Nokkala, J. García-Beni, G. L. Giorgi, M. C. Soriano, and R. Zambrini, “Opportunities in quantum reservoir computing and extreme learning machines,”Advanced Quantum Technologies, vol. 4, no. 8, 6 2021. [Online]. Available: http://dx.doi.org/10.1002/qute.202100027

    doi:10.1002/qute.202100027 2021

  53. [54]

    Large-scale quantum reservoir learning with an analog quantum computer,

    M. Kornja ˇca, H.-Y . Hu, C. Zhao, J. Wurtz, P. Weinberg, M. Hamdan, A. Zhdanov, S. H. Cantu, H. Zhou, R. A. Bravo, K. Bagnall, J. I. Basham, J. Campo, A. Choukri, R. DeAngelo, P. Frederick, D. Haines, J. Hammett, N. Hsu, M.-G. Hu, F. Huber, P. N. Jepsen, N. Jia, T. Karolyshyn, M. Kwon, J. Long, J. Lopatin, A. Lukin, T. Macrì, O. Markovi ´c, L. A. Martíne...

    Pith/arXiv arXiv 2024

  54. [55]

    Dual-frame optimization for informationally complete quantum measurements,

    L. E. Fischer, T. Dao, I. Tavernelli, and F. Tacchino, “Dual-frame optimization for informationally complete quantum measurements,” Physical Review A, vol. 109, no. 6, Jun. 2024. [Online]. Available: http://dx.doi.org/10.1103/PhysRevA.109.062415

    work page doi:10.1103/physreva.109.062415 2024

  55. [56]

    Predicting many properties of a quantum system from very few measurements,

    H.-Y . Huang, R. Kueng, and J. Preskill, “Predicting many properties of a quantum system from very few measurements,”Nature Physics, vol. 16, no. 10, pp. 1050–1057, 2020

    2020

  56. [57]

    Tensor-network error mitigation (tem) - a qiskit func- tion by algorithmiq,

    IBM Quantum, “Tensor-network error mitigation (tem) - a qiskit func- tion by algorithmiq,” https://quantum.cloud.ibm.com/docs/en/guides/ algorithmiq-tem, 2024, accessed: 2026-04-09

    2024

  57. [58]

    Synergy between quantum computers and databases,

    V . Uotila, “Synergy between quantum computers and databases,” in VLDB 2022 PhD Workshop co-located with the 48th International Conference on Very Large Databases (VLDB 2022). CEUR, 2022, pp. 1–4. [Online]. Available: https://ceur-ws.org/V ol-3186/paper_1.pdf

    2022

  58. [59]

    Quantum computing methods for query optimization in relational databases,

    ——, “Quantum computing methods for query optimization in relational databases,” PhD thesis, University of Helsinki, 2026. [Online]. Available: http://hdl.handle.net/10138/628219

    2026

  59. [60]

    Zx-db: A graph database for quantum circuit simplification and rewriting via the zx-calculus,

    V . Uotila, C. Yu, and B. Zhao, “Zx-db: A graph database for quantum circuit simplification and rewriting via the zx-calculus,” 2025. [Online]. Available: https://arxiv.org/abs/2511.13033

    arXiv 2025

  60. [61]

    Transpiling quantum circuits on graph databases,

    V . Uotila, “Transpiling quantum circuits on graph databases,” in2nd Workshop on Quantum Computing and Quantum-Inspired Technology for Data-Intensive Systems and Applications (Q-Data’25), ser. Q- Data’25. Association for Computing Machinery, 2025, p. 18–19. [Online]. Available: https://doi.org/10.1145/3736393.3736694

    arXiv 2025

  61. [62]

    Qymera: Simulating quantum circuits using rdbms,

    T. Littau and R. Hai, “Qymera: Simulating quantum circuits using rdbms,” inCompanion of the 2025 International Conference on Management of Data, ser. SIGMOD/PODS ’25. New York, NY , USA: Association for Computing Machinery, 2025, p. 179–182. [Online]. Available: https://doi.org/10.1145/3722212.3725126

    arXiv 2025

  62. [63]

    Ultra-large-scale compilation and manipulation of quantum circuits with pandora,

    I. Moflic and A. Paler, “Ultra-large-scale compilation and manipulation of quantum circuits with pandora,” 2025. [Online]. Available: https://arxiv.org/abs/2508.05608

    Pith/arXiv arXiv 2025

  63. [64]

    A framework for debugging quantum programs,

    D. Rovara, L. Burgholzer, and R. Wille, “A framework for debugging quantum programs,” in2025 IEEE International Conference on Quan- tum Software (QSW), 2025, pp. 130–136

    2025

  64. [65]

    Debugging quantum processes using monitoring measurements,

    Y . Li and M. Ying, “Debugging quantum processes using monitoring measurements,”Phys. Rev. A, vol. 89, p. 042338, Apr 2014. [Online]. Available: https://link.aps.org/doi/10.1103/PhysRevA.89.042338

    work page doi:10.1103/physreva.89.042338 2014

  65. [66]

    Statistical assertions for validating patterns and finding bugs in quantum programs,

    Y . Huang and M. Martonosi, “Statistical assertions for validating patterns and finding bugs in quantum programs,” inProceedings of the 46th International Symposium on Computer Architecture, ser. ISCA ’19. New York, NY , USA: Association for Computing Machinery, 2019, p. 541–553. [Online]. Available: https://doi.org/10.1145/3307650.3322213

    arXiv 2019