QS09: add job-to-dispatch integrity controls

[meridianverity]

Summary

This PR adds a narrow, emerging quantum-specific control to QS09: integrity
continuity from a submitted quantum job through security-relevant
transformations to the exact artifact and platform context identified at
dispatch, and from that lineage to the returned result record.

The proposed controls address substitution, omission, mismatch, and loss of
traceability across quantum-toolchain stages without asserting that a
provider-generated record independently proves physical QPU execution or
result correctness.

Relationship to PR #14

PR #14 covers conformance between a custom gate's declared gate-level scope
and behavior and its pulse-level implementation.

This PR intentionally excludes gate-to-pulse conformance and pulse-semantic
validation. It addresses whether the artifact dispatched remains
integrity-linked to the submitted job and its security-relevant transformation
lineage, and whether the returned result record identifies the
platform-reported execution context, record producer, and applicable trust
boundary.

The two proposals therefore address adjacent but distinct QS09 integrity
boundaries.

Evidence classification

Emerging quantum-specific adaptation.

QProv presents quantum-specific provenance collection across circuit,
computer, compilation, and execution attributes. CHEQ outlines an emerging
controller-side circuit-integrity design. SLSA and RFC 9334 provide established
generic provenance and attestation models.

The cited sources support separate parts of the proposed control. No single
source is claimed to establish or deploy the combined end-to-end control, and
this PR does not represent it as an existing quantum-platform standard or as
independent proof of physical QPU execution.

Non-goals

• Gate-to-pulse conformance or pulse-semantic validation addressed in PR QS09: add pulse-level circuit attack class (Xu & Szefer, IEEE S&P 2025) #14
• QPU tenant isolation addressed in QS08
• Side-channel or control-plane exposure addressed in QS10
• 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
• A vendor-specific receipt schema, product, protocol, or implementation

Changes

• Adds one description paragraph defining the job-to-dispatch integrity gap
• Adds one common vulnerability example
• Adds three actionable prevention controls
• Adds one non-overlapping artifact-substitution scenario
• Adds three supporting references and refines existing framework and
  regulatory references
• Updates the standards and regulatory mapping

[Treyrob3]

Greetings, I actually just saw your PR. I am the author of #14 .

Thanks for writing up the relationship section — that boundary matches how I'd describe it from my side too. #14 is about whether a custom gate's pulse implementation matches what its gate-level description declares. Yours is about whether the artifact that actually gets dispatched is still linked to what was submitted. Agreed those are distinct.

One practical thing though: I think our two PRs will conflict textually even though we're deconflicted on scope. We both insert items directly after Common Examples 5 and after How to Prevent 5, and we both modify the Reference Links list and the Standards and Regulatory Mapping paragraph. GitHub shows us each as clean because it only checks against base, not against other open PRs — so whichever one merges second will need a rebase.

Happy for that to be me. If yours lands first I'll rework #14 on top of it: renumber my additions and slot the Xu & Szefer reference into your reordered list. Or if the maintainers would rather sequence it the other way, that works too.

Thank you!

[meridianverity]

Greetings — thank you for the thoughtful note, and for the care you have taken to make #14 technically precise and clearly bounded.

I agree fully with your description of the boundary. Your contribution addresses an important conformance question: whether a custom gate’s pulse-level implementation remains faithful to its declared gate-level scope and behavior. #16 addresses the separate but complementary question of whether the artifact actually dispatched remains integrity-linked to the submitted job and its security-relevant transformation lineage. I am glad that the distinction reads the same from both sides.

You are also exactly right about the likely textual conflict. Although the two contributions are technically distinct, they modify several of the same locations in the document. I have no preference on merge order. If #14 lands first, I will rebase #16 onto the updated main branch and handle the renumbering and integration of the references and standards mapping on my side. If #16 lands first, I sincerely appreciate your generous offer to make the corresponding updates to #14.

I will keep #16 stable unless the maintainers request substantive changes, and we can coordinate the mechanical integration once the merge sequence is clear. I would also be glad to review the combined result afterward so that both contributions remain clearly distinguished, accurately represented, and fully preserved in the final text.

Thank you again for identifying this early and for approaching it with such professionalism and generosity. I genuinely appreciate the substance of your work on #14, and I am grateful that these two contributions can complement one another and strengthen QS09 together.