Overview
EveryQuantumDevice has a set of runtime options that control the behavior of the device.run() call.
These options govern which steps in the job submission pipeline
are enabled, and can be updated using device.set_options().
The four default options correspond to the pipeline steps that precede job submission:
| Option | Default | Type | Description |
|---|---|---|---|
transpile | True | bool | Convert the program to the device’s target program type |
transform | True | bool | Apply device-specific passes (e.g. gate decomposition, topology mapping) |
validate | ValidationLevel.RAISE | ValidationLevel or int | Verify the program satisfies device constraints |
prepare | True | bool | Serialize the program to the submission IR format |
apply_runtime_profile pipeline invoked by device.run():
transform=False means the program
will not undergo any device-specific gate set transformations before validation.
API Reference:qbraid.runtime.RuntimeOptions ↗
Transform
TheQuantumDevice.transform step applies device-specific transformations to the program. This is where
gate decompositions, topology mapping, and other hardware-aware compilation passes are performed. The base
class implementation is a no-op — each provider overrides transform() with its own logic.
Setting transform=False skips this step:
IonQ
TheIonQDevice.transform method decomposes the input OpenQASM program into the IonQ native gate set.
It loads the program, applies gate mappings (single-qubit, two-qubit, and three-qubit), and falls back to
pyqasm.unroll() if the initial transformation fails:
IBM
TheQiskitBackend.transform method runs the program through a Qiskit PassManager
to produce an ISA (Instruction Set Architecture) circuit compatible with the target backend.
By default, it uses generate_preset_pass_manager(backend=...), but you can supply your own:
pass_manager option.
AWS
TheBraketDevice.transform method applies provider-aware transformations. For IonQ devices accessed
through Amazon Braket, it routes the circuit through pytket for an expanded gate set, then applies
Braket-specific transformations. For other Braket-supported devices, it applies standard device transformations
through the load_program interface.
Validate
The validate step verifies that the run input satisfies all criteria for submission to the target device. This includes checks such as ensuring the number of qubits in the circuit does not exceed the device’s capacity, and that the program conforms to the device’sProgramSpec.
Validation behavior is controlled by the ValidationLevel enum:
| Level | Value | Behavior |
|---|---|---|
ValidationLevel.NONE | 0 | No validation is performed |
ValidationLevel.WARN | 1 | Warnings are issued if validation fails |
ValidationLevel.RAISE | 2 | Exceptions are raised if validation fails (default) |
API Reference:qbraid.runtime.ValidationLevel ↗
Validation in action
By default, validation is set toRAISE. If a program violates device constraints, a
ProgramValidationError is raised:
Disabling validation
To skip validation entirely, set the validation level toNONE. You can use either the enum or
pass False as a shorthand:
Downgrading to warnings
To receive warnings instead of errors, set the validation level toWARN:
Re-enabling validation
To restore the default strict validation behavior:Prepare
The prepare step serializes the quantum program into the intermediate representation (IR) required for submission to the target device’s API. This might produce a JSON payload, an OpenQASM string, bytecode, or any other format expected by the provider. The base class implementation delegates toProgramSpec.serialize(), which is defined per-provider.
For example, Pasqal Pulser sequences are serialized into a JSON-based abstract representation, and
OpenQASM programs may be wrapped into a Program object with format and data fields.
Setting prepare=False skips this step, leaving the program in its current in-memory representation:
Provider-Specific Options
Providers can extend the default options with their own fields. These additional options are merged into the device’s configuration at initialization and follow the sameset_options interface.
IBM pass_manager
The QiskitBackend adds a pass_manager option that accepts a Qiskit PassManager instance (or None).
When set, the custom pass manager is used during the transform step instead of the default preset pass manager:
pass_manager back to None:
pass_manager option includes a built-in validator that only accepts None or a PassManager instance.
Attempting to set it to any other type raises a ValueError.
Advanced: RuntimeOptions
Under the hood, device options are managed by theRuntimeOptions class, a dataclass-like container
with dictionary-style access, dynamic field support, and custom validators. While device.set_options()
is the primary interface for users, understanding RuntimeOptions can be useful when
writing a new provider.
Initializing with custom fields
Adding dynamic fields
Fields can be added at any time using attribute or dictionary syntax:Removing dynamic fields
Dynamic (non-default) fields can be deleted. Default fields cannot be removed:Setting validators
Validators are callables that returnTrue for valid values. Once set, every update to the field is
checked against the validator:
ValueError
is raised. You must update or delete the field first before replacing the validator:
Merging options
Providers usemerge() to combine custom options with the device defaults. The override_validators
parameter controls whether validators from the merged options replace existing ones:
options to a QuantumDevice constructor, as
shown in the IBM pass_manager example.