Multi-Tenant Quantum Product Design — Operating Quantum Computers

A quantum platform becomes a product when users can consume it without understanding every operational detail, while operators still retain enough control to protect scarce hardware, scientific validity, security, and cost.

Multi-tenant quantum product design is the discipline of exposing useful abstractions without hiding the constraints that determine result quality.

56.1 Product surface

Diagram loads as you read

56.1 Product surface · Figure 1

View diagram source

flowchart TB
    User[User or application] --> API[Product API]
    API --> Catalog[Workload catalog]
    API --> Runtime[Runtime contract service]
    API --> Evidence[Evidence package service]
    API --> Cost[Cost estimator]
    API --> Support[Support and incident workflow]

The product is not just the ability to submit circuits. It is the ability to plan, execute, understand, reproduce, and govern quantum work.

56.2 Tenant isolation

Quantum systems require several isolation layers.

Diagram loads as you read

56.2 Tenant isolation · Figure 2

View diagram source

flowchart LR
    TenantA[Tenant A] --> IAM[IAM and policy]
    TenantB[Tenant B] --> IAM
    IAM --> Quota[Quota and budget]
    Quota --> Scheduler[Fair scheduler]
    Scheduler --> QPU[Shared QPU]
    Scheduler --> Artifact[Isolated artifacts]
    Scheduler --> Logs[Redacted logs]

Isolation means more than access control. It includes quotas, artifact separation, result privacy, job-tag hygiene, and protection from noisy-neighbor scheduling effects.

56.3 Product tiers

Tier	Target user	Exposed abstraction	Operator burden
raw execution	expert researchers	circuits, shots, backend	high support burden
governed runtime	platform teams	runtime contracts	moderate
domain function	application teams	chemistry/optimization functions	lower
decision service	business workflow	decision and uncertainty	highest governance burden

Diagram loads as you read

56.3 Product tiers · Figure 3

View diagram source

flowchart TB
    Raw[Raw execution] --> Runtime[Governed runtime]
    Runtime --> Function[Domain function]
    Function --> Decision[Decision service]
    Raw -. more flexibility .-> Expert[Expert users]
    Decision -. less implementation detail .-> Business[Business users]

IBM Qiskit Functions and primitive APIs illustrate the move from low-level circuit execution toward more packaged utility-scale workflows. [R70] [R98]

56.4 API contract

A product API should return structured uncertainty and refusal reasons.

Illustrative listing · json

{
  "request_id": "qsvc-2026-04-19-0001",
  "status": "completed",
  "result": {
    "estimate": -1.1372,
    "standard_error": 0.0041,
    "confidence_interval": [-1.145, -1.129]
  },
  "evidence_package_id": "evidence-abc123",
  "runtime_contract_id": "runtime-def456",
  "warnings": [
    "mitigation_overhead_multiplier=6.4",
    "target_calibration_age_minutes=42"
  ]
}

For rejected work:

Illustrative listing · json

{
  "request_id": "qsvc-2026-04-19-0002",
  "status": "rejected",
  "reason_codes": [
    "TARGET_FEATURE_UNSUPPORTED",
    "EXPECTED_ERROR_BUDGET_EXCEEDED"
  ],
  "suggested_actions": [
    "reduce circuit depth",
    "allow alternate backend",
    "run simulator preflight"
  ]
}

56.5 Tenant-facing workflow

Diagram loads as you read

56.5 Tenant-facing workflow · Figure 4

View diagram source

sequenceDiagram
    participant U as Tenant user
    participant P as Product API
    participant Q as Quota service
    participant R as Runtime
    participant S as Scheduler
    participant E as Evidence store

    U->>P: Submit workload request
    P->>Q: Check budget/quota
    Q-->>P: Approved or denied
    P->>R: Build runtime contract
    R->>S: Request execution slot
    S-->>R: Slot assigned
    R->>E: Register evidence package
    R-->>P: Result + evidence ID
    P-->>U: Response with uncertainty

56.6 Product telemetry

OpenTelemetry-style semantic conventions are useful because product teams need common dimensions across traces, metrics, logs, and resources. Quantum products should standardize fields such as tenant, workload family, backend, target snapshot, circuit hash, mitigation policy, and evidence package ID. [R102]

Diagram loads as you read

56.6 Product telemetry · Figure 5

View diagram source

flowchart LR
    Request[Request trace] --> Tenant[tenant.id]
    Request --> Workload[quantum.workload.family]
    Request --> Backend[quantum.backend.name]
    Request --> Target[quantum.target.snapshot]
    Request --> Mitigation[quantum.mitigation.policy]
    Request --> Evidence[quantum.evidence.id]

56.7 Pricing models

Diagram loads as you read

56.7 Pricing models · Figure 6

View diagram source

flowchart TB
    Pricing[Pricing model] --> Shots[Per shot/task]
    Pricing --> Window[Reserved window]
    Pricing --> Result[Per validated result]
    Pricing --> Tier[Subscription tier]
    Pricing --> Internal[Internal chargeback]

Per-shot pricing is easy to meter but can reward inefficient workflows. Per-result pricing is more user-aligned but requires stronger evidence and acceptance definitions.

56.8 Support model

Quantum product support needs reason-code routing.

Diagram loads as you read

56.8 Support model · Figure 7

View diagram source

flowchart TD
    Ticket[Support ticket] --> Type{Reason code}
    Type --> Compile[Compilation issue]
    Type --> Target[Target availability]
    Type --> Quality[Result quality]
    Type --> Billing[Quota or billing]
    Type --> Evidence[Evidence retrieval]
    Compile --> CompilerTeam[Compiler team]
    Target --> OpsTeam[Ops team]
    Quality --> ScienceReview[Scientific review]
    Billing --> PlatformOps[Platform ops]
    Evidence --> DataTeam[Data team]

Do not route every failed quantum job to the same support queue.

56.9 Product principle

A good quantum product reduces accidental complexity while preserving essential uncertainty.

Diagram loads as you read

56.9 Product principle · Figure 8

View diagram source

flowchart LR
    Complexity[Accidental complexity] --> Hide[Hide behind product]
    Uncertainty[Essential uncertainty] --> Expose[Expose explicitly]
    Hide --> Useful[Useful abstraction]
    Expose --> Trust[User trust]
    Useful --> Product[Quantum product]
    Trust --> Product

A product that hides uncertainty will create bad decisions. A product that exposes every detail will not scale beyond experts. The engineering problem is finding the boundary.