Cross-Provider Trust Fabrics and Service Catalogs

Most serious quantum programs will use more than one provider, simulator, compiler, and evidence store. A cross-provider trust fabric makes those moving parts usable without turning every experiment into a bespoke integration project.

Diagram loads as you read

Cross-Provider Trust Fabrics and Service Catalogs · Figure 1

View diagram source

flowchart TB
    User[User] --> Catalog[Service catalog]
    Catalog --> Broker[Provider broker]
    Broker --> IBM[Provider A]
    Broker --> Ion[Provider B]
    Broker --> Sim[Simulator provider]
    Broker --> Internal[Internal lab system]
    Broker --> Evidence[Unified evidence fabric]

Service catalog entries

A catalog entry should describe a capability, not just a vendor endpoint.

Field	Purpose
service class	simulator, gate QPU, analog device, logical-qubit service, resource estimator
supported workloads	circuit classes, analog programs, optimization models, chemistry workflows
constraints	shots, depth, connectivity, queue policy, reservation requirements
trust level	provider attestation, benchmark evidence, audit status
governance tags	export, data residency, confidentiality, retention
cost model	unit cost, minimum charge, reservation cost, rerun cost
exit path	alternate targets, export format, replay path

Diagram loads as you read

Service catalog entries · Figure 2

View diagram source

flowchart LR
    Entry[Catalog entry] --> Capability[Capability]
    Entry --> Constraints[Constraints]
    Entry --> Trust[Trust level]
    Entry --> Governance[Governance tags]
    Entry --> Cost[Cost model]
    Entry --> Exit[Exit path]

Trust fabric

The trust fabric connects identity, policy, provider attestations, telemetry, and evidence.

Diagram loads as you read

Trust fabric · Figure 3

View diagram source

flowchart TB
    Identity[Identity] --> Policy[Policy engine]
    Provider[Provider attestations] --> Policy
    Benchmarks[Benchmark evidence] --> Policy
    Telemetry[Runtime telemetry] --> Evidence[Evidence fabric]
    Policy --> Broker[Broker decision]
    Broker --> Evidence

Trust should be dynamic. A provider can be approved for one workload class and blocked for another.

Routing by declared capability

Diagram loads as you read

Routing by declared capability · Figure 4

View diagram source

sequenceDiagram
    participant App as Application
    participant Catalog as Service Catalog
    participant Broker as Broker
    participant Provider as Provider
    participant Evidence as Evidence
    App->>Catalog: request service class
    Catalog-->>App: eligible services and constraints
    App->>Broker: submit workload contract
    Broker->>Catalog: resolve eligible targets
    Broker->>Provider: execute on selected target
    Provider-->>Broker: result and telemetry
    Broker->>Evidence: write normalized evidence

The broker should prefer explicit constraints over implicit vendor assumptions.

Catalog governance

Diagram loads as you read

Catalog governance · Figure 5

View diagram source

stateDiagram-v2
    [*] --> Proposed
    Proposed --> Evaluating
    Evaluating --> Approved
    Evaluating --> Rejected
    Approved --> Restricted
    Restricted --> Approved
    Approved --> Retired
    Rejected --> [*]
    Retired --> [*]

A provider or service class should not remain approved forever. Periodic review should check benchmark freshness, support incidents, pricing changes, regulatory changes, and exit-path viability.

Failure isolation

Diagram loads as you read

Failure isolation · Figure 6

View diagram source

flowchart LR
    ProviderFailure[Provider failure] --> Detect[Detect]
    Detect --> Classify[Classify affected workload classes]
    Classify --> Route[Route to alternate or pause]
    Route --> Notify[Notify users]
    Notify --> Evidence[Record evidence]
    Evidence --> Review[Post-incident review]

A catalog is also a resilience tool. If the service catalog includes alternates, constraints, and exit paths, the platform can degrade gracefully.

Chapter close

Cross-provider operations are not achieved by wrapping APIs. They require a trust fabric: cataloged capabilities, machine-readable constraints, policy-aware routing, normalized evidence, and explicit retirement paths.