How should a lab control its SOP versions?

Version 3 of our example lab's mycoplasma SOP has a hole in it. A PCR reaction that fails, from debris in the sample or a culture that's too dense, gives no signal. And no signal is exactly what a clean sample gives.

Version 4 closes the hole with one extra reagent and one extra rule. Writing it takes an afternoon. The rest of the job is SOP version control: getting v4 onto the bench for the next test, keeping v3 readable, and being able to say later which version a result came from. The example is the monthly mycoplasma screen in the lab our home page follows, which this month also clears its new HEK293 cell bank for use.

What does version control mean for an SOP?

It means two kinds of text: one working copy that people edit, and a numbered series of released versions that nobody can change. The lab works to the latest release. Everything else is a draft.

Engineers will recognise this as the revision block on a drawing. Nobody machines a part from a drawing without a revision on it, and a superseded revision gets marked as such, because the part is only right if the drawing was. I've had machined parts come back that didn't fit because I forgot the anodising thickness, so I have some respect for the revision block.

An SOP is the lab's drawing, with one difference that makes it harder. A wrong part doesn't fit. A wrong method usually still produces a result.

What changes from v3 to v4?

Four sections of the SOP change, and every one of them is there to stop a failed test passing for a clean one.

Section	v3	v4
2. Sampling	Spent medium at least 48 hours after the last feed	At least 72 hours, so the organisms have longer to build up
5. Mix	Master mix, primers and probe, water	The primer and probe mix now includes an internal amplification control
6. Run	Target read in FAM	Target in FAM, internal control in HEX
7. Calls	No target signal is negative	No target but internal control present is negative. A late target signal is retested. No signal at all is invalid, and the sample is repeated at 1:10. Each sample is called on its worse well, never an average

The internal control is a piece of DNA that should amplify in every well. If it comes up, the reaction worked, and a missing target signal means something. If it doesn't, the reaction failed, and the well tells you nothing about mycoplasma. The cut-offs are this lab's rule, taken from its kit, not a universal one.

What should a release note say?

A release note should say what changed, why, and what a reviewer should look at. Write it for the person who opens the history in two years, wanting to know why the lab's results changed in September 2026.

The v4 note in the example lab:

Adds an internal amplification control to every reaction, read in HEX. A sample with no target and no internal-control signal is now invalid and is repeated at 1:10, instead of being reported negative. Duplicates are called on their worst well, not averaged, and a late target signal (Ct 35 to 40) is inconclusive and retested. Sampling moves from 48 to 72 hours after the last feed. Sections 2, 5, 6 and 7 changed; the plate controls are unchanged.

That last sentence matters as much as the rest. Saying what didn't change is how a reviewer knows where not to spend an hour.

How do you check a change before releasing it?

You compare the working copy against the last release, line by line, before anyone releases it. Reading the new version on its own isn't enough, because the eye reads what it expects.

The change from 48 to 72 hours is two characters in a paragraph of sampling instructions. It's the change most likely to be missed, and the one that moves the whole week's schedule. In CCA Labs, History has Diff vs working copy: inserted text shows in green, removed text struck through in red. The 48 and the 72 sit next to each other, one red and one green, and they're hard to miss.

How does the bench know which version to use?

The bench should only ever see released text, and every result should name the method version it came from. In practice labs manage the first with printed copies and the second with memory, and both leak.

In CCA Labs a workflow step can link an SOP, and only a released document can be linked. The scientist opens it from the step, read-only. The version that's pinned is the workflow's: an experiment runs from a released workflow version and names it on the record.

Here's where we're not where I'd like to be. The step links the document, not a particular release, and the bench sees the document as it currently stands. That's the working copy. So if someone starts drafting v5 on Wednesday, Thursday's plate can see their draft text. Until we change that, draft big changes in a copy of the document, and release before the edits pile up.

Where it goes wrong

These are the usual ways SOP control fails. None of them are clever.

• Printed copies. A laminated SOP in the tissue culture room outlives three releases. If paper copies exist, they carry their version number, and someone collects them at each release.
• A release with no note. Two years later nobody knows why the method changed, only that it did.
• The SOP changes and the method doesn't. v4 adds a reagent. If the workflow the bench runs isn't updated to match, the new SOP is a document nobody follows.
• Nobody checks it or reads it. A changed test needs one check run before anyone relies on it, and the people running it need to have read the new version. This lab puts both on the checklist of its plate-day card on the Bench Board.
• Editing history. Going back to an old version should be a new release. Restore in CCA Labs copies an old release's text into the working copy, and you release it as the next number, so the history still shows what happened.

SOPs in CCA Labs

SOPs live in Documents, a library of rich-text documents with tags, visibility and archive. Several people can edit the working copy at once. Release records it as the next version, v4 here, and editing carries on in v5. Version numbers are assigned by the system, never typed. History lists every release with its date and release comment, and you can view any old version read-only, compare it with the working copy, or restore it.

Releasing a document needs edit rights, and there's no approval step or signature on it. If your quality system needs a second person to approve an SOP, CCA Labs doesn't enforce that on documents today. The signature sits on the workflow release, when your policy asks for one, because that's the version the bench actually runs. The rest of the operations side is on the all-in-one lab page, and you can create your lab and put your own SOPs in.

An SOP is prose, and prose is easy to skim at nine in the morning. v4's changes have to become things the bench can't skip: a reagent in the mix, a 72-hour wait, a check on the controls before anyone reads a result. That's the next part of the story: how to turn a written protocol into a workflow the bench can run.