Pragmatic AI
Use Case

Turning legacy documents into structured data

Decades of technical records, handwritten and typed, scanned and filmed, converted into a database the people who need them can actually query.

The records exist. They are in filing cabinets, in scanned boxes on a shared drive, on microfilm somebody digitized in 2004. Somewhere in them is the answer to a question your team asks every week.

Nobody looks. Finding one number means a person walking to a cabinet and reading paper for an afternoon, so instead your team works from the last ten years of data that happens to be in a system, and treats the rest as though it does not exist. Decades of expensive fieldwork sitting there, unused.

Why OCR does not solve this

The obvious move is to run everything through OCR and load the text into a database. It is the first thing everyone tries, and it fails in the same places every time.

Handwriting. These records were filled in by hand, by dozens of different people, over decades. OCR was built for typed pages. It returns confident garbage on a field note.

Tables that break across pages. A single record often runs over several sheets. OCR reads one page at a time and has no idea the second page continues the first, so one record becomes three fragments.

Every form is different. The layout changed in 1978, again in 1991, and one regional office always did it their own way. Anything built around fixed field positions breaks on the next box you open.

No sense of what the values mean. OCR gives you characters. It does not know that a number in one column is a depth and the one beside it is a grade, so it cannot catch a reading that is off by a factor of ten.

Damage and degradation. Faded ink, coffee stains, skewed scans, notes written up the margin. A person reads through all of that. Character recognition does not.

What you get back is a pile of text that still needs a person to interpret it. That is the problem you started with.

THE RECORD Handwritten, skewed, running off the page. OCR OUTPUT F1ELD REC0RD N0. 88?3 ,, 19—8 DE?TH GR@DE SAMPL C0MMENT ~~~ ||| l2.4 O.87 A-l ..... 3l.2 1,09 B-2 .... 44,O O.6l C-3 —— 5l.8 O,94 A-4 ... rn1n0r fract vrng · wtr tbl @ 22rn || ——— || \\ ,, .. —— ,, /// c0nt’d 0n ne—— page ends, record continues elsewhere ?? ?? ?? —— ,, .. || ———— ?? .. ,, Characters, columns collapsed, fragments. STRUCTURED OUTPUT FIELDVALUESRC Record no.0000 Year0000 Depth0.0 m Grade0.00 SampleA-0 Water table0.0 m Fields, values, and the page each came from.
Diagram 1. Illustrative. Values are placeholders, not real records.

What works: reading the page, not the characters

Vision models read a page the way a person does. They see the layout, the handwriting, the table structure, and the notes in the margin at the same time, and they interpret them together. A column header two pages back is still context when the model gets to page three.

That changes what is possible. Instead of recognizing characters and hoping the structure survives, the system reads the record, understands what kind of record it is, and pulls out the fields that record type is supposed to have.

Around that sits an agentic pipeline. Different document types get routed to handlers built for them. Records that span pages get assembled before extraction rather than after. Values get checked against what is physically plausible for that field and flagged when they are not. Anything the system is unsure about goes to a person instead of quietly into the database.

1 · Ingest2 · Classify3 · Assemble4 · Extract5 · Validate ScansPDFsPhotosFilm Mixed inputs, one queue Form 1968Form 1978Form 1991 Three pages, one record Fields with source markers Plausible? Complete? Database Review queue Flow runs left to right. Nothing uncertain reaches the database without a person seeing it.
Diagram 2. The pipeline, in the same family as the workflow on the recurring report note.

In practice

A geological exploration company had roughly fifty years of field records across several regions. Handwritten, multiple form generations, varying scan quality, and no consistent index. The historical data was the company's most valuable asset and the least accessible thing it owned.

The system now reads those records and produces a structured database with the source page attached to every value. Geologists query the whole archive instead of the last decade. Data that was effectively lost is in the same tools as everything else.

We built the system, then turned it into a product: LogDog, our drill log digitization product.

LogDog
A Pragmatic AI product

LogDog

AI drill log digitization for mineral exploration.

The exploration version of this problem turned out to be the same in every company that had it, so we packaged it. LogDog is that system sold self serve to geologists. Every other domain is an engagement, which is what the rest of this page describes.

What you get out

The output is a database rather than a text dump.

Every extracted value carries its source, so anyone can check a number against the page it came from in a couple of seconds. Output lands in the formats your existing tools already read, so nobody has to learn a new system to use it. Uncertain values arrive in a review queue rather than silently in a table. And the archive stops being a liability you keep meaning to deal with.

STRUCTURED DATA FIELD VALUE SOURCE Field A0.00 Field B0.00 Field C0.00 0.00 p. 00p. 00p. 00 A value in the database SCANNED PAGE box-014-scan.tif, page 00
Diagram 3. Illustrative. Values are placeholders, not real records.

Whether this fits your archive

The domain above is geology. The shape of the problem is not. Utilities, land records, manufacturing quality files, clinical archives, insurance claims, and municipal permits all have some version of it. Decades of records, filled in by hand, in forms that changed several times, holding information the organization still needs.

If that sounds like what is in your cabinets, the first question is not what technology to use. It is how many document types you actually have and how much of the content is judgment. That is usually a short exercise.

Related
Origin Note Why RAG breaks down at scale Why completeness has to be designed in rather than retrieved. Application Note Automating a recurring report with AI The same review-gate pattern, applied to a recurring deliverable.

Send us a box.

Give us a representative sample of your records and we will show you what comes out. You will know within a week whether this works on your archive.

Get Pragmatic

Common questions

Can OCR do this if we clean up the scans first?

Better scans help OCR read characters. They do not help it understand a table that runs across three pages or a form layout it has never seen. The limitation is not image quality, it is that character recognition has no idea what a record is.

What if our records are handwritten?

That is the normal case. Vision models handle handwriting far better than OCR does, because they read a page in context rather than one character at a time. Hard cases go to the review queue rather than into the database.

How accurate is it?

Accuracy depends on your documents, which is why we run a sample first. The more useful number is how much reaches the review queue, because that is the work left for your people. That number is knowable in a week.

How many document types can it handle?

As many as you have. Each type gets its own handling, so adding a form generation you found in a back office is a small piece of work, not a rebuild.

What format does the data come out in?

Whatever your systems read. The point is that the archive lands in the tools your team already uses, not in a new place they have to go.

Do we have to send you our records?

For a sample, yes, and we can work under whatever agreement your legal team wants. For a full run, the system can be deployed where your data already lives.