What should a hosted quantum computing service agreement cover?

A hosted quantum computing service agreement should define access, the conditions under which results are usable and responsibility for restoring operation after a failure. Availability of an application programming interface (API), availability of a processor and acceptance of a workload are different measures. Service commitments should cover the operations on which the customer depends.

Defining availability and calibration

Describe the purchased service before discussing a percentage. The buyer may receive shared processor access, a reserved window, a dedicated system or a hybrid workflow combining classical and quantum resources. Name the relevant device or substitution rules, supported software and permitted workloads. A service can satisfy a narrow access promise while failing the purpose for which it was purchased. The agreement should make that distinction visible before payment and operational dependence grow.

Availability needs a defined numerator, denominator and measurement point. Does a successful login count if no processor can accept the job? Does scheduled maintenance reduce the promised access period or fall outside it? How are provider outages, failed submissions and customer errors classified? A hypothetical 99% availability promise over a defined 100-hour service window permits one hour of unavailability under that definition. It says nothing about queue time or output quality unless those are separately included.

Calibration is part of the service boundary. The LRZ integration study published in 2025 found that recalibration needed to be automated and controllable through the HPC scheduler for its superconducting installation. A commercial buyer should establish how calibration affects reserved time, which status information is available and what happens if performance drifts during a job. The contract should not imply that every physically completed execution meets a scientific acceptance threshold. That threshold depends on the agreed workload and the measurement method.

Scheduling, support and data responsibilities

Access commitments should distinguish submission, scheduling and completion. Shared queues may suit exploratory work while leaving time-sensitive hybrid experiments exposed to delays. Ask whether a reservation guarantees exclusive use, priority or only an opportunity to run within stated constraints. Determine how cancellation, failed jobs and unused time are billed. Amazon Braket’s pricing documentation illustrates that reserved access and on-demand hybrid execution can have different charging boundaries. Those published models should not be converted into a universal quantum service standard.

Support requires a route from notification to recovery. Define the contact point, coverage hours, severity categories and responsibility for dependencies outside the provider’s immediate platform. A prompt initial response is different from restoring a useful environment. Establish access to logs, configuration records and technical staff when an incident crosses hardware, compiler and application layers. A credits-only remedy may reduce the bill while leaving the buyer’s research programme delayed; assess that consequence against the service’s importance.

Data obligations should follow the actual processing route. AWS’s security documentation for Braket allocates responsibilities between the provider and customer rather than presenting security as entirely outsourced. For the proposed service, establish where workload data, results and logs are retained, who can access them and what happens when support staff intervene. Address retention and deletion, identity controls, incident notification and permitted secondary use. A jurisdictional claim must cover the relevant subcontractors and operations, not only the address on the invoice.

Service changes, exit and performance records

Change management and exit matter because quantum systems and software can evolve quickly. Specify notice for device retirement, material interface changes and unsupported versions. Determine whether a replacement processor is acceptable for the customer’s workload or requires validation. Preserve sufficient configuration and result records to reproduce prior work or explain why it cannot be reproduced after a change. Exporting source code is helpful, but may not preserve a provider-specific calibration state or operating environment.

Finally, attach reporting to the commitments. The buyer needs a record of access, interruptions, failed jobs, maintenance and resolution that matches the contract’s definitions. Review that record against the workload’s actual needs before renewal or expansion. A service agreement cannot guarantee scientific success, but it can make operational responsibilities and remedies concrete. The strongest protection is a contract whose measurements can distinguish a provider failure, an application limitation and an unresolved research result without prolonged argument.