A self-driving lab for electrochemical systems
Built downward from the measurement — not upward from the synthesis.
AI alone is not enough. An autonomous lab needs hardware that can both observe the system and act on it, all under script control. Building that hardware layer — for systems that are running, coupled, and buried — is what this platform is.
Built down from analysis, not up from synthesis
Most self-driving labs are built upward from synthesis. A robot makes a material, a fast measurement scores it, an optimizer picks the next composition. The measurement is chosen because it is cheap — the whole loop is designed around the throughput of making.
Our problem does not yield to that. What we need to optimize is not a composition on a tray; it is a system that is already running and changing while we watch it. No single cheap number scores it, and it cannot be taken apart to be read without ending the experiment.
So we build in the other direction — downward from the measurement. We start from what the science requires us to see, and every layer beneath exists to make that measurement possible, repeatable, and scriptable.
built upward from synthesis
built downward from analysis
Most self-driving labs automate making. We automate seeing — and then acting on what we see.
Instruments built for the measurement
Descending from the measurement has a consequence: sooner or later you reach something no instrument on the market can measure. A lab built up from synthesis rarely meets that wall, because it measures whatever happens to be convenient. We meet it constantly, because the requirement comes first.
So we design and build our own — sensors, analog front-ends, mechanics, and the software that drives them — specified around the measurement we need rather than around what a vendor chose to sell.
Building in-house also means building open. Every instrument we make is scriptable from the start, which is what lets it join the connected setup below instead of sitting behind its own closed interface.
One connected setup
An instrument that cannot be driven from a script cannot take part in a loop. So every part of the setup is driven and read by our own code. Many programs run at once — one per instrument — but they share a clock and write into one record, belonging to one experiment.
They run at very different rates: impedance spectra in seconds, force and temperature continuously, images only occasionally. Keeping these multi-rate streams aligned is what the shared record is for — without it, a change in one quantity cannot be attributed to a change in another.
The loop closes on a running system
With measurements arriving live, the loop can act on the system itself rather than on the next sample. Measured properties feed a prediction of where the system is heading; when that trajectory points toward instability, the operating conditions are adjusted — mechanical, thermal, electrical, whatever the setup can apply — before the damage is done.
This is the part a materials-first self-driving lab structurally cannot do. Its loop closes on the choice of the next material to make. Ours closes on the system that is already running.
We are building the hardware layer a self-driving lab for electrochemical systems actually needs: instruments that can see what matters, all under one script, closing the loop on a system while it runs.
For the scientific questions this platform is built to answer, see our research vision and our work on solid-state batteries.