What is Boulder Opal?

Boulder Opal is Q-CTRL's orchestration layer for autonomous quantum hardware characterization and calibration. It provides a Python client that connects to local hardware systems and then interfaces to the Q-CTRL Cloud to access and run tailored and robust quantum control workflows. A digital model of the physical QPU, called a Virtual Device, automatically saves the results of these executions to a persistent storage object that can be easily reviewed and shared.

This tutorial introduces the core concepts behind the platform: the virtual device that acts as a digital representation of your QPU, the three-tier workflow hierarchy that organizes calibration tasks, and the supported hardware. Reading through these sections gives you the context you need before queuing your first calibration. The get started tutorial walks you through installation and a first calibration run.

1. Virtual devices as digital representations of a physical QPU

The central abstraction in Boulder Opal is the virtual device. A virtual device is a persistent server-side representation of your physical QPU, a digital record that stores resulting data, plots, and system parameters.

You create a virtual device from the device topology, controller wiring, and initial parameter estimates. Once created, the virtual device stores a model containing all QPU components (transmons, resonators, couplers, ...) together with their physical parameters. Every experiment and routine reads from and writes to this virtual device. When a routine measures a resonator frequency or a T1 time, the result flows back into the model so that subsequent calibration steps start from the most up-to-date values.

You can learn more in our Understanding virtual devices topic.

2. The workflow hierarchy

Boulder Opal organizes calibration work into three tiers. Each tier wraps the one below it in increasing levels of automation, so you can choose the level that matches the granularity of the task at hand.

Tier	Abstraction	Purpose	Example
Solution	Full-system calibration	Calibrate an entire QPU	Calibration
Routine	Component-level task	Calibrate one component	TransmonDiscovery
Experiment	Atomic measurement	Run one control sequence	ResonatorSpectroscopy

An experiment is the atomic unit. It runs one measurement program on the QPU and returns an analysis result that includes the swept parameter values, the fitted parameters, the raw data, and the diagnostic plots produced from the fit. You start with experiments when you want to test one behavior or validate one measurement. You use routines for end-to-end component tasks, such as characterizing a qubit. You use solutions when you want to calibrate the whole QPU in one call. Each higher level reuses the lower-level tools, so your results stay consistent.

For more information on how to run jobs, refer to the hierarchy of workflows topic or the How to run a custom experiment user guide.

3. Intelligent autonomy

Routines are not fixed scripts. They make decisions at each step based on the current state of the virtual device and the results of the measurements they have already taken, which is what lets them recover from incomplete starting information and adapt to a specific QPU as they learn about it.

TransmonDiscovery is a good example. It starts by scanning a wide frequency range to locate the qubit transition. If it finds a candidate, it narrows the scan automatically and refines the estimate. If the initial scan turns up nothing, it adjusts the drive power and retries with a fresh sweep. The same pattern recurs across the routine library: each one wraps a small state machine that decides what to do next from what it has just measured.

For more information on routines, read the hierarchy of workflows.

4. Supported hardware

Boulder Opal is designed and built to work on specific QPU vendors and models with validated control electronics. Please see the Supported architecture topic to find what hardware is currently supported. If you want to use Boulder Opal on a device not currrently listed, or using control hardware that is not currently validated, please reach out to us.

5. Data and state management

Every calibration job produces data, and the platform exposes that data through a small set of methods that cover both the per-job results and the device-level state they aggregate into.

You can learn more about reviewing job and device data in the Reviewing job results and device history topic or the How to retrieve and display data user guide.

Next steps

• Getting started tutorial: install the SDK, connect to your hardware, and run your first calibration end-to-end.
• Understanding virtual devices: a deeper look at the structure, components, and state-management workflow.