Browse documentation
Docs / Quantum Workflow / Qiskit coverage reference
Qiskit Sensor Coverage Reference
Sensor 0.12.6 reference for QuantumCircuit, pass managers, backends, targets, Sampler, Estimator, jobs, results, and supported capture limits.
Scope and recognition
This reference describes the 0.12.6 sensor implementation. It covers selected Qiskit, Qiskit Aer, IBM Runtime, and Mthree activity. SDK installation alone does not provide automatic coverage. Classes are checked by SDK module, inheritance, and supported access patterns; a matching name alone is insufficient.
Recognition, payload capture, and workflow display are separate steps. Some objects are only recognized when passed to a monitored function. The sensor does not turn every supported object type into an independent dashboard row.
Circuits and representations
| Class or representation | Captured data and conditions |
|---|---|
QuantumCircuit | Real Qiskit circuit ancestry with supported accessors. Object identity, circuit/version references, name, qubit/clbit counts, depth, size, operation counts, parameters, metadata, structure digest, bounded instruction data, and available layout. |
| Circuit instructions and control flow | Operation names, operands, supported parameters, stored definitions, and control-flow blocks within structure budgets. Unsupported internals can remain opaque. |
TranspileLayout | Supported exact class: initial/final index layouts, routing permutation, input/output width, and whether a final layout exists. Bounded summaries and supported value attachments. |
DAGCircuit | Identity and conversion relationships at supported converter boundaries. The full DAG graph is not serialized. |
Instruction, Gate | Representation identity at supported boundaries and a stored definition circuit when safely available. This is not a general serializer for arbitrary gate objects. |
SparsePauliOp, SparseObservable | Representation identities and supported term payloads when encountered in observed transformations or Estimator inputs. |
| Observed callable | Meaning |
|---|---|
QuantumCircuit.copy, copy_empty_like | New circuit object and its observed derivation. |
QuantumCircuit.compose, tensor, assign_parameters | Source circuits, supported arguments, and returned or in-place circuit state. |
QuantumCircuit.inverse, decompose, repeat, power, control | Supported circuit transformation and its observed output. |
QuantumCircuit.to_gate, to_instruction | Conversion from circuit to tracked instruction representation. |
QuantumCircuit.append | Insertion provenance only when the instruction representation was already tracked. Ordinary gate insertion is not universally traced. |
circuit_to_dag, dag_to_circuit | Representation conversions. DAG-to-circuit exports during a supported run can become pipeline snapshots. |
SparsePauliOp.apply_layout | Observed observable transformation and supported output payload. |
Nested helper calls can be suppressed to avoid duplicate transformation activities. Supported boundaries provide observed relationships, not a trace of every internal implementation step.
Pass managers and transpilation
| Class or callable | Coverage |
|---|---|
BasePassManager, PassManager, StagedPassManager | Manager identity, type, stages, enabled stage managers, task counts/types, and plan fingerprint. Supported stored task graphs contribute analysis/transformation classification and factory-plan evidence. |
AnalysisPass, TransformationPass | Recognized in configured task ancestry. Custom tasks can have unknown behavior or incomplete inspection. No universal event for each pass execution and no full property_set capture. |
qiskit.transpile | Authoritative Qiskit transpilation function: observed inputs, options, backend/target, returned circuits, timing, and failure outcome. |
generate_preset_pass_manager | Factory options and returned manager identity, allowing supported later runs to be associated with their configuration. |
PassManager.run | Whole-run input/output and manager context. StagedPassManager uses this inherited execution boundary. Generic, analysis-only, and transformation runs are not automatically classified as compilation. |
_run_workflow and dag_to_circuit | Sparse internal observation points for associating explicit circuit exports with the running pipeline. Stage attribution requires unambiguous configured task context. |
Observed compilation context can include backend/target information, optimization level, basis gates, initial layout, stage methods, approximation degree, and transpiler seed when they use supported values. Exact coverage depends on the callable’s available arguments.
Backends and targets
| Object | Captured data |
|---|---|
| Backend/simulator families | Recognized SDK objects with run and backend/simulator ancestry. Type, passively available name, version, qubit capacity, maximum circuits, bounded options, available instance CRN, and target. This includes compatible GenericBackendV2, Aer, and IBM backend objects. |
Target | Available operation/qarg entries with durations and errors; operation names, coupling edges, description, width, dt, available T1/T2/frequency, digest, and completeness. |
CouplingMap | Not a separately serialized namespace artifact. Connectivity is recorded through an available backend Target. |
The sensor does not invoke backend.configuration() or a callable backend.name() for inspection. The recorded target is a snapshot of available fields, not a promise that all backend timing constraints or calibration data were captured.
Primitives, PUBs, parameters, and observables
| Object or input | Coverage |
|---|---|
| Sampler/Estimator families | Recognized SDK classes with Sampler/Estimator ancestry. Primitive kind, bounded options, passively accessible backend, and supported .run() inputs. |
SamplerPub, EstimatorPub, tuple/list PUBs | For materialized list/tuple submissions: circuit, unit index, parameter values and shape, shots or precision, and supported observables. Generators are not consumed to recover their PUBs. |
BindingsArray | Binding shape and stored parameter-value data through an exact-type adapter, subject to value budgets. |
ObservablesArray | Stored observable array and shape through an exact-type adapter; supported nested observables may also carry artifact identities. |
SparsePauliOp, SparseObservable | Supported exact-type term adapters and observable summaries where available. |
Pauli, strings, dictionaries, supported arrays | Supported observable summaries where available. Recognition of Pauli does not supply a full exact-value serializer for that class. |
Parameter, ParameterVectorElement | Supported exact types provide name and UUID. Complex ParameterExpression values do not have a general exact-value adapter. |
| Built-in values and supported NumPy types | Flat structured values; supported arrays include shape, dtype, and values within budgets. Unsupported dtypes/classes retain limited or unavailable capture. |
Observable summaries can include shape, count, term count, maximum Pauli weight, and coefficient norms. These summaries can be bounded and must not be treated as complete statistics when their inputs exceed capture limits.
Execution, jobs, and results
| Boundary or artifact | Coverage |
|---|---|
Backend or primitive .run() | Execution capture requires a positively recognized backend, Sampler, or Estimator receiver. A method named run on an unrelated object does not qualify. |
| Job lifecycle methods | submit, result, status, cancel, wait_for_final_state, done, running, cancelled, in_final_state, is_final_state, job_id, metrics, and usage, when implemented at recognized SDK boundaries on a Job-like receiver. This is not general backend .submit() coverage. |
| Job-like objects | Runtime identity and job handle, already stored job ID, passive backend/instance information, available metadata, and observed result relationships. |
| Result-like objects | Type, experiment/PUB count where available, and bounded metadata. Being recognized as Result-like does not serialize all result data. |
PrimitiveResult, PubResult, SamplerPubResult, DataBin | Supported exact containers provide per-PUB shape and selected evs, stds, and ensemble_standard_error payloads. Unsupported result/container implementations are not fully decoded. |
BitArray.get_counts() | Links the returned counts object to its source job for supported later mitigation provenance. This observation alone does not persist the histogram payload. |
| Optional result-count query | When explicitly enabled, the sensor may call get_counts() on a recognized result object that provides it and retain a bounded summary. Disabled by default. |
Notebook lifecycle observations, control-plane provider refresh, and result normalization are distinct sources of evidence. A complete provider result view is not guaranteed solely by recognizing a returned job.
Mitigation and circuit imports
| Boundary or evidence | Coverage |
|---|---|
| Runtime mitigation | Selected resilience, measurement mitigation, ZNE, PEC, twirling, and dynamical-decoupling settings; supported numerical result fields including noise-factor and extrapolated values. Field and array limits apply. |
M3Mitigation.apply_correction | Supported raw counts, corrected quasi-probabilities, qubit mapping, overhead, and source-job association when the original counts identity was observed. |
| M3 calibration methods | cals_from_file, cals_from_matrices, cals_from_system, and cals_from_backend: observations of user-invoked calibration activity. The sensor does not initiate calibration. |
qiskit.qpy.load | Returned circuit identity and import relationship. A supplied BytesIO can contribute its digest and stream offset. Arbitrary files are not independently read by the sensor. |
qiskit.qasm2.load/loads, qiskit.qasm3.load/loads | Returned circuit relationship and the supplied source argument. Provided strings can be captured with a digest. For a filename string, the string is the path; it is not the file contents. |
Configuration defaults
These are sensor source defaults for 0.12.6. Deployment settings can override them. Environment changes belong to the kernel deployment configuration; setting a notebook variable is not a supported way to reconfigure an already installed sensor.
| Setting | Source default |
|---|---|
SPINORIO_SENSOR_INCLUDE_CELL_CODE | false — cell code is excluded from this sensor payload by default. |
SPINORIO_SENSOR_INCLUDE_ERRORS | true — supported error information can be recorded. |
SPINORIO_SENSOR_CAPTURE_RESULT_COUNTS | false — no automatic result-count query by default. |
SPINORIO_QPY_CAPTURE_ENABLED | false — full QPY artifact upload is optional and also requires a configured endpoint. Structural fingerprinting can use QPY independently. |
SPINORIO_SENSOR_MAX_RUN_UNITS | 0 — no separate PUB item-count ceiling; other capture/transport budgets still apply. |
SPINORIO_SENSOR_MAX_OBSERVABLES | 0 — no separate observable item-count ceiling; other budgets still apply. |
Capture limits
| Source default budget | Value |
|---|---|
| Boundary events per cell | 10,000 |
| Locals inspected per event / circuit collection limit | 20 locals / 16 circuits on bounded collection paths |
| Namespace items inspected | 200, derived from 10 × the locals setting |
| General collection summary / string summary | 100 items / 1,000 characters |
| Tracked circuits / pass managers | 4,096 circuits / 1,024 managers |
| Configured pass-manager task inspection | 512 task-budget entries |
| Intermediate snapshots | 512 per tracked run; event budget also applies |
| Target instruction entries | 20,000 |
| Circuit preview / structure analysis | 128 preview instructions / 10,000 analysis instructions |
| Circuit nesting / namespace container depth | 8 levels / 3 levels |
| Exact-value attachment | 20,000 nodes / 4 MiB |
| Separate capture details per cell | 256 details / 64 MiB |
| Mitigation summaries | 8 PUBs; 128 numerical values per supported array; 256 outcomes per supported distribution |
These budgets apply at different steps and do not combine into a guarantee that a whole workload is preserved. For example, an unlimited PUB count setting does not remove the exact-value byte budget, circuit collection limits, or delivery limits.
Some captures include complete/incomplete status, truncation reasons, omitted counts, or opaque representations. A record can therefore remain useful while some details are unavailable. Unsupported boundaries can also produce no event; absence of a warning does not establish complete coverage.