{"id":"d32af0d3-a3ff-43d7-a600-4ff2817e400d","arxiv_id":"2608.08272","paper_version":1,"verdict":"ACCEPT","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A cross-provider analysis of 15 quantum platforms finds fragmented provenance access, and a unified OpenAPI contract with provider adapters is shown to normalize representative records while preserving evidence origins.","lead":"This paper compares how 15 quantum computing platforms expose provenance data such as programs, calibration, and results, and finds the coverage fragmented and incomplete. It then proposes a unified, evidence-aware API with provider adapters, demonstrated on a fixture-backed prototype for Amazon Braket, IBM Quantum, and IonQ.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Fixture-backed conformance may be self-confirming: the contract, adapters, fixtures, and 21-attribute inventory were co-developed, so \"all records validate\" could reflect internal alignment rather than faithful normalization of real provider interfaces.","rationale":"The reader's weakest assumption identified fixture fidelity, and that is exactly the load-bearing concern here. The paper's own limitations sections explicitly restrict the demonstration to deterministic, sanitized fixtures and deny claims about live field population, retention, or reliability, so the acceptance verdict remains appropriate for the scoped claim of structural feasibility. The concern does not invalidate the paper, but it should be flagged as the key residual risk: a future provider-authorized validation against real authenticated responses would settle whether the demonstrated conformance transfers. Such a test is a natural next step rather than a condition for accepting this design-science artifact, because the paper already frames itself as a reference prototype and includes reproducible artifacts and drift checks as support.","tokens_in":29464,"tokens_out":5526,"duration_ms":58101,"concrete_test":"Run the unmodified reference prototype's Amazon Braket, IBM, and IonQ adapters against an independently captured hold-out corpus of authenticated provider responses that were not used to build the fixtures, for example archived Qiskit Runtime job and backend responses from a public issue or integration test, a Braket task and device response, and an IonQ API response. If any record fails OpenAPI validation, or if supporting the real responses requires changes to the shared contract or more than version-number updates to the adapters, the demonstrated conformance is fixture-specific rather than a property of the proposed architecture; if all records validate with evidence qualifiers correctly assigned by an independent annotator, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim generalizes from three prototype records to heterogeneous provider interfaces, and that generalization depends on a condition the paper does not test: that the sanitized fixtures are faithful surrogates for authenticated provider data. Section 6.1 states that the evaluation is entirely offline and that fixtures were constructed from public SDK documentation, public data models, source code, schemas, and examples. Section 7.6 concedes that the prototype fixtures may reflect interpretation errors or omit deployment-specific behavior such as retention, permissions, and field population. Because the same authors also wrote the reduced OpenAPI contract, the adapters, and the fixed inventory, a passing validation is not an independent check: any mismatch could be removed by adjusting one of the co-designed pieces until it conformed. The provider-input and schema-evolution experiments are controlled changes on those same fixtures, so they test the adapter boundary under author-selected perturbations, not under the ambiguity of real absent fields, retention limits, renamed fields, or account-specific permissions. The paper is honest about this limitation, but the limitation is load-bearing because the abstract's \"All records validate\" and the RQ4 answer \"can be realized over existing heterogeneous provider interfaces\" invite the reader to infer more than the demonstration supports.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":29689,"tokens_out":7372,"duration_ms":67661,"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.","major_comments":[],"minor_comments":[{"comment":"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.","section":"Abstract and Section 7.2 (RQ4)"},{"comment":"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.","section":"Section 7.1, Table 11 and Section 6.4, Table 9"},{"comment":"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.","section":"Section 6.4, Table 10"},{"comment":"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.","section":"Throughout"},{"comment":"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.","section":"Section 7.2, RQ2"}],"recommendation":"minor_revision","confidential_remarks":"The paper is honest about its fixture-backed limitation, and the stress-test concern about self-confirming conformance is already addressed in the body. The main improvement needed is to align the abstract and RQ4 wording with the scoped claims already present in Sections 6.1, 6.5, and 7.6. I see no need for additional experiments before publication, provided the requested wording clarifications are made."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things to know. First, the genuinely new contribution is the 15-platform coverage matrix, which is the first systematic quantification I know of for how fragmented compilation provenance is across quantum providers, plus the evidence-aware extension of QProv with software/access context, availability qualifiers, and platform-vs-hardware attribution. Second, the prototype validation is self-contained: contract, adapters, fixtures, and the 21-attribute inventory were co-developed, so \"all records validate\" is a statement about internal consistency, not independent confirmation against live provider behavior. The paper admits this in Section 7.6. What it does well: the methodology is careful and the scope is unusually honest. The analysis is explicitly a time-bounded snapshot of public documentation, with retired interfaces excluded and conservative ratings where evidence was thin. The distinction between provider-supplied, aggregator-normalized, pass-through, derived, and application-captured values is well designed and directly addresses a real reproducibility problem. The artifact ships with tests, drift checks, and a versioned inventory. That is reproducible evidence and deserves credit. The soft spots are real but mostly disclosed. The fixture fidelity issue is load-bearing if you read the abstract as claiming production-ready normalization; the paper itself is careful to call the demonstration structural feasibility. The RQ4 answer \"can be realized over existing heterogeneous provider interfaces\" is a bit generous — the fixtures were built from those interfaces, but interaction with retention, permissions, renamed fields, and account-specific behavior is untested. The coverage matrix uses a qualitative three-level scale, which simplifies complex differences, though the supplementary profiles mitigate that. Only three integrations are prototyped, with direct IonQ as a supplementary case. These are limitations, not hidden flaws. The stress-test concern lands, but not fatally. The paper does not claim live conformance; it claims a reproducible feasibility demonstration, and that claim holds. My main editorial suggestion is to tighten the abstract so \"all records validate\" is explicitly tied to the fixture-backed prototype. Who this is for: quantum software engineers, reproducibility researchers, and anyone building multi-provider tooling. It deserves a serious referee; the coverage matrix alone is worth engaging with.","headline":"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.","tokens_in":703,"tokens_out":778,"would_cite":true,"duration_ms":26933,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A single evidence-aware contract can hold quantum provenance records from many providers without erasing their differences.","keywords":["quantum provenance","quantum software engineering","OpenAPI 3.1 contract","provider adapters","multi-provider quantum computing","evidence-aware API","reproducibility","fixture-based evaluation"],"falsifier":"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.","tokens_in":29293,"feed_emoji":"⚛️","tokens_out":6634,"duration_ms":57656,"temperature":0.7,"pith_summary":"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.","feed_headline":"One evidence-aware contract unifies quantum provenance data","feed_subtitle":"Providers expose different fields through different interfaces; a normalized record keeps those differences explicit.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the QProv provenance model that the unified schema extends with software-access context and evidence qualifiers.","marker":"[5]"},{"why":"Defines the OpenAPI 3.1 contract language used for the unified API and its strict validation.","marker":"[6]"},{"why":"Provides the public Braket SDK models and examples used to build the Braket-IonQ fixture and adapter mapping.","marker":"[17]"},{"why":"Contains the OpenAPI contract, fixtures, attribute inventory, generated records, and evaluation report that make the demonstration reproducible.","marker":"[31]"},{"why":"Documents Qiskit client-side circuit and transpilation structures used for the IBM case's application-captured context.","marker":"[33]"},{"why":"Documents the runtime job methods and properties used in the IBM adapter mapping.","marker":"[34]"},{"why":"Documents the REST resources behind IBM job, backend, and result retrieval.","marker":"[35]"}],"fun_headline_variants":["One contract tracks quantum provenance across 15 platforms","Evidence-aware API unifies fragmented quantum provenance","Quantum provenance normalized with explicit evidence tags","Braket, IBM, IonQ fit one provenance schema","Cross-provider quantum provenance: one contract, no ambiguity"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["One contract tracks quantum provenance across 15 platforms","Evidence-aware API unifies fragmented quantum provenance","Quantum provenance normalized with explicit evidence tags","Braket, IBM, IonQ fit one provenance schema","Cross-provider quantum provenance: one contract, no ambiguity"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000166,"raw_usage":{"total_tokens":1220,"prompt_tokens":880,"completion_tokens":340,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":496,"completion_tokens_details":{"reasoning_tokens":268}},"tokens_in":496,"tokens_out":340,"duration_ms":4114,"temperature":1.0,"reasoning_tokens":268,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T00:11:15.843022+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"https://spec.openapis.org/oa s/v3.1.0.html","cited_arxiv_id":null,"evidence_quote":"Defines the OpenAPI 3.1 contract language used for the unified API and its strict validation."},{"cited_title":"https://github.com/a mazon-braket/amazon-braket-sdk-python","cited_arxiv_id":null,"evidence_quote":"Provides the public Braket SDK models and examples used to build the Braket-IonQ fixture and adapter mapping."},{"cited_title":"Version 0.1.0 (2026)","cited_arxiv_id":null,"evidence_quote":"Contains the OpenAPI contract, fixtures, attribute inventory, generated records, and evaluation report that make the demonstration reproducible."},{"cited_title":"https://quantum.cloud.ibm.com/ docs/en/api/qiskit/release-notes/2.5","cited_arxiv_id":null,"evidence_quote":"Documents Qiskit client-side circuit and transpilation structures used for the IBM case's application-captured context."},{"cited_title":"https://quantum.cloud","cited_arxiv_id":null,"evidence_quote":"Documents the runtime job methods and properties used in the IBM adapter mapping."},{"cited_title":"https://quantum.cloud.ibm.com/ docs/en/api/qiskit-runtime-rest","cited_arxiv_id":null,"evidence_quote":"Documents the REST resources behind IBM job, backend, and result retrieval."}],"review_version":1}