Most labs store liquid classes the way they store everything else: as files on a shared drive, or as settings buried inside a single instrument. It works until someone changes a flow rate to fix one protocol and every other method that relied on that class quietly shifts. Nobody notices until a result looks wrong weeks later, and by then there is no record of what changed or why.
The cost of undocumented change
Automated liquid handling promises reproducibility, but a parameter set with no history offers none. If you cannot answer which version of a class produced a given plate, you cannot defend the result, reproduce it, or roll it back. This is the reproducibility gap that undermines otherwise well-run automation.
What versioning gives you
- A complete history: every parameter change is recorded with who made it and when.
- The ability to pin a method to an exact version, so a validated protocol never shifts underneath you.
- A diff between versions, so you can see precisely which flow rate or delay changed.
- Rollback, so a regression is a one-click fix rather than an archaeology project.
Provenance is the other half
Version history tells you how a class changed. Provenance tells you where it came from and in what context it was validated: which instrument, which tips, which volume range, which liquid. Together they let a colleague, an auditor, or a future you judge whether a class is safe to adopt without rerunning every experiment.
A liquid class you cannot trace is a liquid class you cannot trust. Treat provenance as part of the data, not metadata you fill in later.