Call a quantum computer what its operators see every day: a physical system under continuous measurement, with a second apparatus attached to it whose only job is to measure the first one, over and over, to find out whether it still works the way it did yesterday. That second apparatus produces data, a great deal of it, and the question of where that data lives and how it is kept is a question the environmental monitoring world has been answering for decades.
The question came up for us on September 9, at the Colorado Technology Association's WIT in Denver, during a panel called "Women leading the quantum economy." The panelists came from Atom Computing, Quantinuum, the Colorado School of Mines, and the Colorado Quantum Incubator, and the conversation, as billed, was about the talent, investment, infrastructure, and cross-sector collaboration it takes to turn Colorado's scientific lead into an industry. We were in the audience, and the question we left with was narrower than any the panel took up: what does it take, day to day, to know what a quantum computer is actually doing?
What does a quantum computer measure about itself?
A qubit is the device's basic unit, and it is a physical object: a superconducting circuit, a trapped ion, or a neutral atom held in place by light. It holds its state for a limited time. T1 is how long, on average, a qubit stays in its excited state before it relaxes. T2 is how long it keeps phase coherence, which is the property that makes it useful for computation at all. Gate error is how often an operation on one or two qubits comes out wrong. Readout error is how often the answer the machine reports disagrees with the state the qubit was actually in. Calibration is the routine that re-measures all of these and re-tunes the control signals to whatever the numbers are today.
The vendors publish the shape of this record. IBM's documentation reports T1, T2, frequency, readout error, and per-gate error for each qubit, and each property comes paired with the timestamp of its last calibration. A caller can also request the properties as they stood on an earlier date. Google's Cirq documentation says that calibration data "is stored by Quantum Engine and users can then query for the current or previous state of the calibration." Google also publishes a tutorial titled Identifying hardware changes, whose premise is that a circuit's results can shift because the device changed since its last maintenance calibration, and whose advice is to re-characterize and then choose qubits accordingly.
Those two design choices are the whole shape of the problem. The number is time-stamped because it will be different tomorrow. The history is queryable because the honest explanation for a changed result is often a changed machine.
How do labs keep this data today?
For the machines the large vendors operate themselves, the vendor keeps the record, and the interfaces above are the public face of it. Inside the labs and companies building the hardware, the picture is more mixed, and more familiar. Open-source acquisition frameworks such as QCoDeS and Quantify drive the instruments and save each experiment's results, Quantify using the xarray dataset format. What an experiment file captures less well is the thing that spans experiments: what the device was on each day, what was changed in between, and whether the numbers from March can be compared with the numbers from September.
A 2024 paper from the team behind QubiC, the open-source qubit control system at Lawrence Berkeley National Laboratory, describes the state before they built their own tool (Scientific Reports, 2024). Calibration files were kept locally. Characterization data sat in JSON files inside notebooks. Sharing those files and keeping everyone on the latest version was, in their words, "a logistical hurdle." Their answer, QubiCSV, pairs a version-controlled database for calibration parameters with a document store for characterization data, with commit and branch semantics at the database level, so that a parameter set can be traced to the moment it was recorded. A 2025 preprint on quantum processors attached to high-performance computing clusters (arXiv 2508.21231) takes the analysis side: its authors examined more than 250 days of calibration metrics from a 20-qubit device, found temporal patterns among the metrics, and used clustering to derive per-qubit health indicators and recommended maintenance schedules.
Read together, the field is converging on requirements that have nothing quantum about them. A time-stamped record of the device state. Versioning of the parameters that produced a result. Long histories, queryable by time, so drift can be seen rather than suspected. And a place where the metadata about what changed sits next to the measurements it explains. Every measurement has to carry three things: what was measured, what measured it, and when that instrument was in place.
Why does this look familiar to an environmental analyst?
Swap the quantum lab for a monitoring network. A monitoring network has instruments on sampling points: a stream gauge, an air monitor, a well. Instruments get swapped when they fail, recalibrated on a schedule, and moved to a new site when a study ends. A step-change in the record is either something that happened in the world or the day the instrument changed, and an analyst who cannot tell those two apart cannot stand behind the number in front of a client, a community, or a regulator. The analyst does not stop working. They hesitate, re-pull the data, ask the field technician what happened in March, and the report slips a week.
The physical systems are different. The bookkeeping is the same. Quantum labs are working out, right now, how to keep the record of the instrument alongside the record of the measurement. Environmental science has been at that problem for a long time, under regulators who ask "how was this number derived?" and expect an answer that names the sensor. Datasparks was built around that answer.
What Datasparks does with a physical system
The model has four parts. Sites are places. Sampling nodes are the points within a site where measurement happens. Technologies are kinds of instrument, with their attributes. Assets are the individual serialized units, each identified by its own code and by whatever aliases the vendors' exports use for it. The deployment log ties them together: it records which technology, and optionally which specific asset, sat on which sampling node from an installed time to a removed time, with a parent-child hierarchy for instruments that sit inside other instruments.
Attribution happens at ingestion. When a reading arrives carrying an asset identifier and a timestamp, the pipeline resolves which deployment covered that moment and writes the resulting sampling node onto the stored row. The reading is tied to the place and the instrument at the moment it was taken, and that outcome is stored with the data rather than recomputed later.
The deployment log is treated as lineage, not as editable data. Rows are never hard-deleted. Deleting a deployment hides it from the default view, and the original window survives so the history can still be read. Swapping or moving an instrument is one atomic operation: the old window closes and the new one opens in the same transaction, or neither happens. A half-changed log is worse than an unchanged one, and the platform refuses to produce one.
Quality rules follow the same discipline. A ruleset is defined once and scoped across metrics, sources, and sampling nodes. Every slice of stored data carries a digest of the rule versions that checked it, so a stale result is detected by comparing digests rather than assumed to be fine, and committing a rule change rechecks what that change touches. And gaps stay gaps: a harmonized dataset preserves missing intervals by default, and interpolation or smoothing is a choice made per dataset variant, where a different choice is a different variant rather than a silent edit to the same one.
Datasparks sits above the instrument. A control system talks to the electronics and runs the pulse sequences, and it is the only thing in the stack that knows what a T1 is. Frameworks such as QCoDeS and Quantify drive the instruments and save each experiment. Datasparks takes the readings those tools produce, organizes them around the physical system they describe, and keeps them defensible over years. Our customers today monitor environmental and industrial sites. A quantum lab would be new ground for us, and it is better to say that plainly than to pretend the domain knowledge is already in hand.
The data layer under every kind of computation
The panel's subject was infrastructure. A data layer is infrastructure. The Boulder, Louisville, and Broomfield corridor is now home to more than 30 quantum companies, and every machine those companies build depends, on its classical side, on the same discipline: a reliable, time-aware, defensible record of what a physical system did and what was done to it. That is the record traditional analytics runs on. It is the record an AI has to be handed before it can explain a drift instead of inventing a reason for one. And it is the record a quantum computer's own operators consult every morning before they decide which qubits to trust.
We expect the tools quantum labs are building for themselves to keep converging on that shape, because the shape comes from measurement, not from qubits. If you run a lab or a fleet that measures a physical system all day, and the record of what changed is living in files and notebooks, we would like to compare notes.
