Bench scanner or camera
A fixed camera or a sheet-fed scanner at the bench. The slip is captured the moment it is torn off; nobody opens a file.
Captured at the bench, read into the record, sent on. A person approves what ships.
A bench instrument measures the sample and prints the result on a strip of thermal paper. That is where the data stops: nothing can be released until the values are in the lab record - the LIMS, the ELN or the quality system. And the paper itself fades, while a GxP record has to stay readable for years.
Reading an instrument printout into a record is not a new idea. Instrument interfaces, scan-to-LIMS tools and middleware have done pieces of it for years. AI Intime is one way to do it - built for labs that need it to run inside their own boundary, to read any printout from any instrument, and to keep a person in charge of what is recorded.
Capture is the easy half. What matters is what happens between the capture and the record.
A fixed camera or a sheet-fed scanner at the bench. The slip is captured the moment it is torn off; nobody opens a file.
Point AI Intime at the folder your scanners already drop into. New files are picked up as they land.
Slips photographed on a phone and sent to a lab mailbox arrive in the hub by themselves.
If your scans already live in a SharePoint library, the connector indexes it and keeps it in sync.
If the instrument can export over USB, serial or the network, we take the file. If it can only print, we read the print.
Approved values do not sit in AI Intime. They go out, through the same connectors the platform uses everywhere else.
LIMS, ELN or your quality system - the system your release process reads today. AI Intime writes to it through an interface adapter; nothing is replaced.
Every approved result streams to your warehouse or lakehouse for trending, control charts and audits, with the slip image reference beside it.
The slip image and its approved values are filed to the library your QA already audits from, as the true copy.
An exception that needs a decision, or a batch whose results are all in, posts to the channel or inbox that owns it.
A REST endpoint and an MCP tool layer for the systems we have not named.
On the platform todaySharePoint · Outlook · Teams · database change-data capture (PostgreSQL, MySQL, SQL Server, MongoDB) · REST upload API · MCP tool layer
Tap a card to read it. One at a time.
Scanner, folder, mailbox or library - the slip reaches the hub without anyone opening a file. Capture is the easy half; what matters is what happens between the capture and the record.
Sample, parameter, result, units, time, instrument and operator - read from the printout into fields your record already has, each one linked to its place on the slip image.
Thermal print fades and a 3 can look like an 8. A doubtful digit is marked for a person to decide, beside the slip, rather than guessed.
Who captured the slip, who changed which value, who approved. The trail is kept with the record, not in someone's memory.
Thermal paper fades; the record has to last. The slip image is filed with the result as a true copy, so the paper no longer has to be photocopied to survive.
Different instruments print different slips. Each layout is learned once, reviewed by a person, and held for every future printout from that model.
Approved values go to the LIMS, the warehouse and the SharePoint library through the same connectors the platform uses everywhere else - not into another database beside them.
Lab data is regulated and confidential. AI Intime runs inside your own infrastructure - on your site, or fully air-gapped - with the connectors running there too.
The AI model is a part you can swap. Change providers, go self-hosted, or move when a regulator says so - your capture keeps working exactly as before.
Extraction is automatic; judgment is not - "Human in Loop" is our design philosophy, and in a GxP lab it is also the second check.
The slip is captured at the bench - from the scanner, the folder, the mailbox or the library.
The instrument layout is recognised and every field on the slip is read into the record.
Anything faint or doubtful is flagged beside its spot on the slip.
Check the flagged values against the slip; correct, then approve. That is the second check.
Approved values post to the LIMS and stream to the warehouse; the slip image is filed to SharePoint as the true copy.
Direct interfaces cover the instruments that have them. We read the paper from the ones that do not, and the same review screen covers both.
On-prem or air-gapped, with the connectors to your LIMS, warehouse and SharePoint running there too. Nothing goes to a cloud OCR service.
The analyst's review beside the slip is the second check your procedure already asks for, with who-changed-what kept with the result.
Entirely inside your infrastructure - on your site, or fully air-gapped. The slips are your batch records - they never leave your boundary, and neither do the LIMS, the warehouse or the SharePoint library they feed. And it is LLM-agnostic: the models sit behind the platform, replaceable without touching the capture or the connectors.
Bring a handful of slips - as they came off the instrument, faded ones included - and watch the values land in your record with the analyst's review in the loop. Tell us where the values need to go, and we will show that too. No form, no gate.
On-prem. Your data never leaves your boundary.