There is a moment that separates a casual lab from a governed one: someone wants to change a calibration that has already produced results people trust, and the lab has to decide whether that is a two-minute edit or a reviewed, approved, documented event. In any setting where the data matters, it is the second. Change control is the discipline of treating a change to a validated thing as a decision with consequences, made on purpose and recorded, rather than a tweak that happens because someone had a better idea on a Tuesday.
This is a sane change-control flow for liquid classes, written for the reality that most changes are legitimate and useful. The aim is not to make change hard but to make it visible and reversible, so that improving a class never quietly invalidates the results that came before it.
Why a calibration is not a document you just edit
A liquid class sits underneath data. If a class delivered the samples that produced last month's reported results, then editing that class in place rewrites the meaning of those results after the fact: the report now cites a method that no longer exists in the form that produced it. That is the specific harm change control exists to prevent. The fix is conceptually simple. You never change a published class in place; you create a new version, and the old one survives, still attached to the data it produced.
The steps of a change
A workable flow has a small number of stages, each of which leaves a trace. The weight of each stage should scale with the risk of the change, but the shape stays the same.
- Propose: state what you want to change and why, in concrete terms. A better flow rate for a viscous reagent is a proposal; make it better is not.
- Assess the impact: decide what the change touches. Does it affect volumes already reported? Does it require requalification? Does another method depend on this class?
- Verify: show that the new version actually delivers, gravimetrically or by your accepted method, before it becomes the one people use.
- Approve: have someone with the authority to do so sign off, as a distinct act from having made the change, so no one both writes and blesses their own edit unchecked.
- Release and record: publish the new version, keep the old one, and make sure the audit trail shows who changed what, when, and why.
Separation of duties and the approval itself
The single most valuable rule in change control is that the person who makes a change is not automatically the person who approves it. This separation is not an insult to the author; it is a second pair of eyes on something that affects other people's results. The approval should be bound to the specific version, so that approved means this exact set of parameters was blessed, not this class in general. An approval that floats free of a version is worth very little the moment the parameters move.
When a change forces a requalification
Not every change is equal. Correcting a typo in a description is not the same as altering a flow rate that changes delivered volume. Part of impact assessment is deciding whether the change reaches into territory that was formally qualified, and if it does, whether the relevant performance qualification has to be repeated before the new version can be used for reported work. Building that question into the flow is what stops a well-meaning improvement from quietly stepping outside the boundary of what was validated.
Change control is not about preventing change. It is about making sure that when a calibration changes, the results it already produced still mean what they said, and the new version earned its place before anyone relied on it.