Best practices

Reproducibility across labs: why sharing the definition is not the same as sharing the result

Two labs can run the identical liquid class and get different volumes. Here is what a shared definition leaves out, and how to close the gap.

Here is an uncomfortable experiment. Take a liquid class that works perfectly in one lab, send its exact parameters to a second lab running the same model of instrument, and have them run it. Often the delivered volumes do not match. Nothing was copied wrong; both labs are using identical numbers. And yet the result is different, because a liquid class definition is not the whole story of why a transfer comes out the way it does. Reproducibility across labs is not achieved by sharing a definition. It is achieved by sharing a definition and then accounting for everything the definition quietly leaves out.

This matters far beyond tidiness. Multi-site studies, contract labs reporting to a sponsor, and any organization with more than one instrument all depend on a result being a property of the method rather than of the room it ran in. Understanding what the definition omits is the first step to making that true.

What a shared definition does not carry

The parameters in a liquid class describe how the instrument should move liquid. They do not, by themselves, describe the physical reality that surrounds the transfer, and it is that reality that drifts between labs.

  • Ambient conditions: temperature and humidity shift viscosity, density, and evaporation, so the same parameters deliver differently in a cold validation lab and a warm production one.
  • The liquid itself: nominally the same reagent can vary by grade, lot, or age, and a real liquid is not always as reproducible as its name suggests.
  • Tips and consumables: the same nominal tip from a different vendor or lot can shift low-volume behavior enough to break agreement.
  • The instrument as it actually is: two units of the same model differ in wear, calibration state, and service history, so identical commands produce slightly different volumes.

Verification is what turns a copy into a match

Because the definition cannot carry the physical context, the only way to know that a shared class reproduces is to measure it where it lands. A gravimetric check on the receiving instrument turns the question is this the same class into the question does this deliver the same volume, which is the one that actually matters. This is not a lack of trust in the definition; it is an acknowledgement that the definition was always only half the answer. A class that has been verified on both instruments is reproducible between them in a way that a class that was merely copied never is.

Record the context, not just the numbers

When two labs disagree and you have only the parameters, you have nothing to investigate; the numbers are identical, so they explain nothing. The investigation becomes possible only if each lab recorded the context around the class: the temperature it was validated at, the tip lot, the instrument and its service state. With that in hand, a discrepancy usually resolves quickly into a concrete cause, a few degrees of temperature or a different tip, rather than an unfalsifiable suspicion that one lab is doing something wrong. Context is what makes reproducibility debuggable.

Two labs running identical parameters can get different volumes, and both can be right about the numbers. A definition describes intent; only a verified, context-carrying class describes a result you can reproduce.
Piptera

Notes on pipetting calibration, liquid classes, and building an open, vendor-neutral catalog for every liquid handler.

© 2026 Piptera. Built for labs.