Note · lab software
Provenance was the point
I built a lab automation framework for two years. Here is what it was actually for, which half of that problem got solved by something else, and which half did not.
Two problems, not one
Praxis came out of two things I kept running into, and it is worth separating them because only one of them has changed.
The first was people. Plenty of excellent scientists do not want to write code, and should not have to. A protocol that only runs if you can debug someone else's Python is a protocol most of the lab cannot use. So the framework had tiered access: a usable interface on top, scripting underneath for the people who wanted it.
The second was the state of the data. I had spent enough time inside research repositories that had been assembled quickly and then grown — directories named after dates, three versions of the same analysis, a results file nobody could regenerate. Not because anyone was careless. Because nothing in the workflow made recording the run cheaper than not recording it.
So the framework recorded everything: what ran, on which deck layout, with which volumes, against which version of the protocol. Stored so an Could someone else reconstruct what happened, months later, without asking you? was possible rather than archaeological. That was the part I cared about.
What automation is actually good for
The usual case for lab automation is throughput, and throughput is real. It is not the interesting part.
A protocol as written is never the protocol. Every wet-lab method carries context that did not survive being written down — how long the plate sat out, which tip the technician reached for, what "mix gently" meant that afternoon. Those idiosyncrasies are where a computational person's assumptions quietly die, and they are invisible in the methods section.
A robot does not eliminate that context. It collapses it into settings. The hidden variables become explicit parameters, and explicit parameters can be recorded. That is an epistemic gain, not a logistical one, and it is the reason automation belongs in the same stack as the models rather than in a support role beneath them.
The other honest reason: I do not reliably track every volume and plating at the end of a long day. The machine does.
What changed
The accessibility half of that problem is not what it was.
A large amount of the work in Praxis went into not making people write code — the interface, the guardrails, the tiering, the careful design of what a non-programmer should never have to see. That investment made sense when the distance between "I know what I want the deck to do" and "I have working Python that does it" was measured in weeks.
With current coding assistants that distance is much shorter. A scientist who can describe a protocol precisely can now get a runnable script without a framework mediating for them. The bridge I spent a long time building is one a lot of people can now walk across unaided. That is straightforwardly good, and it means the marginal value of building that layer no longer justifies what it costs to build and maintain.
What did not change
Provenance did not get solved. If anything it got harder.
More generated code means more code that runs correctly and is understood shallowly. The failure mode of a hastily assembled repository was never that the code was hard to write — it was that six months later nobody could say which version produced which numbers. Lowering the cost of producing analyses without lowering the cost of recording them makes that worse, not better.
So the half of Praxis I would rebuild is not the interface. It is the ledger: what ran, on what, when, against which version, recorded because recording was the path of least resistance rather than an act of discipline.
Status
Praxis is paused, not archived. It did what I needed it to do, I learned the thing above from building it, and I stopped when the case for continuing stopped holding. If I am back on a deck regularly, I expect to want it again — narrower, and pointed at the half that still matters.