Short answer / The record
A batch record should hold everything needed to check a run without asking anyone: the method version, materials and lots, equipment, the data with calculations fixed, every deviation, override and repeat with its reason, who did each step and when, and the evidence. The signer checks the controls first, then anything that isn't a clean pass.
At 16:40 on 24 September, QA in our example lab signs off a mycoplasma test in which one sample gave no signal at all. That sample is the reason the signature means something.
Under last month's SOP, no signal read as a clean negative. Under this month's, it's invalid, and the record says so in plain sight. I think that's the whole job of a batch record: let the person signing see what actually happened, including the parts nobody wanted. This is what the record should hold before anyone signs it, what the signer should check, and why it can't change afterwards. The example is the test that cleared our example lab's new HEK293 cell bank for use.
What is a batch record?
A batch record is the complete, fixed record of one run, which someone signs to say it's complete and correct. The term comes from manufacturing, where every batch has one. In a research lab it's the final record of an experiment.
The difference from a notebook page is where it comes from. A notebook page is written by the person who did the work, usually afterwards, in their own words. A batch record is assembled from what was actually done and captured during the run. One is someone's account of the work. The other is the work, laid out.
What should it contain?
Enough for a stranger to check the result without asking anyone, which in practice means eight things.
- The method, by version: here workflow "Mycoplasma PCR screen" v3.
- Every step: who did it, when it started and finished.
- The materials and their lots, including the new primer and probe mix, lot
LOT-PP-2609. - The equipment, so a questionable instrument can be traced to every run it touched.
- The data, in the structure it was captured in, with calculated values fixed.
- Every exception: overrides, deviations, repeats and failed attempts, each with its reason.
- The evidence: here, the instrument's amplification plot.
- The sign-offs: the checkpoint during the run and the signature at the end.
Take any one of these away and a question goes unanswered. Lose the lots and you can't answer "was it the reagent?". Lose the method version and you can't say whether the internal control was even in the mix.
The record of the September screen
The experiment is EXP-20260921-001. Its steps run from Monday's feed, through the 72-hour wait (nobody overrode it), to Thursday's plate. The plate-control checkpoint passed at 13:00 and was signed then. The results table was sealed at 13:40:
| Sample | Target Ct | IC Ct | Call |
|---|---|---|---|
| Positive control | 28.1 |
30.2 |
Positive (control passes) |
| No-template control | 40 |
29.0 |
Negative (control passes) |
SMP-0424, HEK293 bank (P5) |
40 |
29.3 |
Negative |
| HEK293, routine | 40 |
29.1 |
Negative |
| CHO-K1 | 40 |
28.8 |
Negative |
| HeLa | 40 |
29.6 |
Negative |
| A549 | 40 |
29.2 |
Negative |
| Jurkat | 40 |
40 |
Invalid |
A Ct of 40 means no amplification, and each row takes the worse of the sample's two wells, never their average. The Call column is a formula, and sealing froze its values, so the record shows what the formula said at 13:40 even if someone edits the table template next month.
What should the signer check first?
The controls, because if they failed, nothing else on the plate means anything. Then every result that isn't a clean pass. Then whether the record is complete.
Here the positive control came up and the no-template control stayed clean. Five samples are negative, and each shows an internal control signal, which is what makes them real negatives.
It's worth a glance at where that signal lands: between 28.8 and 29.6, within a cycle of the no-template control's 29.0. A control that came up several cycles late would mean a struggling reaction, which is why the SOP's cut-off is 32. Jurkat shows nothing in either channel. The signer's question is whether the record treats it honestly: it's reported as invalid, not negative, and a retest at 1:10 is already on the lab's board for Monday.
Signing a record with an invalid sample in it is fine. That's the method working. Signing one that quietly rounds it up to "all negative" is the thing to avoid, and a record assembled from the run makes that a lot harder to do by accident.
Why can't a signed record change?
Because a signature is about specific content. If the content can change after the signature, the signature doesn't mean much.
So CCA Labs fixes the record at two points. In this lab, whose policy turns sealing on, the results table is sealed when it's submitted: the scientist signs it, the calculated values are frozen, the content is hashed and the signature records who authored it.
When QA chooses Finalize & Sign Batch Record, they re-enter their password, the signature is bound to that exact content with the meaning "approved", and an immutable snapshot is stored. The dialog is blunt about it: "This action cannot be undone." The signed record carries a content hash of the whole record, so it's tamper-evident. The electronic signatures are built to support 21 CFR Part 11 controls.
The cost is that the signer has to be right before signing, because there's no quiet fix afterwards. I think that's the correct trade, but it does mean records take a few minutes longer to sign.
Does every record need a signature?
No, and I'd be wary of anyone who says it does. It's the lab's decision, per action. In CCA Labs the Owner turns signatures on or off for each kind of action, from finalising a batch record to passing a QA/QC checkpoint. The GMP preset starts with all of them on, and the R&D preset starts with everything off.
The example lab signs its QC tests, because they release material other people will use. That's probably the one place where even a research lab without a quality system should sign. A bank released on an unsigned test is a bank nobody can vouch for.
What doesn't it do?
It doesn't read the instrument. The Ct values were pasted in from the instrument's export, and the export itself is attached as evidence. It names the workflow version but not the release of the SOP document the step linked, so the SOP version is read from the date: v4, released on 15 September, as long as nobody edited the working copy before the run. There's no separate review-and-approve round before finalising, and no CAPA module for investigations. And finalising needs an Admin or above.
Batch records in CCA Labs
Every experiment has one. It sets out Record Metadata, Execution Steps, Shared Captures, Aggregated Data by Schema (with a workbook download for each table), the Bill of Materials, what the run Produced, Cost per step, Evidence, and a summary from any Pebble sensor watching the equipment. More on how the run gets recorded in the first place is in what an electronic lab notebook should record for each experiment. The rest is on the all-in-one lab page, and you can create your lab to run and sign your own.
The same afternoon, QA records the bank's mycoplasma assay as passed. It was the bank's last outstanding check, so the bank shows as released. In this lab a working bank is released on its viability at freezing and its mycoplasma result; many labs also thaw a vial to check recovery and confirm identity first.
And the run leaves a question: the only invalid well came from the dense suspension culture. One well proves nothing, so it goes to the SOP's owner as something to test before the next release, drafted outside the working copy the bench reads. That's where this story started: how a lab should control its SOP versions. A record is how a method gets better, which is probably the best reason to keep it properly.
The whole story / one floor at a time
One mycoplasma test, from the SOP to the signed record
One routine test, followed through a lab: the monthly mycoplasma PCR that clears the example lab's new HEK293 cell bank. Operations releases a new SOP and builds it into a workflow, the bench plans the week and runs the plate, QA signs the record, and what the run taught goes back into the SOP. Each part is written for the people on that floor.
FAQ / asked about this
Frequently asked questions
- What is the difference between a batch record and a lab notebook entry?
- A notebook entry is usually written by the scientist during or after the work, in their own words. A batch record is the fixed, complete record of one run, assembled from what was actually done and captured, and signed by someone to say it is complete and correct. The term comes from manufacturing, where every batch has one.
- Who should sign a batch record?
- Someone with the authority to accept the result, usually QA or the lab manager, and ideally not the person who did the work. In CCA Labs finalising a batch record needs an Admin or above, and the lab's e-signature policy decides whether it also needs a signature.
- Can you change a batch record after it is signed?
- It should not be possible to edit it in place, because the signature applies to that exact content. In CCA Labs finalising creates an immutable snapshot, the signature is bound to that content, and the experiment is marked completed.