Assurance Cases for Quantum Results and Services

An assurance case is a structured argument that a claim is supported by evidence. Quantum platforms need assurance cases because results are probabilistic, hardware changes over time, and the same high-level workload can be transformed by many layers before execution.

This chapter adapts the assurance-case model described by the OMG Structured Assurance Case Metamodel [R165] to quantum results, services, and operations.

Diagram loads as you read

Assurance Cases for Quantum Results and Services · Figure 1

View diagram source

flowchart TB
    Claim[Claim] --> Argument[Argument]
    Argument --> Evidence1[Experiment evidence]
    Argument --> Evidence2[Operational evidence]
    Argument --> Evidence3[Review evidence]
    Evidence1 --> Confidence[Confidence statement]
    Evidence2 --> Confidence
    Evidence3 --> Confidence

Why claims need structure

Quantum claims often fail because the evidence is scattered: notebooks in one place, raw counts somewhere else, calibration snapshots elsewhere, and a slide deck making a stronger claim than the data supports. An assurance case makes the relationship between claim, argument, and evidence explicit.

Claim type	Example	Evidence needed
result claim	this estimator value is within bound	raw counts, confidence interval, mitigation details
service claim	this runtime target supports a workload class	target contract, canary suite, SLO history
safety claim	this lab procedure is controlled	hazard analysis, training, inspection records
security claim	sensitive workloads remain isolated	access logs, policy evaluation, data-flow proof
economic claim	quantum path improves portfolio value	baseline, cost model, decision impact

Diagram loads as you read

Why claims need structure · Figure 2

View diagram source

mindmap
  root((Quantum assurance case))
    Claim
      result
      service
      safety
      security
      economic
    Argument
      method
      assumptions
      bounds
    Evidence
      data
      telemetry
      review
      provenance

Claim, argument, evidence

The simplest useful pattern is claim-argument-evidence. The claim states what is being asserted. The argument explains why the evidence supports it. The evidence provides auditable artifacts.

Diagram loads as you read

Claim, argument, evidence · Figure 3

View diagram source

flowchart LR
    C[Claim: workload result is valid] --> A1[Argument: circuit was equivalent]
    C --> A2[Argument: target was within operating envelope]
    C --> A3[Argument: statistics support interval]
    A1 --> E1[Compiler equivalence record]
    A2 --> E2[Calibration and telemetry snapshot]
    A3 --> E3[Raw counts and analysis notebook]

Bounded claims

A quantum assurance case should avoid absolute language unless the system can support it. Claims should be bounded by target, time, method, confidence, and assumptions.

Diagram loads as you read

Bounded claims · Figure 4

View diagram source

flowchart TB
    Unbounded[Unbounded claim] --> BoundTarget[Bind target]
    BoundTarget --> BoundTime[Bind time window]
    BoundTime --> BoundMethod[Bind method]
    BoundMethod --> BoundStats[Bind statistical confidence]
    BoundStats --> BoundAssumptions[Declare assumptions]
    BoundAssumptions --> Bounded[Bounded claim]

Example:

Under target profile qpu-42.calibration-2026-04-19T12:00Z, compiler profile v7.3.1, mitigation profile zne-v2, and 64,000 shots, we report an expectation-value estimate and interval [a, b] for the stated Hamiltonian and ansatz. The interval procedure has the declared coverage under the stated sampling and mitigation assumptions; disclose any residual bias that the interval does not cover.

Confidence levels

Not every result needs the same assurance depth. The assurance depth should match the consequence of being wrong.

Level	Use	Required evidence
exploratory	internal learning	workload, raw result, basic provenance
engineering	design decision	reproducibility package, baseline, target metadata
production	customer-facing service	SLO history, canaries, review signoff
regulated	audit or legal consequence	assurance case, controls, retention, independent review
public claim	publication or marketing	claim review, limitations, reproducibility archive

Diagram loads as you read

Confidence levels · Figure 5

View diagram source

flowchart LR
    Exploratory --> Engineering
    Engineering --> Production
    Production --> Regulated
    Regulated --> PublicClaim[Public claim]

Assurance case repository

Assurance cases should live next to evidence packages. They should be versioned, reviewable, and searchable.

Diagram loads as you read

Assurance case repository · Figure 6

View diagram source

sequenceDiagram
    participant Author
    participant EvidenceStore
    participant AssuranceRepo
    participant Reviewer
    Author->>EvidenceStore: link artifacts
    Author->>AssuranceRepo: submit assurance case
    AssuranceRepo->>Reviewer: request review
    Reviewer->>EvidenceStore: inspect evidence
    Reviewer-->>AssuranceRepo: approve, condition, or reject

Failure modes

Assurance cases can fail in predictable ways.

Diagram loads as you read

Failure modes · Figure 7

View diagram source

flowchart TD
    Failure[Assurance failure] --> Missing[Missing evidence]
    Failure --> Overclaim[Claim exceeds evidence]
    Failure --> Stale[Stale target assumptions]
    Failure --> Circular[Circular argument]
    Failure --> Unreviewed[No independent review]

Failure	Control
evidence missing	block claim eligibility
overclaiming	require bounded-claim rewrite
stale assumptions	tie claim to target epoch
circular argument	require independent evidence source
reviewer rubber stamp	rotate reviewers and audit decisions

Operating rule

A result is not a claim until its argument and evidence are visible. A platform is not trustworthy until claims can be audited without reconstructing them from memory.

Additional technical sources: [R269].