Verification, Tomography, and Shadow Protocols

Strong quantum claims require layered evidence rather than a single impressive run. The operator's job is to turn that thesis into a managed system: a contract, a workflow, a set of measurable controls, and a review loop. Current vendor and standards material is useful, but it should be treated as input to an operating model rather than a substitute for one [R126][R131].

Operating model

The operational pattern is consistent across this chapter: define the contract, validate early, execute under a bounded policy, capture evidence, and feed the result back into the platform.

Diagram loads as you read

Operating model · Figure 1

View diagram source

flowchart LR
    Intent[Intent] --> Contract[Contract]
    Contract --> Validate[Validate]
    Validate --> Execute[Execute]
    Execute --> Evidence[Evidence]
    Evidence --> Review[Review]
    Review --> Improve[Improve]
    Improve --> Contract

Core principles

The first principle is evidence grades. A quantum system becomes difficult to operate when this is informal. Make it explicit in manifests, API schemas, dashboards, and review gates.

The second principle is simulation where feasible. Hardware time, review time, and scientific attention are scarce. The platform should reject bad work early and explain how to fix it.

The third principle is targeted tomography. It should be represented as a first-class object rather than hidden in scripts or notebooks.

The remaining principles are randomized protocols, replication, and claim review. These are the mechanisms that make the system improvable rather than merely usable.

Diagram loads as you read

Core principles · Figure 2

View diagram source

mindmap
  root((Verification Tomography and Shadow Protocols))
    evidence grades
    simulation where feasible
    targeted tomography
    randomized protocols
    replication
    claim review

Lifecycle

A mature implementation should have lifecycle states. A draft object is cheap to change. A reviewed object can be used by a team. A production object can support decisions. A deprecated object remains visible but should not be used for new claims.

Diagram loads as you read

Lifecycle · Figure 3

View diagram source

stateDiagram-v2
    [*] --> Draft
    Draft --> Reviewed: technical review
    Reviewed --> Production: release gate
    Production --> Suspended: incident or policy failure
    Suspended --> Reviewed: fix validated
    Production --> Deprecated: replacement available
    Deprecated --> Retired
    Retired --> [*]

Failure modes

The major failure modes are overclaiming, post-hoc threshold choice, ignored negative runs, unbounded mitigation bias, single-backend dependence, and unclear confidence. Each has a different owner and a different corrective action. Avoid generic labels such as “quantum failed.” They erase the distinction between physics, software, policy, and interpretation.

Failure mode	Detection signal	Strong corrective action
overclaiming	Alert, failed preflight, or user report	Add automated check and owner dashboard
post-hoc threshold choice	The acceptance threshold was chosen after inspecting the evaluation results	Predeclare thresholds for confirmatory evaluation; label exploratory findings and test them on independent evidence
ignored negative runs	The reported cohort omits failed, null, or unfavorable runs without declared exclusions	Reconcile all attempted runs against the reported cohort and publish exclusions with reasons
unbounded mitigation bias	Reference cases or sensitivity checks show unexplained systematic error	Restrict or disable the mitigation method, validate its assumptions, and report residual bias separately from sampling uncertainty
single-backend dependence	Inconsistent result or claim review finding	Mark affected evidence provisional
unclear confidence	The estimate lacks a stated uncertainty method, assumptions, or treatment of bias	Report the estimator and uncertainty method, distinguish statistical variation from systematic bias, and limit the claim accordingly

Diagram loads as you read

Failure modes · Figure 4

View diagram source

flowchart TB
    Failure[Failure detected] --> Classify{Classify}
    Classify --> Physics[Physics or backend]
    Classify --> Software[Software or runtime]
    Classify --> Data[Data or evidence]
    Classify --> Policy[Policy or governance]
    Classify --> Claim[Claim or interpretation]
    Physics --> Action[Corrective action]
    Software --> Action
    Data --> Action
    Policy --> Action
    Claim --> Action

Control surface

The control surface should be smaller than the implementation. Users need stable inputs and predictable outputs. Operators need deeper controls. Reviewers need evidence. Executives need portfolio-level signals. Do not force all personas into the same interface.

Diagram loads as you read

Control surface · Figure 5

View diagram source

classDiagram
    class UserContract {
      purpose
      inputs
      limits
      outputs
    }
    class OperatorControls {
      policy
      routing
      quarantine
      rollback
    }
    class EvidenceBundle {
      provenance
      raw_data
      analysis
      reviewer_state
    }
    class DecisionView {
      cost
      risk
      maturity
      claim_status
    }
    UserContract --> EvidenceBundle
    OperatorControls --> EvidenceBundle
    EvidenceBundle --> DecisionView

Metrics

Metrics should separate system health from scientific value. A platform can be healthy while an experiment is inconclusive. A benchmark can improve while user experience degrades. Keep these dimensions separate.

Diagram loads as you read

Metrics · Figure 6

View diagram source

flowchart LR
    Metrics[Metrics] --> Health[System health]
    Metrics --> Quality[Scientific quality]
    Metrics --> Cost[Cost and capacity]
    Metrics --> UX[Developer experience]
    Metrics --> Governance[Governance]
    Health --> Dashboard[Review dashboard]
    Quality --> Dashboard
    Cost --> Dashboard
    UX --> Dashboard
    Governance --> Dashboard

Review cadence

The review cadence should match risk. Low-risk exploratory work can use automated checks. Production claims require human review. External claims require independent challenge. Regulated or high-stakes use requires audit-grade evidence.

Diagram loads as you read

Review cadence · Figure 7

View diagram source

flowchart TB
    Work[Work item] --> Risk{Risk class}
    Risk -- exploratory --> Auto[Automated checks]
    Risk -- internal decision --> Peer[Peer review]
    Risk -- external claim --> Board[Claim review board]
    Risk -- regulated --> Audit[Audit trail and approval]
    Auto --> Archive[Archive evidence]
    Peer --> Archive
    Board --> Archive
    Audit --> Archive

Operator checklist

Convert informal practice into a versioned contract.
Reject invalid work before it reaches scarce hardware.
Preserve enough evidence to explain results later.
Separate system-health metrics from scientific-quality metrics.
Assign owners to every failure class.
Review claims more strictly than exploratory runs.

Additional technical sources: [R263].