Pith. sign in

REVIEW 5 minor 48 references

Toward Standardized Quantum Provenance: A Cross-Provider Analysis, Unified API, and Reference Prototype

T0 review · 0 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read A single evidence-aware contract can hold quantum provenance records from many providers without erasing their differences.

desk verdict Genuinely useful cross-provider provenance survey plus an honest, fixture-backed prototype; the conformance result is partly self-defined, but the paper scopes it as structural feasibility and mostly earns that framing. read the letter →

arxiv 2608.08272 v1 pith:3HO2PRYB submitted 2026-08-08 quant-ph

Jouni Peltonen , Vlad Stirbu , Tommi Mikkonen , Cesare Pautasso This is my paper · ORCID
classification quant-ph
keywords quantumprovenancesoftwareengineeringOpenAPI3.1contractprovideradaptersmulti-providercomputingevidence-awarereproducibilityfixture-basedevaluation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

Quantum software development depends on knowing how a result came about — which program was compiled and executed, on which device and calibration state, with which software versions — but providers expose this through incompatible SDKs and APIs. The paper claims this fragmentation can be contained behind a provider-independent, evidence-aware provenance contract: one schema that normalizes record structure while keeping each value's origin, meaning, temporal relevance, and availability explicit. It supports the claim by analyzing publicly documented provenance access across 15 platforms spanning five hardware technologies, where compilation provenance is the weakest category, and by building a fixture-backed reference prototype for Amazon Braket, IBM Quantum, and IonQ. All three representative completed-job records validate against the same reduced OpenAPI 3.1 contract, with provider-specific semantics preserved, evidence origins explicit, and incomplete data represented as unavailable rather than silently missing. If correct, the result gives multi-provider quantum applications a stable boundary for audit, comparison, and reproducible experimentation.

What carries the argument

The load-bearing mechanism is the evidence-aware provenance record: a single normalized structure in which job, device, program, compilation, execution, characterization, results, and software context appear together, and every value carries an explicit evidence qualifier and, for time-dependent device data, a characterization-association class (provider-linked, configuration-linked, timestamp-matched, nearest-available, or current-at-retrieval). Around this record sits the provider-adapter pattern, which keeps provider-specific retrieval, normalization, redaction, and failure handling behind one application-facing contract. The evaluation is carried by a fixed, versioned inventory of 21 provenance attributes that every emitted record must classify, plus an OpenAPI 3.1 schema with additionalProperties disabled, which turns undocumented fields into validation failures.

What would settle it

Take one real completed job from each of the three providers using the same adapter mappings and compare the live record against the fixture-based record; if any documented field is absent, renamed, or structurally different under real authentication, or if an evidence qualifier misclassifies a live value, the demonstrated conformance fails to transfer to production services.

Watch

Extended reading notes

Core claim

The paper's central claim is that heterogeneous quantum-provider interfaces can be normalized into a single evidence-aware provenance record without erasing the differences that matter for reproducibility. It extends the QProv model with a software-and-access context, adding access method and version, SDK/API version, retrieval timestamp, data-availability metadata, and namespaced technology-specific extensions. Each value in the unified record carries an evidence qualifier distinguishing provider-supplied, aggregator-normalized, provider-pass-through, derived, application-captured, unavailable, not applicable, and not verifiable, so an absent field is no longer ambiguous. The reference prototype demonstrates the claim: a Braket execution routed to IonQ hardware, an IBM Quantum execution, and a direct IonQ execution with probability-histogram results all validate against the same reduced OpenAPI 3.1 contract, each preserving its provider-native result semantics and characterization-association strength. The evaluation classifies a fixed inventory of 21 provenance attributes for every case, no completed record contains an unclassified inventory attribute, and controlled experiments show schema-valid partial records, isolation of a provider field rename to the affected adapter, and backward-compatible additive contract evolution.

Load-bearing premise

The prototype runs on deterministic, sanitized fixtures built from public SDK and API documentation rather than live authenticated provider responses, so everything demonstrated depends on those fixtures faithfully representing how production services actually behave.

Editorial extensions

If this is right

  • Multi-provider applications can access provenance through one contract while provider-specific retrieval and normalization remain localized in adapters.
  • An absent or inapplicable provenance value is represented honestly as unavailable, not applicable, or not captured, rather than as a bare null, so consumers can distinguish not exposed from not meaningful.
  • A change in a provider's input schema can be absorbed inside the affected adapter without invalidating the common record or altering records from other providers.
  • Because compilation provenance is rarely retained on the provider side, complete records require application-side capture of compiler versions, transpilation settings, and random seeds.
  • Aggregator-mediated executions remain distinguishable from direct-provider executions: the platform that managed the job and the operator of the hardware are recorded separately, and pass-through metadata is not presented as normalized metadata.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the evidence-aware contract gains adoption, provenance records could feed reproducibility audits and calibration-aware device selection without requiring providers to expose identical data.
  • The same evidence-qualifier design could transfer to other multi-provider computational ecosystems where field absence is ambiguous, such as cloud machine-learning services or HPC job records.
  • The change-isolation experiment covers one controlled field rename, so whether adapter maintenance stays bounded over real provider-interface churn is still open; the paper itself calls for longitudinal observation.
  • The fixture-based conformance approach could become a provider certification baseline, with credential-free fixtures for reproducibility and live provider-authorized validation as an optional trust tier.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

0 major / 5 minor

Summary. This design-science paper addresses the fragmentation of quantum-computing provenance interfaces. It analyzes publicly documented provenance access across 15 quantum platforms spanning five hardware technologies, maps the results onto a QProv-derived schema extended with software/access context, and proposes an evidence-aware OpenAPI 3.1 provenance contract plus a provider-adapter architecture. The claims are evaluated with a fixture-backed reference prototype at QMill covering an Amazon Braket-to-IonQ execution, an IBM Quantum execution, and a direct IonQ case. The paper reports that all three records validate against one reduced contract, that a fixed 21-attribute inventory leaves no attribute unclassified, that partial records remain schema-valid, that a provider-input rename is isolated to the affected adapter, and that additive schema evolution is backward compatible. The evaluation is explicitly offline: fixtures are constructed from public SDK documentation, schemas, and examples, and the paper repeatedly states that live provider behavior, field population, retention, and permissions are not assessed.

Significance. If accepted as a feasibility study, the paper is a useful contribution to quantum software engineering. Its strengths are the systematic, time-bounded comparison of 15 platforms, the explicit evidence/availability qualifiers that prevent provider-supplied, derived, and application-captured values from being conflated, and a reproducible artifact with deterministic fixtures, drift checks, and 34 passing tests. The central result is appropriately scoped by the authors: the conformance demonstration applies to the three fixture-backed records, not to live authenticated provider services. The skeptic's concern that the contract, adapters, fixtures, and inventory were co-developed is legitimate, and the paper acknowledges it in Sections 6.1 and 7.6; this means the conformance result is evidence of internal consistency and structural feasibility rather than an independent certification of provider interfaces. Read in that light, the paper's claims are defensible and the threats-to-validity discussion is unusually thorough.

minor comments (5)
  1. [Abstract and Section 7.2 (RQ4)] The abstract's "All records validate against one common contract" and the RQ4 answer "can be realized over existing heterogeneous provider interfaces" are stronger than the evaluation supports when read in isolation. Please add an explicit qualifier that validation is against the three fixture-backed demonstration records and that the result establishes structural feasibility, not live-service conformance; Sections 6.1 and 7.6 already state this, so the fix is local wording.
  2. [Section 7.1, Table 11 and Section 6.4, Table 9] Because the fixed 21-attribute inventory was introduced after the implementation cycle refined the evaluation method (Table 11, iteration on 'raw counts of evidence objects'), the absence of unclassified attributes in Table 9 is partly by construction. Please state this explicitly in Section 6.4 so readers do not treat it as an independent conformance check.
  3. [Section 6.4, Table 10] The sentence "adapter sizes are similar across the three structurally different provider integrations, and provider-specific code remains bounded" could be misread as evidence of equal integration complexity. The paper correctly warns earlier that LOC is not an effort measure; consider adding a one-sentence reminder next to Table 10 that similar adapter sizes do not imply similar semantic complexity.
  4. [Throughout] Table captions and headings contain the typo "T able" instead of "Table" (for example, "T able 1", "T able 2", "T able 5", "T able 6", and "T able 11"). Please correct these for consistency.
  5. [Section 7.2, RQ2] The percentages "87% of the platforms were classified as comprehensive and 13% as partial" for execution provenance are reported without the raw counts; given the qualitative coverage matrix and the caveats in Section 7.6, please report the counts (for example, 13 of 15 and 2 of 15) alongside the percentages.

Circularity Check

1 steps flagged · score 3.0 of 10

Fixture-backed conformance is largely an internal-consistency check because contract, adapters, fixtures, and inventory were co-developed; the paper's own validity section concedes the external gap.

  1. self definitional [Section 3.4 (Stage 4), Section 6.4, and Section 7.6]
    "The prototype evaluation used deterministic, sanitized fixtures rather than live authenticated requests. The fixtures were constructed from the public models and interface evidence examined in Stage 2. ... All three completed-job records validated against the same reduced OpenAPI contract."

    The records that 'validate' are generated by the authors' own adapters from fixtures the authors constructed, and they are checked against an OpenAPI contract the authors wrote. Any mismatch could be removed by adjusting the fixture, the adapter, the contract, or the fixed 21-attribute inventory, all of which were refined together in the same Design Science Research build-evaluate cycle. The validation therefore demonstrates internal consistency of one co-designed artifact set rather than independent conformance of real provider interfaces.

full rationale

The paper's cross-provider analysis is anchored in an external model (QProv, reference [5]) and in public SDK/API documentation, schemas, and source code, so that part of the evidence chain is not circular. The design-principles discussion draws on external API-design literature, and no load-bearing uniqueness theorem or self-citation chain is invoked. The main circularity risk is concentrated in the prototype evaluation: the reduced OpenAPI contract, the provider adapters, the sanitized fixtures, the 21-attribute inventory, and the generated records are all products of the same authorial design loop, so 'all records validate against the same contract' is to a significant degree guaranteed by construction rather than discovered from independent provider behavior. The paper is unusually transparent about this threat, explicitly stating that the evaluation is offline, fixture-based, and does not establish field population, retention, permissions, or generalization beyond three cases. These admissions lower the severity: the result is a feasibility demonstration with self-defined conformance criteria, not a forced mathematical derivation or a hidden fit. Hence a moderate score of 3 is appropriate.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No free numerical parameters are fitted to data; the paper introduces no new physical or theoretical entities. The evidence qualifiers, adapter registry, and extension namespaces are software artifacts rather than postulated entities. The central assumptions are the adequacy of QProv as a basis, the use of public documentation as evidence, the fidelity of fixtures, and the one-record-per-job granularity.

assumptions (4)
  • domain assumption The QProv model provides the correct core provenance concepts for quantum executions and can be extended without redefinition.
    Sect. 4.1 states 'we adopt the Quantum Provenance (QProv) model as our conceptual basis'. The schema and the entire coverage matrix inherit QProv's categories.
  • domain assumption Public SDK, REST, and API documentation is a faithful proxy for the provenance actually retrievable by authorized users.
    Sect. 3.4 reports that the study did not authenticate to deployed services; coverage ratings rest on documentation and source code alone, with no operational verification.
  • domain assumption Sanitized fixtures constructed from public models represent real provider responses closely enough to support normalization conclusions.
    Sect. 6.1 describes deterministic fixtures built from public documentation; Sect. 7.6 acknowledges that the construction 'may reflect interpretation errors or omit deployment-specific behavior'.
  • domain assumption A single provenance record per completed job is the right granularity for cross-provider comparison.
    Sect. 4.1: 'The schema follows a one-record-per-job model'. Hybrid workflows with multiple quantum jobs inside one experiment are deferred to future work in Sect. 8.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Toward Standardized Quantum Provenance: A Cross-Provider Analysis, Unified API, and Reference Prototype." pith.science (2026). https://pith.science/paper/3HO2PRYB

@misc{pith2026260808272,
  author       = {Pith},
  title        = {Pith review of: Toward Standardized Quantum Provenance: A Cross-Provider Analysis, Unified API, and Reference Prototype},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3HO2PRYB}},
  note         = {Machine review of arXiv:2608.08272}
}
read the original abstract

Quantum software development requires provenance describing programs, compilation, execution, hardware characterization, results, and software environments, but providers expose this information through heterogeneous software development kits, application programming interfaces, and resource models. We analyze publicly documented provenance access across 15 quantum platforms spanning five hardware technologies and find fragmented, incomplete coverage, with compilation provenance weakest. We propose an evidence-aware OpenAPI 3.1 provenance contract and provider-adapter architecture, evaluated through a fixture-backed reference prototype at QMill covering Amazon Braket, IBM Quantum, and IonQ. All records validate against one common contract while preserving provider-specific semantics, explicit evidence origins, and graceful handling of incomplete data.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 29 canonical work pages

  1. [1]

    Nature638(8052), 920–926 (2024) https://doi.org/10.1038/s41586-024-08449-y

    Acharya, R.,et al.: Quantum error correction below the surface code threshold. Nature638(8052), 920–926 (2024) https://doi.org/10.1038/s41586-024-08449-y

    doi:10.1038/s41586-024-08449-y 2024

  2. [2]

    Nature618(7965), 500–505 (2023) https://doi.org/10.1038/s41586-023-06096-3

    Kim, Y., Eddins, A., Anand, S., Wei, K.X., Berg, E., Rosenblatt, S., Nayfeh, H., Wu, Y., Zaletel, M., Temme, K., Kandala, A.: Evidence for the utility of quantum computing before fault tolerance. Nature618(7965), 500–505 (2023) https://doi.org/10.1038/s41586-023-06096-3

    doi:10.1038/s41586-023-06096-3 2023

  3. [3]

    Quantum2, 79 47 (2018) https://doi.org/10.22331/q-2018-08-06-79

    Preskill, J.: Quantum computing in the NISQ era and beyond. Quantum2, 79 47 (2018) https://doi.org/10.22331/q-2018-08-06-79

    doi:10.22331/q-2018-08-06-79 2018

  4. [4]

    https://github.com/qir- alliance/qir- spec

    QIR Alliance: QIR Specification. https://github.com/qir- alliance/qir- spec. Accessed July 2026 (2025)

    work page 2025

  5. [5]

    IET Quantum Communication2(4), 171–181 (2021) https://doi.org/10.1049/qtc2.12012

    Weder, B., Barzen, J., Leymann, F., Salm, M., Wild, K.: QProv: A provenance system for quantum computing. IET Quantum Communication2(4), 171–181 (2021) https://doi.org/10.1049/qtc2.12012

    doi:10.1049/qtc2.12012 2021

  6. [6]

    https://spec.openapis.org/oa s/v3.1.0.html

    OpenAPI Initiative: OpenAPI Specification v3.1.0. https://spec.openapis.org/oa s/v3.1.0.html. Accessed July 2026 (2021)

    work page 2021

  7. [7]

    Quantum Science and Technology5(4), 044007 (2020) https: //doi.org/10.1088/2058-9565/abae7d

    Leymann, F., Barzen, J.: The bitter truth about gate-based quantum algorithms in the NISQ era. Quantum Science and Technology5(4), 044007 (2020) https: //doi.org/10.1088/2058-9565/abae7d

    doi:10.1088/2058-9565/abae7d 2020

  8. [8]

    Cambridge university press, Cambridge, UK (2010)

    Nielsen, M.A., Chuang, I.L.: Quantum Computation and Quantum Information, 10th anniversary edn. Cambridge university press, Cambridge, UK (2010)

    work page 2010

Show all 48 references
  1. [9]

    https://qx.vtt.fi/docs/advanced/advanced-qc

    VTT: VTT Advanced QC Usage. https://qx.vtt.fi/docs/advanced/advanced-qc. html. Accessed July 2026

    2026

  2. [10]

    Computing 107(4), 99 (2025) https://doi.org/10.1007/s00607-025-01450-x

    Kinanen, O., Mu˜ noz-Moller, A.D., Stirbu, V., Murillo, J.M., Mikkonen, T.: Toolchain for faster iterations in quantum software development. Computing 107(4), 99 (2025) https://doi.org/10.1007/s00607-025-01450-x

    2025 doi

  3. [11]

    https: //arxiv.org/abs/2007.07047

    Zhao, J.: Quantum Software Engineering: Landscapes and Horizons (2021). https: //arxiv.org/abs/2007.07047

    2021 arXiv

  4. [12]

    CEUR Workshop Proceedings 2561, 1–5 (2020)

    Piattini, M., Peterssen, G., P´ erez-Castillo, R.,et al.: The Talavera manifesto for quantum software engineering and programming. CEUR Workshop Proceedings 2561, 1–5 (2020)

    2020

  5. [13]

    Communications of the ACM65(4), 84–88 (2022) https://doi.org/10.1145/3512 340

    Ali, S., Yue, T., Abreu, R.: When software engineering meets quantum computing. Communications of the ACM65(4), 84–88 (2022) https://doi.org/10.1145/3512 340

    2022 doi

  6. [14]

    De Stefano, M., Pecorelli, F., Di Nucci, D., Palomba, F., De Lucia, A.: Software engineering for quantum programming: How far are we? Journal of Systems and Software190, 111326 (2022) https://doi.org/10.1016/j.jss.2022.111326

    2022

  7. [15]

    arXiv preprint arXiv:2405.08810 (2024)

    Javadi-Abhari, A., Treinish, M., Krsulich, K., Wood, C.J., Lishman, J., Gacon, J., Martiel, S., Nation, P.D., Bishop, L.S., Cross, A.W., Johnson, B.R., Gambetta, J.M.: Quantum Computing with Qiskit. arXiv preprint arXiv:2405.08810 (2024)

    2024 arXiv

  8. [16]

    https://github.com/quantumlib/Cirq

    Google Quantum AI: Cirq. https://github.com/quantumlib/Cirq. Version 1.7.0; accessed July 2026 (2026) 48

    2026

  9. [17]

    https://github.com/a mazon-braket/amazon-braket-sdk-python

    Amazon Web Services: Amazon Braket SDK for Python. https://github.com/a mazon-braket/amazon-braket-sdk-python. Version 1.123.0; accessed July 2026 (2026)

    2026

  10. [18]

    Science354(6317), 1240–1241 (2016) https://doi.org/10.1126/science

    Stodden, V., McNutt, M., Bailey, D.H., Deelman, E., Gil, Y., Hanson, B., Heroux, M.A., Ioannidis, J.P.A., Taufer, M.: Enhancing reproducibility for computational methods. Science354(6317), 1240–1241 (2016) https://doi.org/10.1126/science. aah6168

    2016 doi

  11. [19]

    Science334(6060), 1226–1227 (2011) https://doi.org/10.1126/science.1213847

    Peng, R.D.: Reproducible research in computational science. Science334(6060), 1226–1227 (2011) https://doi.org/10.1126/science.1213847

    2011 doi

  12. [20]

    https://www.acm.org/publications/policies/artifact-review-and-badging-curre nt

    Association for Computing Machinery: Artifact Review and Badging – Current. https://www.acm.org/publications/policies/artifact-review-and-badging-curre nt. Accessed July 2026 (2020)

    2020

  13. [21]

    In: 2023 IEEE International Conference on Quantum Computing and Engineering (QCE), pp

    Senapati, P., Wang, Z., Jiang, W., Humble, T.S., Fang, B., Xu, S., Guan, Q.: Towards Redefining the Reproducibility in Quantum Computing: A Data Anal- ysis Approach on NISQ Devices . In: 2023 IEEE International Conference on Quantum Computing and Engineering (QCE), pp. 468–474...

    2023 doi

  14. [22]

    Herschel, M., Diestelk¨ amper, R., Ben Lahmar, H.: A survey on provenance: What for? what form? what from? The VLDB Journal26(6), 881–906 (2017) https: //doi.org/10.1007/s00778-017-0486-1

    2017 doi

  15. [23]

    In: Proceedings of the 2008 ACM SIGMOD International Con- ference on Management of Data

    Davidson, S.B., Freire, J.: Provenance and scientific workflows: challenges and opportunities. In: Proceedings of the 2008 ACM SIGMOD International Con- ference on Management of Data. SIGMOD ’08, pp. 1345–1350. Association for Computing Machinery, New York, NY, USA (2008). htt...

    2008

  16. [24]

    SIGMOD Rec.34(3), 31–36 (2005) https://doi.org/10.1145/1084805.1084812

    Simmhan, Y.L., Plale, B., Gannon, D.: A survey of data provenance in e-science. SIGMOD Rec.34(3), 31–36 (2005) https://doi.org/10.1145/1084805.1084812

    2005

  17. [25]

    Concurrency and Computation: Practice and Experience18(10), 1039–1065 (2006) https://doi.org/10.1002/cpe.994

    Lud¨ ascher, B., Altintas, I., Berkley, C., Higgins, D., Jaeger, E., Jones, M., Lee, E.A., Tao, J., Zhao, Y.: Scientific workflow management and the Kepler sys- tem. Concurrency and Computation: Practice and Experience18(10), 1039–1065 (2006) https://doi.org/10.1002/cpe.994

    2006 doi

  18. [26]

    Future Generation Computer Systems 46, 17–35 (2015) https://doi.org/10.1016/j.future.2014.10.008

    Deelman, E., Vahi, K., Juve, G., Rynge, M., Callaghan, S., Maechling, P.J., Mayani, R., Chen, W., Silva, R., Livny, M., Wenger, K.: Pegasus, a workflow man- agement system for science automation. Future Generation Computer Systems 46, 17–35 (2015) https://doi.org/10.1016/j.fut...

    2015 doi

  19. [27]

    In: Proceedings of the 13th IEEE/ACM International Conference on Utility and Cloud Computing (UCC), pp

    Weder, B., Breitenb¨ ucher, U., Leymann, F., Wild, K.: Integrating quantum 49 computing into workflow modeling and execution. In: Proceedings of the 13th IEEE/ACM International Conference on Utility and Cloud Computing (UCC), pp. 279–291 (2020). https://doi.org/10.1109/UCC4898...

    2020

  20. [28]

    https://arxiv.org/abs/ 2507.06990

    Gamage, M., Kinanen, O., Muff, J., Stirbu, V.: Enhancing Quantum Software Development Process with Experiment Tracking (2025). https://arxiv.org/abs/ 2507.06990

    2025 arXiv

  21. [29]

    In: Proceedings of the Fourth International Workshop on Data Management for End-to-End Machine Learning

    Chen, A.,et al.: Developments in MLflow: A system to accelerate the machine learning lifecycle. In: Proceedings of the Fourth International Workshop on Data Management for End-to-End Machine Learning. DEEM ’20. Association for Com- puting Machinery, New York, NY, USA (2020). h...

    2020 doi

  22. [30]

    Peffers, K., Tuunanen, T., Rothenberger, M., Chatterjee, S.: A design science research methodology for information systems research. J. Manage. Inf. Syst. 24(3), 45–77 (2007) https://doi.org/10.2753/MIS0742-1222240302

    2007 doi

  23. [31]

    Version 0.1.0 (2026)

    Peltonen, J.: Quantum Provenance Prototype: reproducible reference artifact. Version 0.1.0 (2026). https://doi.org/10.5281/zenodo.21451599

    2026 doi

  24. [32]

    https://unitaryfound ation.github.io/survey-2025/

    Unitary Foundation: 2025 Quantum Open Source Survey. https://unitaryfound ation.github.io/survey-2025/. Accessed July 2026 (2025)

    2025

  25. [33]

    https://quantum.cloud.ibm.com/ docs/en/api/qiskit/release-notes/2.5

    IBM Quantum: Qiskit SDK Release Notes. https://quantum.cloud.ibm.com/ docs/en/api/qiskit/release-notes/2.5. Qiskit SDK 2.5.0, released July 2, 2026; accessed July 2026 (2026)

    2026

  26. [34]

    https://quantum.cloud

    IBM Quantum: Qiskit Runtime Client Release Notes. https://quantum.cloud. ibm.com/docs/en/api/qiskit-ibm-runtime/release-notes. qiskit-ibm-runtime 0.47.0, released May 12, 2026; accessed July 2026 (2026)

    2026

  27. [35]

    https://quantum.cloud.ibm.com/ docs/en/api/qiskit-runtime-rest

    IBM Quantum: Qiskit Runtime REST API. https://quantum.cloud.ibm.com/ docs/en/api/qiskit-runtime-rest. API version 2026-04-15; accessed July 2026 (2026)

    2026

  28. [36]

    In: Pro- ceedings of the 21st International Conference on Mining Software Repositories, pp

    Serbout, S., Pautasso, C.: APIstic: A large collection of openapi metrics. In: Pro- ceedings of the 21st International Conference on Mining Software Repositories, pp. 265–277 (2024). https://doi.org/10.1145/3643991.3644933

    2024

  29. [37]

    Manning Publications, Shelter Island, NY (2019)

    Lauret, A.: The Design of Web APIs. Manning Publications, Shelter Island, NY (2019)

    2019

  30. [38]

    ACM Transactions on Quantum Computing3(3), 1–50 (2022) https://doi.org/10.1145/3505636 50

    Cross, A., Javadi-Abhari, A., Alexander, T., Beaudrap, N., Bishop, L.S., Heidel, S., Ryan, C.A., Sivarajah, P., Smolin, J., Gambetta, J.M., Johnson, B.R.: Open- QASM 3: A broader and deeper quantum assembly language. ACM Transactions on Quantum Computing3(3), 1–50 (2022) https...

    2022 doi

  31. [39]

    https://arxiv.org/abs/1608.03355

    Smith, R.S., Curtis, M.J., Zeng, W.J.: A Practical Quantum Instruction Set Architecture (2017). https://arxiv.org/abs/1608.03355

    2017 arXiv

  32. [40]

    Soft- ware: Practice and Experience52(1), 66–114 (2022) https://doi.org/10.1002/sp e.3039

    Gill, S.S., Kumar, A., Singh, H., Singh, M., Kaur, K., Usman, M., Buyya, R.: Quantum computing: A taxonomy, systematic review and future directions. Soft- ware: Practice and Experience52(1), 66–114 (2022) https://doi.org/10.1002/sp e.3039

    2022 doi

  33. [41]

    PhD thesis, University of California, Irvine (2000)

    Fielding, R.T.: Architectural styles and the design of network-based software architectures. PhD thesis, University of California, Irvine (2000)

    2000

  34. [42]

    In: Proceedings of the 24th European Conference on Pattern Languages of Pro- grams (EuroPLoP), pp

    L¨ ubke, D., Zimmermann, O., Pautasso, C., Zdun, U., Stocker, M.: Interface evolu- tion patterns: Balancing compatibility and extensibility across service life cycles. In: Proceedings of the 24th European Conference on Pattern Languages of Pro- grams (EuroPLoP), pp. 1–24 (2019...

    2019

  35. [43]

    Paltenghi, M., Pradel, M.: Bugs in quantum computing platforms: an empirical study. Proc. ACM Program. Lang.6(OOPSLA1) (2022) https://doi.org/10.114 5/3527330

    2022

  36. [44]

    https://onnx.ai/

    ONNX Community: Open Neural Network Exchange (ONNX). https://onnx.ai/. Accessed July 2026 (2024)

    2024

  37. [45]

    In: IEEE Data Engineering Bulletin, vol

    Zaharia, M., Chen, A., Davidson, A., Ghodsi, A., Hong, S.A., Konwinski, A., Murching, S., Nykodym, T., Ogilvie, P., Parkhe, M., Xie, F., Zumar, C.: Accel- erating the machine learning lifecycle with MLflow. In: IEEE Data Engineering Bulletin, vol. 41, pp. 39–45 (2018)

    2018

  38. [46]

    W3c recommendation, World Wide Web Consortium (2013)

    Moreau, L., Missier, P., Belhajjame, K., B’Far, R., Cheney, J., et al.: PROV-DM: The PROV data model. W3c recommendation, World Wide Web Consortium (2013). Accessed: July 2026. https://www.w3.org/TR/prov-dm/

    2013

  39. [47]

    https://www.newquantumera.com/blog/why-i-joined-the-unitary-foundat ion-and-what-im-planning-to-do/

    Hassinger, S.: Why I Joined the Unitary Foundation and What I’m Planning to Do. https://www.newquantumera.com/blog/why-i-joined-the-unitary-foundat ion-and-what-im-planning-to-do/. Blog post. Accessed July 2026 (2026)

    2026

  40. [48]

    Springer, Berlin, Heidelberg (2012)

    Wohlin, C., Runeson, P., H¨ ost, M., Ohlsson, M.C., Regnell, B., Wessl´ en, A.: Experimentation in Software Engineering. Springer, Berlin, Heidelberg (2012). https://doi.org/10.1007/978-3-642-29044-2 8 51

    2012 doi

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.