Years of paper records, read into data.

1Read the page, and keep the page.

Years of executed batch records, logbooks and forms sit in binders and scans. They hold the history of every lot a site has made, but a question about them means pulling boxes. Neil reads each scanned page into values in Seal: the entry, its row and field on the form, the initials and date beside it, and where on the page it was written.

The scan does not go away. Every value keeps its link to the place on the page it came from, so anyone checking it opens the scan at that line. US rules let records be kept as true copies of the originals,¹ and UK guidance defines a true copy as one verified to carry the same information, context and structure as the original.² Whether a scan stands in for the paper is your quality unit’s decision under your retention procedure. The data read from it is a reading, linked to its source.

2Never rely on one read.

People abstracting values from records by hand get a share of them wrong, and a second person proofreading catches far fewer errors than keying everything twice.³⁴ Leading AI models read handwritten forms better than they did, and still not well enough to rely on alone.⁵ So Neil doesn’t use one read.

On eight synthetic handwritten batch records with known answers, Neil’s first read got 97.2% of 2,219 values right, from 98.9% on clean scans to 94.8% on poor ones.⁶ A handwritten value checked against a limit is then read again from a crop of the scan, however sure the first read was. That left 0.8% of values wrong and unflagged, before anyone had sampled them. All 35 faults planted in those records, from out-of-limit values to corrections with no reason, were read as written.

Each value is checked in code against what the form asks for: its limits, units, dates, sequence and signatures. A value that can’t be found where it is said to be is thrown out. When two reads disagree, nothing is saved until a person has checked the original. A confidence score shows a reviewer where to look first; what goes unchecked is decided by these controls and your own sample.

3Send what can’t be read to a person.

On the test record, the room temperature at step 3.2 on page 9 reads 27 °C to the page reader and 21 °C to a second look at the ink. The limit is 18 to 25 °C, and “Within limit” is ticked Yes. Neil doesn’t pick one. It shows both reads, the same room’s readings elsewhere in the record, and the named reviewer who checks the original.

Reading the whole page also finds what typing values into a spreadsheet passes over: a weight struck through and rewritten with no initials, date or reason beside it, or a printout initialled by its analyst and by no verifier.

Some marks aren’t values at all. Many quality systems ban ditto marks and down arrows outright,⁷ so one shouldn’t pass as a number. In our benchmark Neil named 93 of the 99 marks, with 8 false alarms across the 2,219 values. If your procedure bans them, make that a check.

4Validate it on your own worst pages.

Test the reading the way you would test a new transcriber, for the use you intend. Pick your hardest pages: the worst handwriting, faint copies, crossed-out corrections and pages written over twice. Have your team key a sample by hand the way it would today. Neil reads the same pages, and you compare them value by value, with each difference shown beside the page that settles it.

Count two kinds of miss apart. A wrong value that passed is the one that matters: it’s how a lot that should have stopped gets through. A right value held for a person costs a minute. Split both by writer and by field. On one synthetic record, four writers came in at 99.6% and the fifth at 73.5%, whose initials, OI, were read as 01, and the record’s average still said 96.3%.

Then size the sample for what you need to show. With no misses in a sample, the most you can claim at 95% confidence is about three divided by the number of values checked:⁸ under 10% from 30 values, under 1% from 299, under 0.1% from 2,995. One full batch record can hold thousands of entries, so these numbers are within reach.

From that comparison your quality unit decides what a person verifies, and the closer a value sits to a decision about product, the more it needs. FDA’s draft guidance on AI frames risk the same way: how much the model’s output counts, and what a wrong decision would cost.⁹ A trend across past lots might take a sample. A value behind a batch review check might take a person every time. Keep sampling new records by hand after go-live, and repeat the comparison when the model, the forms or the scanning change. Neil’s part stays the same throughout: it reads and proposes, and people verify and decide. See how Neil fits the EU’s draft Annex 22.

5Use what years of records hold.

Once past lots are data, questions that meant pulling boxes take seconds. Trend a parameter over every lot for continued process verification or a product quality review. Find every earlier time a fault happened, even when it was only ever written on paper. Hold a new site’s first lots against the original site’s history in a tech transfer.

Each new lot can then be reviewed against the ones before it. In batch release, Neil compares a lot with earlier lots on the same line and asks QA about anything outside what they show.

6Start with one binder.

Bring one product’s executed records, or one logbook, and your team’s own transcription of a few of its hardest pages. Compare what Neil reads with what your team keyed, writer by writer, decide what a person verifies, then read the rest of the binder.