Propose new entry: Unverifiable Computation and Job Provenance (platform surface)

[Treyrob3]

Proposing a new platform-surface entry for Sprint 1 consideration, using the standard template.

The gap. The three existing platform entries are all confidentiality-oriented. QS08 covers harm caused by co-tenants, QS09 covers compromise of a toolchain component, QS10 covers leakage through the control plane. None covers integrity and assurance in the absence of any compromise: whether the job ran as specified, on the hardware advertised, and whether the returned result can be trusted at all. Even with a trusted toolchain, a dedicated allocation and no observable side channel, the tenant currently has no means to verify what executed.

Why it is not speculative. Upadhyay and Ghosh demonstrate that less-trusted vendors can tamper with executions to return suboptimal results, and propose a run-adaptive shot-splitting heuristic that identifies untrustworthy hardware at runtime (Frontiers in Computer Science 2024; earlier work at HASP 2022 models tampering of input parameters and measurement outcomes on QAOA). The tampering is hard to detect precisely because quantum results are probabilistic — a degraded or misrouted execution is indistinguishable from ordinary NISQ noise. Tagged demonstrated under the maturity convention.

Why it matters commercially. The workloads with the strongest case for quantum are those where the answer is not classically computable, which is exactly where the tenant has no independent way to check the result. As QPU access is increasingly brokered and resold, the tenant is often several steps removed from the hardware.

On surface balance. The current draft runs seven migration entries to three platform entries, and the sprint plan flags platform-surface coverage as actively sought and surface balance as a Sprint 3 objective. This entry is offered with that in mind.

Notes for reviewers. Numbering left as QSxx since placement is for Sprint 1 voting. Scope boundaries against QS08, QS09 and QS10 are stated explicitly in the entry, following the pattern QS02 uses against QS01 — happy to sharpen those if you see overlap I have not accounted for. Reference 3 links to IEEE Xplore rather than a DOI as I could not verify the DOI string; happy to swap it if you have it.

[Treyrob3]

Cross-referencing #16 @meridianverity , since the two touch adjacent ground and I'd rather surface the boundary than leave reviewers to infer it.

#16 adds provenance controls binding a submitted job to the dispatched artifact and the returned result record. Its Non-goals list explicitly excludes:

• "Independent proof of physical QPU execution without an appropriate controller- or hardware-rooted evidence source"
• "Proof of mathematical, semantic, or fidelity correctness of a returned result"

Those two exclusions are this entry's subject. #16 establishes that a provider's record is internally consistent and traceable; this entry covers whether that record can be trusted as evidence in the first place. A provider assertion is not proof the job ran on the advertised hardware, and Upadhyay and Ghosh demonstrate vendors tampering with executions in ways a self-reported record would not reveal.

It also covers cases the job-to-dispatch model does not reach: brokered or resold access where the tenant has no direct relationship with the operator, and workloads whose results cannot be validated by any means because the answer is not classically computable.

So I read them as complementary — #16 hardens the pipeline, this entry addresses what remains unverifiable even once the pipeline is sound. Happy to sharpen the boundary language in the entry if reviewers see the split differently.

Thanks!

[meridianverity]

Greetings — thank you for cross-referencing #16 and for making the boundary explicit. I agree that this proposal identifies a real and important adjacent platform risk, and that it can sit cleanly beside #16 with a few precision refinements.

The distinction I would preserve is:

Integrity-verifiable traceability can establish linkage within a defined trust boundary; it does not, by itself, establish that the underlying execution occurred as claimed. A provider-generated record remains a provider assertion.

One precision point on the description of #16 : I would avoid saying that it “establishes that a provider’s record is internally consistent and traceable.” #16 proposes controls for integrity-verifiable linkage across the submitted job, security-relevant transformations, the artifact and platform context identified at dispatch, and the returned result record. It also requires the record producer and applicable trust boundary to be identified. It does not establish the truth or internal consistency of any particular provider record.

A tighter formulation might be:

#16 addresses integrity-verifiable linkage and traceability across the submission-to-dispatch-to-result-record lineage within the applicable trust boundary. This entry addresses what evidence permits independent appraisal of the underlying execution and returned result.

Because provenance is already central to #16 , a title centered on Unverifiable Quantum Execution and Result Assurance may distinguish the entries more clearly.

I would also narrow the opening scope statement. QS08 includes fidelity degradation as well as confidentiality risks, and the cited threat model still involves adversarial provider behavior, so “in the absence of any compromise” may be too broad. A more precise formulation could be:

None of the current platform entries centers assurance of the underlying execution and returned result when the tenant-side toolchain and co-tenant isolation boundaries are otherwise intact.

A few evidence refinements may strengthen the entry as well. Upadhyay and Ghosh model and experimentally evaluate adversarial result tampering by less-trusted providers; the paper does not document an actual vendor incident. The “Demonstrated” maturity tag may still be appropriate under the project’s proof-of-concept convention, but Scenario #1’s inferior-device substitution and shot-count truncation would benefit from separate support or narrower attribution.

I would also avoid equating an answer that is unknown in advance with one that admits no independent validation. “May not admit economically practical independent validation at the relevant scale” would be more precise, as would “may lack evidence sufficient to independently assess what executed or whether the returned result was manipulated” rather than “has no means to verify.”

Finally, DORA Articles 28–30 support risk-based contracting, subcontracting oversight, service-level and performance monitoring, and audit rights, but they do not prescribe per-job QPU attestation. I would therefore describe missing execution evidence as something that may create a contractual or oversight gap in the applicable circumstances, rather than as a gap directly mandated by DORA.

With those refinements, I think the entry would be clearly differentiated from #16 and would materially strengthen the platform taxonomy. Thank you again for surfacing the relationship so constructively and for giving the boundary the care it deserves.

[Treyrob3]

Thank you — these are fair and I've applied all of them.

You're right that "establishes that a provider's record is internally consistent and traceable" mischaracterised #16, and I've adopted your formulation: #16 addresses integrity-verifiable linkage across the submission-to-dispatch-to-result lineage within the applicable trust boundary; this entry addresses what evidence permits independent appraisal of the underlying execution and returned result.

Retitled to Unverifiable Quantum Execution and Result Assurance. Provenance is genuinely central to #16 and the old title pointed at your subject rather than mine.

Narrowed the scope statement — "in the absence of any compromise" was too broad given QS08 covers fidelity degradation and the cited threat model is adversarial provider behaviour. Used your formulation about tenant-side toolchain and co-tenant isolation boundaries being otherwise intact.

On evidence: I've made the attribution precise about what Upadhyay and Ghosh model and experimentally evaluate, and added an explicit note that no public vendor incident is claimed. Scenario #1 now describes only the tampering class the paper covers; the inferior-device-substitution and shot-count material moved to a vulnerability example, and Scenario #2 is labelled illustrative.

You were also right that I conflated an answer being unknown in advance with one admitting no independent validation — those aren't the same thing, and plenty of hard problems have cheap solution checks. Reworded to "may not admit economically practical independent validation at the relevant scale."

DORA reframed as risk-based contracting, subcontracting oversight, performance monitoring and audit rights, with missing execution evidence described as something that may create a contractual or oversight gap rather than a gap DORA mandates.

I also added RFC 9334 as a reference and built a prevention control and vulnerability example around the assertion-versus-appraised-evidence distinction, since that's the cleanest anchor for the boundary between our two entries.

[meridianverity]

Thank you — I reviewed the updated commit, and this is an exceptionally thoughtful revision.

The new title and scope now distinguish the entry cleanly from #16, and the refinements to the evidence characterization, scenarios, DORA mapping, and RFC 9334 boundary materially strengthen the proposal. In particular, the distinction between a provider assertion and independently appraised evidence is now explicit without overstating what either entry establishes.

I have no further substantive comments at this stage. One small housekeeping point: if the pull-request title still displays the former title, it may be worth aligning it with the renamed entry when convenient.

I sincerely appreciate how carefully and constructively you handled the review. The revision preserves the distinct contribution of both entries and makes the overall platform taxonomy stronger.