Document AI Glossary: 30 Terms, Defined Plainly

If a vendor doc or a post in the Document AI series uses a word you don't know, it's probably here. The terms are in the order you'd run into them while building: reading the page, turning it into data, checking the data, reviewing it, and paying for it.

Each one gets a short plain definition and a link to the post where it actually matters. Where vendors use a word differently, the entry says so. Terms were checked against the linked docs on September 26, 2026.

Reading the page

OCR

Optical character recognition. It turns a picture of text into actual characters, usually with a box marking where each word or line sat. Classic OCR knows what the characters are but not what they mean, so tables, columns and totals were left to templates and rules. From OCR to vision-language models covers what changed.

Text layer

A PDF made on a computer, rather than scanned, has its text stored inside the file. Reading that stored text is faster and cheaper than OCR, and tools that mix methods use it whenever it's intact. Scans and photos don't have a usable text layer, so they need OCR or a model.

Vision-language model

A vision-language model, or VLM, is an AI model that looks at a page image and writes out the text and its structure directly: headings, the right reading order, tables as HTML. It handles layout far better than OCR. But it writes its output rather than copying it, so it can produce something that looks right and isn't. That risk is why the rest of the series spends so much time on citations, scores and review.

Hybrid pipeline

A setup that uses cheap text extraction where it works, and only calls a VLM for the hard pages or blocks. Marker's fast mode and Extend's auto engine both work this way. It's the practical default described in part 1 of the series.

Layout analysis

The step that finds the different parts of a page, like headings, paragraphs, tables, figures and form fields, and puts them in reading order. Good layout analysis is what stops a two-column page from being read straight across both columns. Datalab in practice shows the kinds of blocks it returns.

Bounding box

The coordinates of an area on the page, usually a rectangle or a shape with four corners. Bounding boxes let a reviewer see exactly where a value came from. Citations are built from them.

Turning pages into data

Parse

Turning a whole document into text and structure, usually markdown or HTML plus labeled blocks with their positions. Parsing copies what's on the page. It doesn't decide what any value means. See parse vs extract vs classify vs split.

Extract

Pulling specific values out of a document into fields you define, returned as JSON. Extraction answers "what's the total due?" while parsing only copies the page. Most vendors parse first and charge for it on top, as the cost post explains.

Classify

Working out what kind of document you have, like an invoice, a receipt or a contract, so it goes to the right extractor. A wrong guess here ruins everything after it, because an invoice read as if it were a contract returns nonsense. It's one of the four steps in part 2.

Split

Finding where one document ends and the next begins inside a single file, like three invoices scanned into one PDF. Datalab calls this segmentation. Without it, fields from different documents can get mixed into one record.

Schema

The list of what to extract: field names, types, descriptions, and which fields are required. It's usually written as JSON Schema. The descriptions matter as much as the names, because the model reads them. Extend in practice walks through one for an invoice.

Citation

A pointer from an extracted value back to where it came from in the document, like a block ID or a bounding box. Datalab returns a list of citations for each field, and Extend can return them if you turn them on. Citations turn review from hunting into confirming, as the review queue post describes.

Processor version

A saved, fixed setup of a parser or extractor that you can lock in, compare against others, and go back to. Versions matter because changing a schema or model changes the results, including for documents you've already processed. How to choose an enterprise document tool explains why locked versions that never change help.

Checking the data

Ground truth

The answer key. It's the values a careful person reads off each document, written in one consistent format for each type. Any accuracy number is only as good as the answer key behind it. Measuring extraction accuracy builds a small one.

Field-level accuracy

Scoring each field on each document separately, instead of giving the whole document one grade. It shows you which fields fail, which is what you need to fix a schema or set a cutoff. The same post has a script that works it out.

Precision

Of the values the extractor gave back, how many were right. As a formula: true positives divided by true positives plus false positives. Low precision means wrong values that look confident, which is the dangerous kind. Google Document AI's evaluation docs use the same definition.

Recall

Of the values that were actually on the documents, how many the extractor got right. As a formula: true positives divided by true positives plus false negatives. Low recall means missing fields, which usually end up in review. A wrong value lowers both precision and recall.

F1 score

One number that combines precision and recall, weighting them equally. (Technically it's their harmonic mean.) It's handy for comparing runs, but it hides which of the two changed. Report precision and recall next to it.

Exact and normalized match

Exact match only counts a value as right if it matches the answer key character for character. Normalized match cleans both up first, for example reading dates the same way or removing currency symbols, and then compares. Which one you pick can move a score by many points, as the scoring example shows, so say which one you used.

Invented value

A value the extractor returned for a field that isn't on the document at all, like a due date it worked out from "Net 30". It counts as a false positive. Vision-language models can make this mistake in a way classic OCR couldn't.

Evaluation set

A fixed set of documents with their answer keys, rerun before every change to the schema, prompt or version. Extend can build one from a batch of documents people have already reviewed. Keep it separate from the documents you tune on, or the score just measures how well the system memorized them.

Business rule validation

Plain checks on the extracted data that don't depend on the model at all. Are the required fields there? Do the line items add up to the subtotal? Is the currency one you accept? These catch the mistakes that actually cost something, and they never drift. The n8n invoice pipeline runs a set of them in one Code node.

Reviewing the data

Confidence score

A number attached to an extracted value that estimates how likely it is to be right. Vendors use different scales. Azure and Extend use 0 to 1, while Datalab's fast-mode scoring and Extend's Review Agent use 1 to 5. Microsoft's confidence docs describe it as an estimated probability, and Extend's docs say a high score doesn't guarantee accuracy.

Confidence threshold

The cutoff score. Anything below it goes to a person instead of straight through. Vendor defaults differ, and even one vendor's own docs can disagree with each other, so set your own from a small trial on documents where you know the answers. The review queue post shows how.

Straight-through processing

Documents that pass every check and reach their destination without a person touching them. The share of documents handled this way is your automation rate. Microsoft's transparency note uses the term when it discusses thresholds.

Exception

A document sent to review because a rule failed, a score came in under the cutoff, or something was missing. The exception rate, the share of documents that end up as exceptions, is the biggest thing driving total cost. The cost post puts a dollar figure on each percentage point of it.

Human in the loop

A setup where people check or fix what the machine produced before anyone uses it. In document AI, that usually means a review queue where a person can approve, correct or reject. The same idea for AI agents is covered in human approval for agents.

Audit sample

A random handful of documents that were approved automatically, checked by a person anyway. It measures the mistakes your review queue never sees. AWS A2I calls this sampling, and Rossum's docs warn that automating nearly everything leaves little human-checked data for the system to learn from. How many you need to check depends on how precise you want the estimate to be, not on how many documents you process.

Paying for it

Per-page pricing

Charging for each page processed, usually quoted per 1,000 pages. Check what counts as a page, and whether parsing and extraction are charged separately. Google's specialized parsers charge per document instead. See the cost post for prices as of September 2026.

Credits

A vendor's own billing unit, turned into dollars at a rate that depends on your plan. Extend charges in credits per page, with different amounts for each step and mode. Always convert to dollars per page before comparing vendors, as Extend vs Datalab vs other parsers does.

To read the series in order, start at Document AI now: from OCR to vision-language models. The post before this one covers document AI cost at scale.