Synthetic Load, Queue Simulation, and Capacity War Rooms

QPU capacity is scarce, time-dependent, and quality-dependent. A capacity plan that counts only jobs per day is incomplete because two jobs with the same shot count may consume very different value windows, calibration risk, queue time, and evidence burden.

Synthetic load testing creates controlled demand so the platform can see how the broker, scheduler, evidence pipeline, and provider connectors behave before a real deadline. Performance-testing tools such as k6 model traffic, thresholds, and test types for conventional APIs; quantum platforms need analogous load scripts for workload admission, result retrieval, evidence creation, and reservation use [R237].

flowchart LR
    LoadModel[Synthetic load model] --> Broker[Broker]
    Broker --> Scheduler[Scheduler]
    Scheduler --> Providers[Provider adapters]
    Providers --> Results[Results API]
    Results --> Evidence[Evidence pipeline]
    Evidence --> Metrics[Capacity metrics]

Load dimensions

Synthetic workload classes

flowchart TB
    Synthetic[Synthetic workloads] --> Smoke[Smoke]
    Synthetic --> Average[Average load]
    Synthetic --> Stress[Stress]
    Synthetic --> Spike[Spike]
    Synthetic --> Soak[Soak]
    Synthetic --> Breakpoint[Breakpoint]

A smoke test checks whether a minimal workload can pass through the system. Average-load tests model ordinary project traffic. Stress tests reveal degradation before collapse. Spike tests test conference-demo behavior and deadline bursts. Soak tests expose leaks in evidence writers, provider polling, or trace storage.

Queue simulation

A queue simulator should model quality windows, not merely FIFO arrival.

flowchart TB
    Arrivals[Workload arrivals] --> Admission[Admission policy]
    Admission --> Queue[Priority queues]
    Queue --> Quality[Backend quality model]
    Quality --> Reservation[Reservation windows]
    Reservation --> Execution[Execution slots]
    Execution --> Results[Latency and success distribution]

Example simulator inputs:

capacity_model:
  backends:
    - backend_id: qpu-a
      available_minutes_per_day: 720
      quality_windows:
        - start: "09:00"
          end: "13:00"
          expected_error_budget: high
        - start: "13:00"
          end: "18:00"
          expected_error_budget: medium
  arrivals:
    research: {jobs_per_hour: 12, priority: 3}
    regulated: {jobs_per_hour: 2, priority: 1}
    training: {jobs_per_hour: 25, priority: 5}

Capacity war room

When a deadline, customer milestone, or shared testbed window approaches, create a capacity war room with explicit decision authority.

flowchart LR
    Demand[Demand forecast] --> WarRoom[Capacity war room]
    Fleet[Fleet health] --> WarRoom
    Budget[Budget and reservations] --> WarRoom
    Claims[Claim deadlines] --> WarRoom
    WarRoom --> Throttle[Throttle low-value jobs]
    WarRoom --> Reserve[Reserve capacity]
    WarRoom --> Reroute[Reroute workloads]
    WarRoom --> Communicate[Communicate expectations]

Metrics

flowchart TB
    Metrics[Capacity metrics] --> Users[User experience]
    Metrics --> Cost[Cost efficiency]
    Metrics --> Science[Scientific quality]
    Metrics --> Governance[Governance compliance]

Operating rule

A quantum capacity plan is credible only if it models both access and trust. Getting time on a QPU is not enough if the result arrives outside the quality window needed for the claim.