What happened
On October 28, 2026, LlamaIndex introduced the Document Parsing Protocol, or DPP. The company describes it as a proposed shared definition of correctly parsed document output: an “answer key” that records both expected output and the reasoning behind difficult structural decisions. Version 0.1 is explicitly a working draft. Its 140 rules cover text, tables, forms, charts, diagrams, and other page elements, with example pages and their expected output.
The immediate problem is that parsers can recognize the same page content while producing materially different structures. LlamaIndex illustrates this with a sales table containing two header rows: years span groups of quarterly columns, and 2023 includes a full-year column. One parser may push quarterly labels into the body, leaving a percentage without its year. Another may retain a value but omit the years, making two “Q2” columns ambiguous. A third may create a synthetic label such as “2024 Q2”; that can make the value usable, but code written for that label can fail when another parser emits “Q2 2024.” DPP treats all of those outputs as incorrect for that page.
For the example, DPP preserves the printed hierarchy with an HTML table, including column spans, because Markdown tables cannot represent headers spanning multiple columns. The result keeps the 4.1% figure under Q2 within the 2024 header. The protocol is therefore not merely asking whether words and numbers were extracted. It specifies how their original relationships should survive the transformation into machine-readable output.
The draft also sets rules beyond tables. An empty form field becomes [blank], distinguishing a blank field from an omitted one; checkboxes remain [x] or [ ]. Charts become tables of printed numbers, with categories as rows and series as columns. Diagrams become diagram code, such as Mermaid, when that code can retain every label and arrow; otherwise, output describes the diagram and retains every label. Text embedded in a PDF but not visible on the page is omitted, while visible but unreadable text is marked [illegible]. On request, output can include each element’s position on the page so a value can be checked against its source.
LlamaIndex says the rules grew from annotation guidance used for ParseBench, its document-parsing benchmark. The protocol also identifies differences it considers equivalent: for instance, wrapping table rows in <thead> and <tbody> is acceptable if information is preserved and one form is used consistently within a document. DPP is available at parseprotocol.com, where pages appear alongside expected output. The company suggests trying it by adding a reference file to ChatGPT or installing a Claude skill with code execution enabled, then attaching a page image and using the supplied prompt. It invites feedback through GitHub issues and pull requests when rules conflict or fail on a document.
What the archive adds
This is a new event on a known LlamaIndex document-parsing thread, not a restatement of its model releases. Earlier coverage included OCRia-1, LlamaIndex’s 4B document-parsing model and its availability through OpenDocRouter. DPP adds a proposed evaluation and representation layer rather than another parser model or distribution channel.
Trend signal
DPP supports the pattern that agent protocols become the interoperability layer. Here the proposed interoperability surface is not a tool-call protocol but a shared contract for parsed document output: systems can only be compared, substituted, or reviewed consistently when they preserve and express structure against common rules. The draft does not establish adoption, so it is evidence of an attempted layer rather than proof of a durable standard.
Why now
LlamaIndex says DPP emerged from the rules its annotators used for ParseBench. Publishing those decisions makes the implicit choices behind benchmark labels inspectable and contestable. The timing also follows recent LlamaIndex parsing work: OCRia-1 was introduced on October 22, while DPP shifts attention from a particular model’s output to the criteria used to judge outputs across parsers.
Connections to other events
The archive’s OCRia-1 notes concerned a parsing model and later access through OpenDocRouter. DPP meets those events at the evaluation boundary: a model can improve recognition scores, but downstream users still need a stable representation of headers, blanks, chart values, and diagram relationships. The related LiteParse gRPC release addressed deployment in typed backend workflows; this draft addresses what such a component should return when a page contains structural ambiguity.
Why it matters
A document agent cannot recover relationships that a parser has discarded without adding another inference step. That is particularly costly in financial tables, forms, and technical documents, where an otherwise correct number can be assigned to the wrong period, category, or field. Teams should therefore distinguish OCR accuracy from structural fidelity when they select a parser or evaluate an extraction pipeline.
DPP offers a possible way to turn that distinction into test cases. A team can take representative pages, state the expected structured output, and decide which variations preserve meaning. Even if it does not adopt DPP wholesale, the protocol’s treatment of blank fields, invisible text, table spans, and positional evidence provides a concrete checklist for acceptance tests. Its open-draft status means it is not yet a substitute for a team’s own document corpus and review process.
What happens next
- DPP will receive contested edge cases and rule revisions through its public feedback process. (3 months, 70%). Watch for: GitHub issues or pull requests that add examples or clarify conflicting rules.
- Parser evaluations will increasingly separate text recognition from structural conformance. (6 months, 60%). Watch for: benchmark or vendor materials that cite DPP-style page-level rules.
Limits and uncertainty
The source is an announcement from LlamaIndex, not independent evidence that other parser vendors, benchmark operators, or customers will adopt DPP. It does not provide conformance results, interoperability commitments, a governance process beyond requests for feedback, or evidence that the 140 rules cover all document types. It also does not establish that HTML, Mermaid, or the specified placeholder tokens are the best representations for every downstream system. The walkthrough via Claude or ChatGPT describes a way to inspect the protocol; it is not a claim that those products natively implement DPP or guarantee compliant output.
Skill to build now
Create a small structural regression set from documents your product already handles: include a multi-row table, an unfilled form, a chart, a diagram, and a page with uncertain text. For each page, write the output relationships that must survive extraction, not only the strings that must appear. Test candidate parsers against those expectations and require source locations for high-impact values. This can reveal whether an agent failure originates in retrieval or in the representation it received.
Reader takeaway
Document parsing is becoming a contract problem as much as a recognition problem. DPP 0.1 is an open attempt to make that contract explicit: not just whether a parser read a page, but whether it retained the structure an agent needs to reason over it. Treat it as a useful evaluation template, not yet as an adopted standard.
Open question
Will independent parser vendors and benchmark maintainers converge on DPP’s rules, or will document workflows continue to require parser-specific normalization layers?