The parsed document

​

Overview

A parsed document is a set of pages, each holding its elements in reading order. Each element is one piece of content the pipeline recovered, carrying what it is, what it says, where it sits, and how certain the extraction is. Some elements carry more: a table carries its grid, a chart carries its data and its recognized labels. The renderings you can request are different views of this one model, so understanding the model explains all of them at once. This page describes the model conceptually. For the exact field names and types, see the output schema, and for the full set of content types, see element types.

​

Elements are typed content

The pipeline classifies every region of a page and turns it into a typed element. The type is what lets user code treat content by its role rather than by its appearance: pull the headings to build an outline, keep the tables for data, route charts to a chart handler, drop page headers and footers from a body-text index. The roles range across text, tables, figures, and page furniture, each cataloged in element types. A heading also carries a level from 1 to 6, derived from the document’s own typography by clustering font sizes and weights. This level records the section hierarchy the document expressed through its layout, so the nesting of sections within sections survives into the output. An outline built from the headings and their levels reconstructs the document’s structure without a separate pass.

​

Different elements carry different content

What an element carries depends on its type. Most elements hold their content as text, and those whose content has an internal structure, such as a table’s grid or a chart’s series, carry that structure as well. Text-bearing elements hold their content as a string. A paragraph holds its prose, a formula holds its mathematical notation, a seal holds its recognized text, a code block holds its code. Tables hold a grid. A table element carries a set of cells and the grid’s dimensions, and each cell knows its row and column position and can span more than one row or column. This grid form is what lets a program read a table by coordinate, addressing the value at a given row and column, rather than reconstructing structure from the spacing of rendered text. Extracting tables works through reading this grid in code. Charts hold data and recognized labels. A chart element can carry the series digitized from its geometry and reconciled with vision model values, and separately the individual text labels recovered from the chart, each with its own position and a note of whether it came from the document’s text or from OCR. Extracting chart data covers reading these.

​

Every element knows where it came from

Each element carries a bounding box locating it on the page that holds it. This provenance is what connects extracted content back to the source. A value pulled from a table can be traced to the region it was read from, a passage can be highlighted on a rendered page, and a reviewer can see a low-confidence extraction in its original context. Chart data carries provenance too, with each point and each recognized label holding its own position. Position also underlies reading order. The pipeline uses each region’s geometry to sequence the elements the way a person reads the page, so the element list arrives already ordered rather than sorted by raw coordinates. The order is part of the model.

​

Confidence travels with the content

Each element carries a confidence score, and the document carries an overall summary of scores. These express how certain the extraction is, and they vary with the source: a clean digital table scores higher than a scanned one, and text recovered by OCR scores lower than text read from the document’s own text layer. Because the score sits on the element, a downstream step can act at the level of a single table or paragraph, flagging and responding to what needs review while trusting the rest. Confidence is the hook for a human-in-the-loop step over parsed output, and it connects to Meibel’s broader confidence scoring.

​

One model, several renderings

Each rendering carries this same model, and they differ in how much of it they keep. Markdown keeps what a reader or a language model needs, rendering elements as text and leaving out positions and scores. The structured result keeps all of it, exposing elements with their labels, cells, chart data, boxes, and scores. Annotated Markdown sits between the two, holding the readable text with each piece’s position attached. Because all three come from one parse they agree with each other, so the choice comes down to how much of the model the consumer needs. Choosing an output format matches each one to its job.

​

Related concepts