The environment is part of the experiment
Writing a quantum circuit is one part of a larger development process. The same project can depend on Python libraries, simulation tools, compiler settings, provider authentication and numerical analysis. Before an experiment can be evaluated, these pieces need to work together.
Maintaining separate environments introduces practical work: installing SDKs, resolving dependencies, choosing the right notebook kernel and moving information between local files and provider dashboards. A change in software or configuration can also affect how an experiment is prepared or interpreted.
A useful quantum lab therefore needs to support both execution and context. Researchers should be able to write code, inspect circuits, compare compiled forms and return to the evidence behind a result within a consistent workspace.
Pre-installed quantum SDKs
A prepared software environment gives researchers a starting point for development without repeating the initial installation of commonly used quantum tools. The supplied environment includes the following software, as listed in the Lab documentation:
| Area | Included software |
|---|---|
| Qiskit tools | Qiskit, Qiskit Aer and Qiskit IBM Runtime |
| Additional quantum tools | PennyLane, Amazon Braket SDK, pytket and pytket-qiskit |
| Scientific computing | Common scientific Python packages |
This brings several quantum programming tools into the same notebook environment. Researchers can select the SDK appropriate to their work while using a common place to develop code and analyse outputs. The installed software and its configuration remain part of the context needed to revisit an experiment.
Integrated quantum workflow
The notebook remains the place to develop and execute code. An integrated workflow connects supported activity to the circuits, processing records, jobs and results it produces. Basic tracking can follow normal Qiskit notebook code without requiring an extra tracking call, as shown in the getting started guide.
The notebook-specific sidebar provides a local view of observed work. The global Workflow workspace brings records across notebooks into searchable Circuits, Circuit processing and Jobs views. A researcher can move from an execution record to its related circuit and captured processing history.
Captured circuit states can be inspected through diagrams, structural metrics and history. Supported transformations preserve derivation relationships, while jobs retain their execution context. These connections help distinguish a change in a circuit from a change in its compilation or submission settings.
Automatic capture follows supported Qiskit-family activity. The installed SDK collection is broader, so using a bundled library does not by itself establish that its objects and executions will appear in Workflow. The record reflects the available observations and their capture limits.
From simulation to a chosen hardware target
Local simulation provides a practical first step for developing a circuit and checking its behaviour. The documented Qiskit Aer example runs in the Lab without an IBM account, allowing the researcher to explore notebook execution and the associated workflow records before connecting remote hardware.
Integrated compilation tools can then prepare a preserved Qiskit circuit for a manually selected target. Available target sources include live IBM QPUs, saved hardware configurations and offline reference targets. Captured results expose circuit metrics and compilation history, and a completed compiled circuit can be inserted into the active notebook.
A comparison can use the same input, target and optimisation level to inspect a standard compilation baseline. This supports a consistent assessment of depth and gate counts. Structural measurements still need to be interpreted alongside the computation’s correctness requirements.
Compilation prepares the circuit; hardware execution is a separate action. Remote execution uses the researcher’s provider access and notebook authentication. An IBM connection in Workflow enables server-side job synchronisation and target discovery, while notebook-side Runtime authentication remains separate.
Continuing and sharing research
Development continues after a cell finishes or a result arrives. The environment should make it possible to revisit a circuit state, inspect the work that followed from it and communicate the relevant evidence to another researcher.
Integrated projects group selected experiment records and preserved source snapshots. Roles and separate contributor branches support access to shared work while retaining original authorship. Notebook source is included with explicit consent, and project copies keep their own working context.
Researchers can also export selected evidence as structured JSON, tabular CSV or a PDF research report. Keeping the scope and availability of that evidence visible helps collaborators understand what was captured and which parts of an experiment need further investigation.
Spinorio Lab
Spinorio Lab is QuantGates’ implementation of this approach: a JupyterLab environment that brings quantum SDKs, notebook development, integrated workflow and compilation into one research workspace. Workflow and Compile are available directly from the menu, alongside ordinary notebook editing and execution.
For compilation from notebook code, the bundled Python package provides spinorio.qcompile(). In an authenticated Lab workspace, it submits a Qiskit circuit to the compiler and returns the completed compiled circuit for further work. The same integration supports target discovery and loading recorded compilation outputs.
The Spinorio Lab documentation describes the environment and its supported integrations. The first experiment guide follows a local Qiskit circuit from notebook execution into Workflow, providing a starting point for developing, compiling and inspecting quantum experiments in the same environment.