Reservation, Quota, and Entitlement Governance

Quantum capacity is not fungible. A minute on one backend during a reservation is not equivalent to a minute on another backend in a public queue. AWS Braket reservations, for example, provide dedicated device access for a fixed duration and can remove queue competition during that reserved window [R247]. Azure Quantum quotas are provider-defined limits intended to prevent accidental cost overages and preserve provider-system integrity [R248]. These are operating constraints, not billing details.

Diagram loads as you read

Reservation, Quota, and Entitlement Governance · Figure 1

View diagram source

flowchart LR
    Demand[Workload demand] --> Entitlement[Entitlement check]
    Entitlement --> Quota[Quota check]
    Quota --> Capacity[Capacity plan]
    Capacity --> Reservation{Reservation needed?}
    Reservation -- yes --> Reserve[Reserve device window]
    Reservation -- no --> Queue[On-demand queue]
    Reserve --> Execute[Execute]
    Queue --> Execute

Capacity objects

Object	Meaning
entitlement	which provider, backend, queue, mode, and data class a workload may use
quota	how much usage the project may consume in a renewal period
reservation	exclusive or dedicated access window
budget	spending boundary or allocation rule
priority	relative scheduling preference under contention
holdback	reserved emergency or calibration capacity

Diagram loads as you read

Capacity objects · Figure 2

View diagram source

classDiagram
    class Entitlement {
      principal
      provider
      backend
      modes
      data_classes
    }
    class Quota {
      period
      limit
      consumed
      reset_policy
    }
    class Reservation {
      provider
      backend
      start
      end
      owner
    }
    class Budget {
      cost_center
      limit
      alert_thresholds
    }
    Entitlement --> Quota
    Quota --> Budget
    Reservation --> Entitlement

Admission decision

Admission control should explain why a workload is accepted or denied.

Diagram loads as you read

Admission decision · Figure 3

View diagram source

flowchart TB
    Request[Execution request] --> Identity[Identity valid?]
    Identity -- no --> DenyIdentity[Deny: identity]
    Identity -- yes --> Entitled[Entitled target?]
    Entitled -- no --> DenyEntitlement[Deny: entitlement]
    Entitled -- yes --> QuotaOK[Quota available?]
    QuotaOK -- no --> DenyQuota[Deny: quota]
    QuotaOK -- yes --> Window[Capacity window available?]
    Window -- no --> QueueOrReject[Queue or reject]
    Window -- yes --> Admit[Admit with evidence]

Reservation economics

A reservation changes the objective. In on-demand mode, the platform optimizes for minimizing unnecessary shots and avoiding queue delays. In reserved mode, the platform also optimizes for filling the reserved window with useful work because cost is tied to the duration of the reservation [R247].

Diagram loads as you read

Reservation economics · Figure 4

View diagram source

quadrantChart
    title Workload fit for reserved access
    x-axis Low setup readiness --> High setup readiness
    y-axis Low capacity value --> High capacity value
    quadrant-1 Reserve candidate
    quadrant-2 Prepare first
    quadrant-3 Do not reserve
    quadrant-4 Batch on demand
    Variational sweep: [0.8, 0.9]
    One-off demo: [0.4, 0.2]
    Calibration campaign: [0.7, 0.8]
    Exploratory notebook: [0.2, 0.3]

Provider quota abstraction

Do not flatten provider quota units into one generic “credits” number. Preserve native units and normalize only for reporting.

Diagram loads as you read

Provider quota abstraction · Figure 5

View diagram source

flowchart LR
    IBM[IBM usage allocation seconds] --> BrokerQuota[Broker quota ledger]
    Azure[Azure provider quota units] --> BrokerQuota
    AWS[AWS task, shot, and reservation costs] --> BrokerQuota
    BrokerQuota --> Report[Normalized report]
    BrokerQuota --> Guard[Native enforcement]

Governance loop

Diagram loads as you read

Governance loop · Figure 6

View diagram source

sequenceDiagram
    participant Team as Workload team
    participant Broker as Broker
    participant FinOps as FinOps
    participant Provider as Provider
    participant Exec as Executive review
    Team->>Broker: Request capacity
    Broker->>FinOps: Forecast quota and cost
    FinOps->>Provider: Check reservation or quota options
    Provider-->>FinOps: Availability and limits
    FinOps->>Exec: Approval when threshold exceeded
    Exec-->>Broker: Approve, reject, or resize

Operating rule

Quantum capacity governance should be explicit at the moment of admission. A platform that lets users discover quota exhaustion, access denial, or reservation waste after submission is not operating; it is relaying surprises.