Execution evidence: hash-pinned bundles and result verification

Every settled Execution Plane job carries an Evidence Bundle: a deterministic, hash-pinned record of how, where and with which parameters the run was produced. It lets you verify later that the result belongs to the workload you submitted, that the workload was not silently altered, which backend ran it and what it cost.

Fetch a job’s evidence

curl -sS https://platform.softquantus.com/api/v1/platform/execution/jobs/{job_id}/evidence \
  -H "Authorization: Bearer $SQ_API_KEY"

Available once the job is settled — before that the endpoint returns 409 evidence_not_available_until_settled. Response shape

{
  "bundle": { "schema": "softquantus.evidence/v1", "...": "..." },
  "hash": "<sha256 of the bundle's canonical JSON>",
  "signature": "<HMAC integrity authenticator over (hash, key_version)>",
  "algo": "HS256-SHA256",
  "key_version": "v1",
  "checks": {
    "evidence_signature_valid": true,
    "workload_hash_valid": true,
    "result_hash_valid": true,
    "provider_metadata_present": true,
    "execution_complete": true,
    "key_version": "v1"
  }
}

The bundle is serialized as canonical JSON (sorted keys, no insignificant whitespace), hashed with SHA-256, and protected by an HMAC integrity authenticator computed with a dedicated evidence key (versioned via key_version so keys can rotate without invalidating old bundles).

What the bundle contains

Section	Fields
Identity	`schema` (`softquantus.evidence/v1`), `job_id`, `workspace_id`, `actor`
Where it ran	`provider`, `physical_target`, `region`, `execution_mode`, `provider_job_id`, `qcos_version`, `compiler_version`, `optimization_profile`
Resources & cost	`resources` (shots, usage units), `cost` (estimated, actual, currency), `timeline` (created, settled), `usage_metrics`
Hashes	`hashes.original_workload` (SHA-256 of the workload as submitted), `hashes.compiled_workload`, `hashes.result` (SHA-256 of the provider result)
Reproducibility	seeds, shots, backend, execution mode, optimization profile, library versions, input dataset hash, calibration snapshot — as available
Outcome	`status`

usage_metrics reports queue time, QPU seconds, execution span, wall-clock time, circuit executions and shots. Durations the provider did not measure are null — a missing measurement is never replaced with a fabricated value.

The checks are independent — do not collapse them

checks returns separate booleans on purpose:

Check	Proves
`evidence_signature_valid`	The bundle was not altered after it was recorded (integrity of the record)
`workload_hash_valid`	The submitted workload is pinned by hash (and matches a recomputed hash when supplied)
`result_hash_valid`	The recorded result hash matches the stored result’s freshly computed hash
`provider_metadata_present`	A real `provider_job_id` and physical target are recorded
`execution_complete`	The run reached a terminal completed/settled state

An intact record is not the same thing as a completed execution, and neither is the same thing as a reproduced result. Treat each facet on its own.

What `result_verified` means

The job object (GET /api/v1/platform/execution/jobs/{id}) carries a single convenience flag:

{ "status": "SETTLED", "result_verified": true }

result_verified is true only when all three hold:

the job’s status is SETTLED,
a result hash is recorded, and
an evidence hash is recorded.

A run that failed, was cancelled, or settled without a pinned result stays result_verified: false — an intact evidence record alone is not enough.

Relation to QCOS sealed evidence

Quantum runs executed by the QCOS runtime produce their own evidence artifact inside QCOS. That artifact is sealed — pinned by a Merkle tree of SHA-256 hashes — and is retrievable through the console proxy:

curl -sS https://platform.softquantus.com/api/v1/platform/qcos/jobs/{qcos_job_id}/execution-evidence \
  -H "Authorization: Bearer $SQ_API_KEY"

(404 when a workload has no evidence artifact.) The two layers are complementary:

The platform Evidence Bundle covers the commercial execution: who submitted what, on which target, what was reserved and settled, and the workload/result hashes.
The QCOS sealed bundle covers the quantum execution inside the runtime. It is sealed (Merkle SHA-256), which pins its contents; sealing is an integrity mechanism, not a cryptographic signature by QCOS.

For QCOS backend certification evidence (the QCOS Assurance page and the Quantum Trust Index), see QCOS Compatible.

Console

Run compute

API & clients

Trust & ecosystem

Execution evidence: hash-pinned bundles and result verification

Fetch a job’s evidence

What the bundle contains

The checks are independent — do not collapse them

What `result_verified` means

Relation to QCOS sealed evidence

​Fetch a job’s evidence

​What the bundle contains

​The checks are independent — do not collapse them

​What result_verified means

​Relation to QCOS sealed evidence

Fetch a job’s evidence

What the bundle contains

The checks are independent — do not collapse them

What `result_verified` means

Relation to QCOS sealed evidence