Every automated liquid handler faces the same problem a bench scientist solves by feel: water, glycerol, and a detergent-laden buffer do not behave the same way in a tip. A liquid class is how that intuition is written down so a robot can reproduce it. It is a named, reusable set of parameters that governs exactly how an instrument aspirates and dispenses one kind of liquid.
Get the liquid class right and a protocol delivers accurate, precise volumes run after run. Get it wrong and you see the familiar failure modes: short volumes from a viscous reagent, droplets clinging to the tip, foaming, or carryover that quietly corrupts a downstream assay.
What lives inside a liquid class
The exact fields vary by vendor, but the concepts are shared across Hamilton, Tecan, Opentrons, and the rest. A typical liquid class describes:
- Aspiration and dispense flow rates, in microliters per second.
- Air gaps: a leading or trailing pocket of air that keeps liquid off the tip opening and clears the last drop.
- Blowout volume, which pushes the final residual out of the tip on dispense.
- Over-aspiration (excess volume) that compensates for liquid retained in the tip.
- Settling and delay times that let a viscous or volatile liquid finish moving before the tip lifts.
- Tip-touch and tip-submersion behavior that controls where in the well the tip sits.
These parameters are not independent. A high viscosity liquid needs a slower flow rate and a longer settling time; a volatile solvent needs air gaps sized to stop dripping. Tuning one in isolation usually just moves the error somewhere else.
Why one liquid class rarely transfers cleanly
A liquid class is tied to more than the liquid. It assumes a specific tip geometry, a specific volume range, and a specific instrument. The parameters that dispense 5 microliters of DMSO accurately on one deck can be meaningfully off on another with different tips. This is why a shared, versioned catalog beats a folder of spreadsheets: you can see the exact context a class was validated in before you trust it.
A liquid class is community-contributed knowledge, not a guarantee. Treat any class you adopt as a strong starting point, then validate it on your own hardware, liquids, and labware.