Interoperability, Intermediate Representations, and Portability

Quantum teams rarely live in one stack. They prototype in notebooks, use multiple SDKs, compare simulators, submit to cloud providers, run resource estimators, and eventually bind application code to workflow systems. Interoperability is therefore not a convenience feature. It is a governance and reproducibility requirement.

Portability does not mean the same program runs equally well everywhere. It means the platform can preserve workload intent, constraints, provenance, and evidence as the program crosses tools.

23.1 The interoperability problem

Diagram loads as you read

23.1 The interoperability problem · Figure 1

View diagram source

flowchart TB
    Researcher[Research notebook] --> SDK1[SDK A]
    Researcher --> SDK2[SDK B]
    SDK1 --> IR[Intermediate representation]
    SDK2 --> IR
    IR --> Sim[Simulator]
    IR --> Cloud[Cloud runtime]
    IR --> Resource[Resource estimator]
    IR --> Archive[Experiment archive]
    Cloud --> Results[Results]
    Sim --> Results
    Results --> Report[Trust report]

The core problem is not file conversion. It is semantic preservation.

Questions the platform must answer:

did the observable mean the same thing after conversion,
were qubit order and classical register order preserved,
were timing and dynamic behavior preserved,
were approximations introduced,
did the target support the required operations,
can the result be reproduced with the same artifacts later?

23.2 IR layers

Different intermediate representations operate at different levels. QIR is an LLVM-based, hardware-agnostic interface between quantum programming languages/frameworks and target platforms [R37]. OpenQASM 3 is an assembly-style language designed for near-term algorithms with timing, classical control, and circuit-level expression [R26, R27]. CUDA-Q is positioned as a hybrid programming platform for CPUs, GPUs, and QPUs [R46].

Diagram loads as you read

23.2 IR layers · Figure 2

View diagram source

flowchart TB
    App[Application model] --> Algorithm[Algorithm IR]
    Algorithm --> Circuit[Circuit IR]
    Circuit --> Target[Target-aware IR]
    Target --> Control[Control IR]
    Control --> Hardware[Hardware commands]

    QIR[QIR-like layer] -.-> Algorithm
    OpenQASM[OpenQASM-like layer] -.-> Circuit
    ControlIR[Vendor control layer] -.-> Control

A mature platform may use several IRs at once. The mistake is to pretend one representation solves every layer.

23.3 Portability contracts

A portability contract states what is guaranteed to survive a tool transition.

Illustrative listing · yaml

portability_contract:
  source_format: openqasm3
  destination_format: qir
  preserves:
    - unitary_semantics_for_supported_gates
    - measurement_register_mapping
    - parameter_names
  may_change:
    - gate_decomposition
    - qubit_layout
    - scheduling
  unsupported:
    - pulse_calibrations
    - target_specific_pragmas
  validation_required:
    - simulator_equivalence
    - observable_consistency

Diagram loads as you read

23.3 Portability contracts · Figure 3

View diagram source

flowchart LR
    Source[Source artifact] --> Convert[Converter]
    Convert --> Contract[Portability contract]
    Contract --> Validate[Validation suite]
    Validate --> Dest[Destination artifact]
    Validate --> Report[Conversion report]

Every conversion should produce a conversion report. Silent conversion is an operational hazard.

23.4 Semantic checks

Diagram loads as you read

23.4 Semantic checks · Figure 4

View diagram source

flowchart TB
    Converted[Converted program] --> Registers[Register mapping check]
    Converted --> Params[Parameter binding check]
    Converted --> Obs[Observable check]
    Converted --> Control[Control-flow check]
    Converted --> Timing[Timing check]
    Converted --> Target[Target support check]
    Registers --> Decision{Valid?}
    Params --> Decision
    Obs --> Decision
    Control --> Decision
    Timing --> Decision
    Target --> Decision

Minimum checks:

Check	Failure mode
register mapping	bitstrings interpreted backward or under wrong labels
parameter binding	optimizer updates wrong angles
observable mapping	expectation values reported for wrong operator
control-flow support	dynamic behavior flattened incorrectly
timing support	delays or alignment constraints lost
target support	unsupported operations accepted too late

23.5 Multi-provider execution gateway

A multi-provider platform should hide account complexity, not hardware truth.

Diagram loads as you read

23.5 Multi-provider execution gateway · Figure 5

View diagram source

flowchart TB
    Client[Client] --> Gateway[Quantum execution gateway]
    Gateway --> Policy[Policy and quota]
    Gateway --> Normalize[Normalize workload intent]
    Normalize --> Capabilities[Provider capability registry]
    Capabilities --> Route{Route or reject}
    Route --> IBM[Provider adapter A]
    Route --> AWS[Provider adapter B]
    Route --> Azure[Provider adapter C]
    Route --> Local[Local simulator]
    IBM --> Evidence[Normalized evidence bundle]
    AWS --> Evidence
    Azure --> Evidence
    Local --> Evidence

The gateway should expose:

workload intent,
target capability matching,
provider-specific constraints,
normalized status and failure semantics,
normalized artifact bundles,
provider-specific raw payloads for audit.

It should not pretend providers are identical. That creates false portability.

23.6 Hybrid interoperability

Hybrid quantum-classical workloads are harder to move than single circuits. They include classical optimizer state, container images, simulator baselines, data dependencies, and iterative scheduling behavior. Amazon Braket Hybrid Jobs and Qiskit Runtime sessions are examples of provider-level execution patterns for hybrid workflows [R20, R35].

Diagram loads as you read

23.6 Hybrid interoperability · Figure 6

View diagram source

sequenceDiagram
    participant App as Hybrid app
    participant Gateway as Execution gateway
    participant Runtime as Provider runtime
    participant QPU as QPU
    participant Store as Artifact store
    App->>Gateway: submit workflow bundle
    Gateway->>Gateway: validate policy and artifacts
    Gateway->>Runtime: create managed execution
    loop optimization iterations
        Runtime->>QPU: submit quantum task
        QPU-->>Runtime: samples / estimates
        Runtime->>Runtime: update classical state
    end
    Runtime-->>Store: outputs and logs
    Store-->>App: trust report

The portable unit is not a circuit. It is a workflow bundle.

23.7 Artifact bundle for portability

Illustrative listing · yaml

portable_experiment_bundle:
  intent:
    problem_class: chemistry|optimization|simulation|benchmark|other
    success_metric: string
  program:
    source_files:
      - path: src/main.qs
        sha256: string
    ir_artifacts:
      - format: qir
        sha256: string
      - format: openqasm3
        sha256: string
  dependencies:
    container_image: string
    sdk_versions: {}
  target_requirements:
    min_qubits: int
    required_features:
      - mid_circuit_measurement
  validation:
    simulator_baseline: string
    conversion_report: string
  execution:
    provider: string
    backend: string
    run_id: string

Diagram loads as you read

23.7 Artifact bundle for portability · Figure 7

View diagram source

flowchart LR
    Bundle[Portable bundle] --> Validate[Validate]
    Validate --> Adapt[Provider adaptation]
    Adapt --> Execute[Execute]
    Execute --> Normalize[Normalize results]
    Normalize --> Archive[Archive]

23.8 Portability maturity model

Level	Behavior
0	ad hoc notebook copies
1	source code stored, but execution metadata incomplete
2	source, dependency, and result artifacts captured
3	IR conversions produce validation reports
4	workload intent can be routed across providers with explicit capability checks
5	resource estimation, simulation, and QPU execution share a governed artifact model

Diagram loads as you read

23.8 Portability maturity model · Figure 8

View diagram source

flowchart LR
    L0[Ad hoc] --> L1[Source controlled]
    L1 --> L2[Artifacts captured]
    L2 --> L3[Validated conversions]
    L3 --> L4[Capability-routed]
    L4 --> L5[Governed portable workflows]

23.9 Chapter rule

Do not sell portability as “run anywhere.” In quantum systems, that phrase is usually false. Sell portability as preserved intent, explicit constraints, validated conversion, and comparable evidence.

References used in this chapter: [R20], [R26], [R27], [R35], [R37], [R46].