Browse documentation
Docs / Quantum Workflow / What Spinorio captures
What Spinorio Captures
Learn what sensor 0.12.6 records from Qiskit notebook code: circuits, processing runs, submissions, jobs, and selected results.
Start with a circuit
Run ordinary Qiskit code in a Spinorio Lab Python kernel with the sensor enabled. Supported circuit state is observed at selected SDK calls and at the end of the cell; basic capture needs no additional Spinorio call.
from qiskit import QuantumCircuit
qc = QuantumCircuit(2, 2)
qc.h(0)
qc.cx(0, 1)
qc.measure([0, 1], [0, 1])
alias = qc
copied = qc.copy()| Notebook code | Observed meaning |
|---|---|
qc = QuantumCircuit(...) and gate additions | The resulting circuit can be discovered in the notebook namespace when the cell finishes. Individual gate helper calls are not each recorded as activities. |
alias = qc | A second name for the same live circuit object. The alias does not create a separate circuit version. |
copied = qc.copy() | A new object with an observed copy relationship to its source. A copy can have the same structure as its source while retaining a distinct object identity. |
| An edit followed by another observation | A changed structure can produce a new immutable circuit state. Edits between observation points are not a complete instruction-by-instruction history. |
A circuit object, an immutable captured state, and a row in the Circuits table serve different purposes. The control plane groups scientific records using their provenance, so the number of notebook variables or snapshots need not equal the number of table rows.
Artifacts and activities
| Qiskit activity or object | Data available to Workflow |
|---|---|
| Circuits | Observed identity and versions; names and aliases; width, depth, size, operation counts, parameters, metadata, bounded instruction structure, and layout when available. |
| Circuit transformations | Input/output or in-place state relationships for supported operations such as copy, compose, tensor, and parameter assignment. |
| Pass managers and transpilation | Configured stages and task types, selected settings, observed input/final output, timing and outcome. Explicitly exported intermediate circuits can provide snapshots. |
| Backends and targets | Backend identity and available options; target operations, connectivity, durations, errors, dt, and available qubit properties. |
| Sampler and Estimator runs | Circuit/PUB inputs, parameter bindings, shots or precision, supported observables, backend context, and the returned job relationship. |
| Jobs and results | Job identity, lifecycle calls made by notebook code, available metadata, and selected result fields such as expectation values and uncertainties. |
| Supported mitigation | Selected Runtime mitigation settings/results and M3 calibration/correction observations when the notebook performs those operations. |
Coverage differs by object type. Some artifacts have structured values; others retain only identity and relationships. Large or unsupported values may have partial or unavailable capture. The coverage reference describes these distinctions.
Processing a circuit and executing it
from qiskit import transpile
from qiskit_aer import AerSimulator
# qc is the circuit from the previous example.
backend = AerSimulator()
compiled = transpile(qc, backend=backend, seed_transpiler=42)
job = backend.run(compiled, shots=1024)
result = job.result()The transpilation boundary provides the observed source and output states. The backend run provides submission evidence for the compiled circuit and a returned job. Calling job.result() provides the relationship between that job and its returned result.
These observations can connect the logical circuit, processing run, submitted circuit, job, and result. A missing boundary or unsupported value can leave a gap. Workflow does not obtain a complete historical execution simply because a circuit remains in a later cell.
Automatic histogram extraction through a result object’s get_counts() is disabled by default. Provider synchronization may supply additional result data separately from the notebook sensor.
Notebook history and compilation analysis
The sensor records supported activity that actually occurs in the notebook. Compilation Stages analysis requested from a circuit inspector is a separate worker job using a preserved input. Its stage outputs are analysis artifacts, not evidence that the notebook executed those stages or changed its circuit.
Circuit drawings produced by circuit.draw() or display() are not captured as rendered images by the sensor. Spinorio renders diagrams from the circuit data available to its inspectors.