Interoperability Labs and Conformance Testing — Operating Quantum Computers

Portability is not a claim. It is a test result. A quantum platform that says it supports multiple providers, languages, runtimes, and evidence formats needs an interoperability lab: a controlled environment where contracts are tested against real adapters, simulated failures, and version drift.

Diagram loads as you read

Interoperability Labs and Conformance Testing · Figure 1

View diagram source

flowchart TB
    Lab[Interoperability lab] --> API[API conformance]
    Lab --> Event[Event conformance]
    Lab --> Artifact[Artifact conformance]
    Lab --> Runtime[Runtime behavior]
    Lab --> Evidence[Evidence completeness]
    Lab --> Exit[Provider exit drill]

What interoperability means

Quantum interoperability has layers.

Layer	Test question
API	Can clients submit, inspect, and cancel work consistently?
event	Do state transitions have common meaning?
artifact	Can circuits, results, and evidence be exchanged?
runtime	Are execution semantics understood?
policy	Are entitlements and guardrails portable?
evidence	Can claims be reviewed across providers?

Diagram loads as you read

What interoperability means · Figure 2

View diagram source

flowchart LR
    Client[Client] --> API[API layer]
    API --> Runtime[Runtime layer]
    Runtime --> Artifact[Artifact layer]
    Artifact --> Evidence[Evidence layer]
    Evidence --> Review[Review layer]

API compatibility is the easiest layer. Evidence compatibility is harder and more valuable.

Conformance suite

A conformance suite is a set of machine-run tests plus human-review checks.

Diagram loads as you read

Conformance suite · Figure 3

View diagram source

flowchart TB
    Suite[Conformance suite] --> Positive[Positive tests]
    Suite --> Negative[Negative tests]
    Suite --> Drift[Version drift tests]
    Suite --> Failure[Failure injection]
    Suite --> Evidence[Evidence review]
    Suite --> Scorecard[Scorecard]

Positive tests check expected behavior for the exercised cases. Negative tests check guardrails against specified invalid inputs. Drift tests detect covered regressions. Passing a finite conformance suite provides evidence, not a general proof that every behavior, guardrail, or upgrade is correct.

Test harness

Diagram loads as you read

Test harness · Figure 4

View diagram source

sequenceDiagram
    participant Harness
    participant Adapter
    participant Provider
    participant Evidence
    Harness->>Adapter: submit canonical workload
    Adapter->>Provider: provider-specific request
    Provider-->>Adapter: result or failure
    Adapter-->>Harness: canonical response
    Harness->>Evidence: inspect artifact completeness
    Harness-->>Harness: score conformance

The harness should produce artifacts, not just pass/fail output. Conformance results are evidence.

Contract-driven testing

OpenAPI, AsyncAPI, and CloudEvents can provide generic contract scaffolding for APIs and events [R202][R203][R204]. Quantum-specific conformance must add semantics: target capability meaning, measurement output meaning, mitigation provenance, and calibration context.

Diagram loads as you read

Contract-driven testing · Figure 5

View diagram source

flowchart TB
    Generic[Generic contract tests] --> Syntax[Syntax and field validation]
    Generic --> State[State-transition shape]
    Quantum[Quantum semantic tests] --> Target[Target capability semantics]
    Quantum --> Result[Result distribution semantics]
    Quantum --> Calibration[Calibration context]
    Quantum --> Mitigation[Mitigation provenance]
    Syntax --> Report[Conformance report]
    State --> Report
    Target --> Report
    Result --> Report
    Calibration --> Report
    Mitigation --> Report

Interoperability scorecard

A useful scorecard records capability, evidence quality, version, and exclusions.

Diagram loads as you read

Interoperability scorecard · Figure 6

View diagram source

flowchart LR
    Score[Scorecard] --> Coverage[Coverage]
    Score --> Failures[Failures]
    Score --> Waivers[Waivers]
    Score --> Versions[Versions]
    Score --> Evidence[Evidence links]
    Score --> Expiry[Expiry]

A score without exclusions is not credible. Every provider, adapter, and runtime has limits.

Exit drills

The most important interoperability test is the exit drill: can a workload move to another target, another provider, or a simulator without losing evidence continuity?

Diagram loads as you read

Exit drills · Figure 7

View diagram source

stateDiagram-v2
    [*] --> SelectWorkload
    SelectWorkload --> ExportArtifacts
    ExportArtifacts --> MapTarget
    MapTarget --> RunEquivalent
    RunEquivalent --> CompareEvidence
    CompareEvidence --> Pass
    CompareEvidence --> Fail
    Pass --> Record
    Fail --> Remediate
    Record --> [*]
    Remediate --> SelectWorkload

Exit drills convert portability from vendor-management language into an operational fact.

Practical rule

Do not say the platform is multi-provider because the code has multiple SDK imports. Say it only when a conformance suite and exit drill show that workloads, evidence, and decisions survive provider movement.

Additional technical sources: [R179].