A portable provenance pattern for Qiskit Runtime workflows

An exploratory community note on binding source-side AI and origin evidence to canonical Qiskit Runtime sessions and jobs without changing the Runtime model itself.

Status Draft discussion note. Narrow goal: invite feedback on an additive provenance pattern that binds declared-AI and source-origin evidence to a Runtime execution record without claiming to redefine Qiskit Runtime, in-toto, or transparency-log standards.

Narrow goal

Qiskit Runtime already gives teams canonical execution handles such as a session or job identifier. AIIR adds a narrower question at the source boundary: was AI involvement declared for the code, circuit package, or workload manifest that produced this Runtime submission, and is that declaration tied to a verifiable receipt?

The useful public shape is additive. Keep the Runtime submission model intact, keep the attestation model intact, and carry one more verifiable provenance bundle alongside the execution record.

Execution-binding pattern

The smallest public pattern has three artifacts:

An AIIR receipt or AIIR-wrapped in-toto Statement for the source change or workload package.
A transparency-log record or proof bundle that timestamps the signed attestation.
A Qiskit Runtime job or session record that stores references to those two artifacts.

{
	"runtime": {
		"provider": "qiskit-runtime",
		"session_id": "session-123",
		"job_id": "job-456"
	},
	"provenance": {
		"aiir_statement": "sha256:...",
		"transparency_entry": {
			"log": "rekor",
			"uuid": "...",
			"log_index": 123456
		}
	}
}

The Qiskit handle stays the auditor-facing key. The AIIR and transparency artifacts stay external, signed, and independently verifiable.

Illustrative flow

1. Build and attest

Generate an AIIR receipt for the source change or workload package. If needed, wrap it in a DSSE or in-toto Statement and sign it.

2. Log and submit

Record the signed statement in a transparency log, then submit the Runtime session or job and store the attestation digest plus log identifiers as metadata or side artifacts.

3. Verify offline

Retrieve the Runtime record, attestation, and log proof, then verify the bundle without requiring a private service from the receipt issuer.

Why this is useful

It keeps provenance tied to a canonical Runtime handle that auditors can query later.
It brings software-supply-chain practices into near-hardware orchestration without changing the surrounding execution API.
It gives research, enterprise, and regulated users a path to reproducibility and audit evidence using already-familiar primitives.

Suggested open-source boundary

The public-friendly release is the bridge layer, not a new AIIR core dependency:

A small adapter that maps an AIIR statement and transparency-log proof onto Qiskit Runtime job metadata or attached artifacts.
A verifier or example workflow that starts from a Runtime job identifier and reconstructs the offline verification bundle.
A public schema example for the binding data, kept outside AIIR core so the zero-dependency receipt kernel remains unchanged.

Boundaries

This note does not claim AIIR becomes a Qiskit Runtime standard or official IBM integration.
This note does not claim Qiskit Runtime itself must store signed statements natively.
This note does not claim undeclared AI use can be inferred from Runtime metadata.
This note does not claim build provenance, model provenance, and execution provenance collapse into one format.

Next public step

If this shape is useful, start with the public proof-chain demo: a static bundle plus guided verification walkthrough that proves one end-to-end example, verifies offline, and fails closed on tampering. The shipped demo uses a release handle rather than a Runtime handle, but preserves the same public proof shape.

See Proof-Chain Demo → See predicate example → See source attachment note → Back to ecosystem →