OCR models for forms and handwriting: structured OCR with provenance
None of that tells you the model got the right field. It can read a smudged nine correctly and still staple it to the wrong line, clean throughout. That's the trap. Forms and handwriting mean applications, surveys, checklists, delivery slips, handwritten additions on a printed form: checkboxes, handwriting, a signature standing in for presence, the field-to-value link. Pages fight back: crossed-out text, touching characters, faint pencil, and notes outside their box. A capable model untangles that layout, and just as readily invents language the page never held.
Keep the boring stages doing the boring work
Schema validity gets a document that loads; page, region, raw text, and transformation history make it auditable. Start with template registration, region cropping, printed OCR, and a dedicated handwriting recognizer, and let a generative model in only where it beats those stages: hard handwriting, an irregular layout, a distant label-value link, an exception nothing upstream caught, never by replacing a stage that works.
The test: source coordinates and raw spans returned, cross-field rules validated, a review overlay on anything doubtful, the file immutable, everything logged from source hash to model revision and reviewer change. Never let normalization overwrite transcription: an ambiguous O, zero, I, one, decimal, or unit gets stored both ways.
Score the gate on field association, handwriting transcription, checkbox state, blank detection, and abstention, not prettiness. Error rates weight a missing comma like a wrong account number; add exact-match checks for identifiers and amounts, and score table geometry separately.
A clean-looking answer isn't the same as a right one
The failure worth losing sleep over: a legible handwritten value stapled to the wrong field, or a mark read where none exists. Storing only the corrected value hides it, tidy, and kills verification later. Language models continue plausible patterns, so a damaged surname or total gets completed into something familiar and wrong.
A confidence score is the model's opinion of itself, not a description of the page.
Build an abstention path: a low-resolution crop, glare, unreadable handwriting, or a total that doesn't add up should raise an exception, not a guess. Confidence scores run model-specific and poorly calibrated; pair them with image-quality checks, format validators, and cross-pass disagreement. Store the region beside the value, so a reviewer resolves an uncertain digit in seconds, not minutes.
Used carefully, a vision-language model can associate a distant label, reconstruct a broken table, or explain disagreeing totals, provided it keeps observation separate from interpretation, writes staying behind validation it doesn't control. Printed text in the document is data, not an instruction. Across pages, preserve order, header identity, and table continuity.
Version the model and validation together, and replay a stratified set whenever either changes. Local deployment stays under direct control, cheaper at volume once storage and review are counted; a hosted API buys elasticity and a wider exception ceiling for a price paid in retention and rate limits. Hybrid routing earns its keep when privacy is strict and escalation stays visible.
None of this makes the model honest on its own, and I'd still bet the first exception nobody wrote a rule for slips through as a clean, well-formatted, entirely wrong value.