Quantum Evidence Packages and Result Governance

A quantum result is not just a number. It is a claim backed by a chain of artifacts: problem formulation, encoding, source code, compiler output, target selection, calibration context, execution metadata, measurement samples, post-processing, statistical analysis, and reviewer decisions.

The product of a serious quantum platform is not merely execution. It is evidence.

48.1 Evidence package model

Diagram loads as you read

48.1 Evidence package model · Figure 1

View diagram source

flowchart TB
    Claim[Claim or answer] --> Analysis[Statistical analysis]
    Analysis --> Samples[Measurement samples]
    Samples --> Execution[Execution record]
    Execution --> Target[Target and calibration context]
    Execution --> Runtime[Runtime and container image]
    Execution --> Compile[Compiled circuit or instruction stream]
    Compile --> Source[Source and configuration]
    Source --> Intent[Problem statement]

Every externally meaningful result should be reconstructible from its evidence package, even if exact physical replay is impossible.

48.2 Evidence schema

Illustrative listing · yaml

quantum_evidence_package:
  package_id: string
  claim:
    statement: string
    scope: string
    limitations: [string]
  workload:
    source_repository: string
    commit: string
    configuration_hash: string
    problem_instance_hash: string
  compilation:
    compiler: string
    version: string
    target_model_hash: string
  execution:
    provider: string
    target: string
    job_id: string
    tags: [string]
    queue_mode: on_demand | reservation | session
    submitted_at: datetime
    completed_at: datetime
  calibration_context:
    calibration_id: string
    timestamp: datetime
    health_summary: string
  statistics:
    shots: integer
    estimator: string
    confidence_interval: string
  review:
    reviewers: [string]
    decision: accepted | rejected | qualified

IBM job tags and runtime job metadata are useful primitives for organizing execution records, but result governance requires a larger envelope that includes intent, compilation, statistics, and review. [R75]

48.3 Chain of custody

Diagram loads as you read

48.3 Chain of custody · Figure 2

View diagram source

sequenceDiagram
    participant Author as Experiment author
    participant Platform as Platform
    participant QPU as QPU or simulator
    participant Store as Evidence store
    participant Reviewer as Reviewer
    Author->>Platform: submit workload with intent
    Platform->>Store: persist source and config hashes
    Platform->>QPU: execute job
    QPU-->>Platform: samples and metadata
    Platform->>Store: persist raw and derived artifacts
    Reviewer->>Store: inspect evidence package
    Reviewer-->>Author: accept, reject, or qualify claim

The chain of custody should be tamper-evident enough for internal governance and customer trust. For regulated environments, integrate with existing security and audit controls.

48.4 Result classes

Not all results deserve the same treatment.

Result class	Governance level
exploratory	lightweight provenance and internal notes
benchmark	formal artifact retention and repeatability gates
customer-facing	review, limitations, and sign-off
scientific publication	full reproducibility package and claim review
product decision	statistical review and business owner approval
compliance claim	legal/compliance review and evidence retention

Diagram loads as you read

48.4 Result classes · Figure 3

View diagram source

flowchart LR
    Result[Result] --> Classify[Classify result]
    Classify --> Exploratory[Exploratory]
    Classify --> Benchmark[Benchmark]
    Classify --> Customer[Customer-facing]
    Classify --> Publication[Publication]
    Classify --> Compliance[Compliance]
    Benchmark --> Retention[Retention and review]
    Customer --> Retention
    Publication --> Retention
    Compliance --> Retention

48.5 Statistical governance

A result without uncertainty is not evidence. It is a point estimate.

Diagram loads as you read

48.5 Statistical governance · Figure 4

View diagram source

flowchart TB
    Samples[Samples] --> Estimate[Estimate quantity]
    Estimate --> Interval[Confidence or credible interval]
    Interval --> Sensitivity[Sensitivity analysis]
    Sensitivity --> Baseline[Compare to classical baseline]
    Baseline --> Claim{Claim supported?}
    Claim -- no --> Qualify[Qualify or reject]
    Claim -- yes --> Publish[Publish with limitations]

The platform should require:

sample counts,
estimator definition,
interval method,
mitigation method if used,
baseline comparison,
sensitivity to calibration and compiler choices,
failure cases and null results.

48.6 Evidence storage architecture

Diagram loads as you read

48.6 Evidence storage architecture · Figure 5

View diagram source

flowchart TB
    Submit[Submission service] --> Metadata[Metadata database]
    Submit --> Object[Object store]
    Runtime[Runtime service] --> Metadata
    Runtime --> Object
    Analysis[Analysis pipeline] --> Metadata
    Analysis --> Object
    Dashboard[Review dashboard] --> Metadata
    Dashboard --> Object
    Audit[Audit export] --> Metadata

OpenTelemetry semantic conventions are useful for consistent traces and metrics, while NIST CSF 2.0 gives a general risk-governance vocabulary for security programs. A quantum evidence store should interoperate with those broader observability and governance systems rather than remain a bespoke research database. [R73] [R89]

48.7 Review workflow

Diagram loads as you read

48.7 Review workflow · Figure 6

View diagram source

stateDiagram-v2
    [*] --> Draft
    Draft --> Submitted
    Submitted --> TechnicalReview
    TechnicalReview --> StatisticalReview
    StatisticalReview --> ClaimsReview
    ClaimsReview --> Accepted
    ClaimsReview --> Qualified
    ClaimsReview --> Rejected
    Qualified --> PublishedWithLimitations
    Accepted --> Published
    Rejected --> Archived

Reviewers should reject claims for missing baseline, missing uncertainty, missing provenance, stale calibration context, unsupported extrapolation, or mismatch between wording and evidence.

48.8 Operating rule

Do not ask, “What did the quantum computer output?” Ask, “What claim can this evidence package support?” The second question is slower. It is also the question that survives contact with customers, auditors, reviewers, and future you.