Calibration Trust Exchanges and Provider Scorecards

Quantum provider selection is a continuous trust decision. Headline qubit count is not enough. For operational work, the relevant question is narrower: can this target, at this time, under this calibration and runtime profile, support this workload and evidence level?

A calibration trust exchange normalizes the answer.

Diagram loads as you read

Calibration Trust Exchanges and Provider Scorecards · Figure 1

View diagram source

flowchart LR
    ProviderA[Provider A] --> Exchange[Trust exchange]
    ProviderB[Provider B] --> Exchange
    ProviderC[Provider C] --> Exchange
    Exchange --> Scorecard[Provider scorecard]
    Scorecard --> Router[Workload router]
    Scorecard --> Procurement[Procurement review]
    Scorecard --> Claims[Claim boundary]

Workload-specific trust

A provider can be trusted for one workload class and unsuitable for another.

Workload class	Trust signal
shallow circuits	current error, readout, queue behavior
VQE	repeatability across sessions and mitigation transparency
dynamic circuits	feedback support and latency semantics
confidential workloads	isolation, residency, audit records
analog simulation	parameter validation and device evidence
claim-grade benchmarking	evidence completeness and independent replay

Diagram loads as you read

Workload-specific trust · Figure 2

View diagram source

mindmap
  root((Provider trust))
    Physics
      calibration age
      drift trend
      crosstalk
    Runtime
      queue predictability
      reservations
      failure semantics
    Evidence
      metadata completeness
      provenance
      exportability
    Commercial
      support
      cost
      exit path

Canonical target health record

The exchange does not require every provider to expose identical internals. It requires enough common metadata to support routing and review.

Diagram loads as you read

Canonical target health record · Figure 3

View diagram source

classDiagram
    class TargetHealthRecord {
      provider
      target_id
      target_class
      calibration_epoch
      topology_profile
      native_operations
      health_metrics
      queue_metrics
      evidence_completeness
      support_status
    }
    class RawMetric {
      name
      value
      unit
      timestamp
      source
      confidence
    }
    TargetHealthRecord --> RawMetric

Scorecard construction

A scorecard separates facts from policy-weighted interpretation.

Component	Example
workload fit	supports required topology, gates, timing, or analog controls
reliability	availability, failed jobs, queue variance
evidence completeness	target snapshots, calibration metadata, runtime settings
economics	price predictability, reservation efficiency, cost per valid result
support	incident response, metadata export, contractual preservation

Diagram loads as you read

Scorecard construction · Figure 4

View diagram source

pie title Example score weighting
    "workload fit" : 30
    "evidence completeness" : 25
    "reliability" : 20
    "economics" : 15
    "support" : 10

Trust tiers

Diagram loads as you read

Trust tiers · Figure 5

View diagram source

stateDiagram-v2
    [*] --> Experimental
    Experimental --> Candidate: evidence improves
    Candidate --> ProductionLimited: drills pass
    ProductionLimited --> Production: sustained performance
    Production --> Restricted: incident, drift, or evidence failure
    Restricted --> Candidate: remediation verified

Tier	Meaning
experimental	exploration only
candidate	pilots with explicit review
production-limited	approved workloads with guardrails
production	approved workload class under normal policy
restricted	blocked or exception-only

Credentials and attestations

Scorecards can incorporate signed claims and evidence. W3C Verifiable Credentials define a model for issuer-backed claims, while CycloneDX attestations provide a structure for claims supported by evidence. Those mechanisms can express provider claims, benchmark certifications, training credentials, and evidence-review outcomes. [R176] [R178]

Diagram loads as you read

Credentials and attestations · Figure 6

View diagram source

flowchart TB
    Claim[Provider or reviewer claim] --> Credential[Signed credential]
    Credential --> Evidence[Supporting evidence]
    Evidence --> Scorecard[Scorecard update]
    Scorecard --> Policy[Routing policy]

Routing policy

The scorecard should inform routing, not replace governance.

Diagram loads as you read

Routing policy · Figure 7

View diagram source

flowchart LR
    Workload[Workload contract] --> Candidates[Candidate targets]
    Candidates --> Scorecards[Scorecards]
    Scorecards --> Policy[Routing policy]
    Policy --> Route{Route allowed?}
    Route -- yes --> Execute[Execute]
    Route -- no --> Exception[Exception or alternate target]

Operating rule

Route production work from current health, trust tier, evidence completeness, workload fit, cost envelope, and explicit policy. Do not route from vendor claims alone.