Following a quantum experiment as it evolves

How a simple experiment becomes a branching workflow

Consider a researcher developing a parameterised circuit. An initial version is tested on a simulator, copied to explore a different construction, and compiled for a hardware target. Several parameter settings are submitted, results are inspected, and the circuit is revised again. A collaborator may continue from an earlier version while hardware jobs from the previous iteration are still running.

Each step introduces another relationship to preserve. A result belongs to a particular submission. That submission used a particular circuit representation and parameter set. The compiled circuit came from a specific input and compilation configuration. A later edit to the notebook does not change what an earlier job executed.

The experiment therefore develops into a graph of related artifacts and activities. A file name, variable name or job identifier describes only part of that graph. As branches, repetitions and asynchronous jobs accumulate, manually reconstructing the connections becomes increasingly difficult.

This also affects interpretation. A change in an observed result might accompany a circuit revision, a new parameter binding, different compilation settings or a different device context. The record needs to retain those distinctions before a comparison can be assessed.

What has to stay connected

A useful experiment record preserves both artifacts and the activities that relate them. Spinorio’s capture model connects the following evidence when the relevant objects and supported execution boundaries are observed:

This makes it possible to follow a captured result back through its job, submitted circuit and processing history, with notebook and cell context where available. A missing observation remains a gap in the record; the current contents of a notebook cannot establish every earlier state.

Our approach: a sensor and a control plane

The sensor operates in the notebook’s Python kernel. An IPython hook establishes the cell’s execution context, CPython monitoring observes selected SDK calls, returns and exceptions, and a bounded inspection of the namespace discovers recognised objects when the cell finishes. Observation records and separate detail payloads are queued for delivery.

The control plane uses the received evidence to assemble workflow records and provenance relationships. Spinorio’s observation model separates this record-building work from the live objects in a particular kernel session.

The resulting Workflow workspace provides distinct views for logical circuit lineages, circuit-processing runs and jobs. Search, research metadata and linked inspectors let researchers move between those views without treating every object or execution as the same kind of record.

Automatic observation covers selected Qiskit-family activity. It has explicit limits on inspected objects, events, structures and payload sizes. The sensor uses the observed program activity without wrapping user functions, inserting compiler passes or replacing callbacks; it also does not provide an instruction-by-instruction history of every mutation.

Following circuit identity as the experiment changes

A live circuit object, a captured circuit state and a logical lineage have different roles. Giving the same object another variable name creates an alias. Copying it creates a distinct object that may initially have the same structure. A later observation of an edited circuit can preserve a new immutable state.

Spinorio tracks object identity and uses structural fingerprints to help detect change. Observed calls such as copying, composition, tensor products and parameter assignment supply derivation relationships. The Circuits inspector organises captured states into lineages and exposes their history, related processing runs and linked jobs.

Selecting a state selects the circuit representation being inspected. Researchers can compare parent and child states, or compare independent circuits, using depth, two-qubit counts, interaction changes and operation differences. Structural similarity helps explain a change, while functional equivalence requires its own verification.

Preserving compilation and submission context

Compilation can change circuit structure substantially before execution. Spinorio observes supported boundaries such as qiskit.transpile(), generate_preset_pass_manager() and PassManager.run(). These observations can connect input and final output states with the manager configuration, timing and outcome.

The Circuit processing inspector exposes the available input/output metrics, layout and hardware evidence. Processing records distinguish compilation, analysis and transformation when the captured plan supports that classification. Intermediate circuits can be recorded when notebook code explicitly exports them through dag_to_circuit() during a supported run; every internal pass state is not automatically captured.

At submission, supported Sampler and Estimator inputs can preserve circuit relationships, parameter values and shapes, shots or precision, and observables. Available target evidence can include native operations, connectivity, durations and errors. The coverage reference specifies which representations and callable boundaries support those fields.

Keeping these contexts together allows a researcher to distinguish a change in the logical program from a change in its compiled representation or execution request.

Keeping jobs connected after the notebook closes

A provider job can outlive the notebook session that submitted it. The sensor observes lifecycle calls made by the notebook; it does not poll job status or request results simply to discover them. Remote provider synchronisation is a separate control-plane responsibility.

With a connected IBM Quantum account and a captured eligible job identity and service-instance context, the control plane can continue synchronising job status, metrics and supported results after the kernel closes. Researchers can revisit that job from the experiment record and request a provider refresh where available.

The provider credential is encrypted in the control plane and remains separate from notebook authentication. It is not passed to the sensor or transferred to collaborators through project sharing. The experiment’s recorded history remains available if the provider connection is later disconnected.

Inspecting the evidence behind a result

The Jobs and results inspector brings execution status, supported results and provenance into the same record. Available Sampler outcomes can be inspected by workload unit and register; supported Estimator results expose expectation values and uncertainties. Missing, unsupported or bounded result data retains its reported status.

Execution analysis distinguishes observed wall-clock timing from provider-reported QPU usage. Where the data supports it, workload expansion relates logical work units to physical circuits and shot executions. Persisted calibration evidence can identify the snapshot and hardware context associated with the record.

These distinctions matter when assessing an experiment. Circuit metrics describe structure, calibration-based quality estimates depend on a model, and processor results are measurements. Spinorio keeps those forms of evidence identifiable so that an apparent improvement can be assessed in the context that produced it.

Sharing work while preserving its history

An experiment also evolves through collaboration. Spinorio Projects group selected records and preserved source snapshots with owner, contributor and viewer roles. Shared records retain their original scientific ownership, and contributors can continue work on separate branches with fixed starting points or recorded checkpoints.

Notebook source is included with explicit consent, supporting files are selected separately, and saved outputs are excluded by default. A contributor’s notebook copy has its own working context. Live kernel state and provider credentials are not transferred, and project branches preserve separate histories without experiment or source merging.

Selected evidence can be exported as JSON, CSV or a PDF research report, with partial or unavailable data represented explicitly. This gives researchers a record they can inspect, discuss and revisit as the experiment develops, together with the limits of what was captured.