{"id":"document-extraction-validation","name":"Document fields become validated records","shortName":"Document fields become validated records","role":"Document layout, transcription/extraction, schema normalization, confidence and cross-field constraints.","description":"Document understanding connects image or text representations to structured fields. An OCR pipeline can introduce transcription errors before a field extractor reasons about layout; an OCR-free model instead learns a route from document images to a structured output representation. Either route can produce plausible fields that are wrong. A schema checks names and types, while cross-field constraints check relationships such as quantities, unit prices and totals. Confidence and review thresholds decide how uncertain output is handled, but high confidence is not an independent truth label. Donut is a primary example of OCR-free document modeling. This lesson uses authored invoice fields to expose the validation boundary; it does not run Donut, an OCR engine or an actual extraction model.","mechanism":["The document and its version are preserved as the evidence from which fields are extracted.","The extractor returns named fields with explicit units and provenance rather than an unstructured assertion of success.","Schema and cross-field constraints detect inconsistent records before downstream actions.","Independent labeled documents evaluate field accuracy and review decisions, including mistakes that still pass arithmetic checks."],"learningObjective":"Distinguish extraction, field typing, arithmetic consistency and source-correctness checks for document records.","engineeringExample":"An authored invoice has two units at 1,250 cents and three units at 400 cents. The subtotal is 2×1,250 + 3×400 = 3,700 cents. A transcription that turns 1,250 into 12,500 creates a subtotal of 26,200 cents, inconsistent with a separately read total of 3,700. Arithmetic validation catches that case. If both the price and total are incorrectly changed consistently, the arithmetic can pass while the document is still misread, so source comparison remains necessary. Integer cents avoid introducing binary floating-point rounding into this exact fixture.","misconception":"A schema-valid and arithmetically consistent record can still misrepresent its source document.","check":{"question":"An extractor changes both a price and total consistently but disagrees with the image. Is arithmetic validation sufficient?","options":["Yes, totals prove the text is correct","No, independent source/field comparison is still needed","Yes, if confidence exceeds a threshold"],"answer":1,"explanation":"Consistency constrains relationships between fields; it does not prove that those fields were read correctly."},"checks":[],"prerequisites":["evaluation","tool-contracts-schemas"],"related":["tool-loop","evaluation"],"specs":[{"label":"Mechanism boundary","value":"Why can accurate-looking text still create a wrong record?","context":"Synthetic invoice; nonnegative integer quantities and exact integer-cent prices. Tax, currency conversion, discounts and rounding policies are outside the example."},{"label":"Evidence type","value":"Authored worked example","context":"Worked explanation with a bounded numeric or state example. This lesson does not claim an executing implementation of an external model or platform."}],"interfaces":[{"name":"Declared input and state","direction":"in","signal":"The document and its version are preserved as the evidence from which fields are extracted."},{"name":"Checked outcome","direction":"out","signal":"Distinguish extraction, field typing, arithmetic consistency and source-correctness checks for document records."}],"tradeoff":"Automatic validation can reduce review load while still missing mutually consistent errors or unusual document conventions.","whyAI":"Documents often trigger external actions, making extraction evidence and validation as important as fluent interpretation.","sourceIds":["automation-donut"],"sources":[{"title":"OCR-free Document Understanding Transformer","url":"https://arxiv.org/abs/2111.15664v5"}],"science":[{"title":"Document fields become validated records · explicit relationship","equation":"The exact subtotal in this fixture sums quantity times unit price across line items.","explanation":"An authored invoice has two units at 1,250 cents and three units at 400 cents. The subtotal is 2×1,250 + 3×400 = 3,700 cents. A transcription that turns 1,250 into 12,500 creates a subtotal of 26,200 cents, inconsistent with a separately read total of 3,700. Arithmetic validation catches that case. If both the price and total are incorrectly changed consistently, the arithmetic can pass while the document is still misread, so source comparison remains necessary. Integer cents avoid introducing binary floating-point rounding into this exact fixture.","assumptions":"Synthetic invoice; nonnegative integer quantities and exact integer-cent prices. Tax, currency conversion, discounts and rounding policies are outside the example."}],"evidenceNotes":"This is a worked explanation, not an executing external platform, model or robot. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. Synthetic invoice; nonnegative integer quantities and exact integer-cent prices. Tax, currency conversion, discounts and rounding policies are outside the example.","level":"model","branch":"Models become evaluated applications","subbranch":"Document fields become validated records","scale":"Logical state, task evidence and declared units; no physical assembly scale","kind":"system","workstream":"W11","visualFamily":"software-flow","labId":"library","labScope":"The worked example explains this mechanism. General numerical labs are a reference; they do not execute this lesson’s full mechanism.","history":[],"workedTrace":{"quantities":[2,3],"pricesCents":[1250,400],"totalCents":3700,"misreadPricesCents":[12500,400],"misreadTotalCents":26200}}