Cross-document tag consistency, spatial grounding, fragment-level attestation, and browser-native readability for business documents Balisage: The Markup Conference 2026 August 3-7, 2026 DGML — Document Graph Markup Language — is a semantic XML representation of business documents. Docugami, with Inveniam, is opening the format itself to the industry as a potential standard, with a reference implementation. Where raw extraction gives you fields, and structural markup gives you shape, DGML gives you meaning: tags that describe what each element is in its domain — a liability cap, an effective date, a payment obligation — not how it appeared on the page. DGML's headline property is cross-document tag consistency: a stable vocabulary across every document of a given type, making a corpus queryable without per-document prompt engineering. A four-layer architecture — semantic tagging, spatial grounding via pixel bounding boxes, cryptographic fragment-level attestation, and browser-native readability — makes DGML suitable for enterprise document AI: economical enough for an agent to process, and provable enough for its answer to be trusted. This paper introduces the format, its schema mechanism, and its packaging. Jean Paoli Jean Paoli is CEO of Docugami Inc., which uses AI to transform the unique document business processes of individual companies, making frontline users more efficient while giving leadership better compliance and insight — inspired by his deep belief that openness and interoperability raises all boats. This paper introduces DGML, the semantic XML format underlying Docugami, now being opened to the industry at large as a potential standard, together with a reference open-source implementation, in partnership with Inveniam. He was formerly President of Microsoft Open Technologies, Inc., and one of the co-creators of the XML 1.0 standard with the World Wide Web Consortium (W3C). Earlier in his career he worked at Inria, the French research lab, and at the startups Gipsi S.A. and Grif S.A.; within Microsoft he built four new ventures — XML, InfoPath, the opening of the Office formats, and Microsoft Open Technologies — each built around breakthrough platform technologies used today by millions. He has spent the years since applying those same design principles — separation of meaning from presentation, namespaces, schema-governed vocabularies — to successive generations of document technology, most recently to the problem of making enterprise business documents legible to, and verifiable by, AI systems. CEO Docugami Inc. jeanpa@docugami.com Copyright © 2026 by the author. Used with permission. semantic XML document AI RELAX NG namespaces JSON-LD Open Packaging Conventions Merkle trees blockchain attestation large language models

The XML effort began in 1996 with a specific bet: that separating a document's meaning from its presentation, and letting anyone mint a namespaced vocabulary for their own domain, would outlast any particular application of markup. That bet was formalized two years later in the W3C XML 1.0 Recommendation [], and has paid off for three decades of document interchange, publishing, and data transport. It is being tested again now, in a context the original authors could not have anticipated — large language models reading business documents at scale, and being asked to answer questions whose truth matters: what is the liability cap, when does the lease terminate, has this clause been amended. There is something genuinely moving in watching this happen. XML was never a modest effort: a broad community of implementers and researchers designed it as a general, extensible way to carry structured meaning between systems, languages, and organizations that would otherwise never agree on a common format. That it turns out, decades later, to be exactly the right answer to one of the defining problems of the AI era — how to let meaning survive the journey from a human-authored document into a machine's hands, intact and provable — is not luck. It is XML doing, at a scale nobody anticipated, precisely what it was designed to do all along. The markup community has spent decades developing the theory and practice of semantic XML: namespaces, schema languages, typed values, linking, provenance. This paper describes DGML (Document Graph Markup Language), a direct application of that intellectual heritage to one of the more consequential problems of the current moment: making business documents legible to AI systems without sacrificing verifiability. Docugami, in partnership with Inveniam, is not merely open-sourcing an implementation: it is opening the format itself to the industry at large, for development as a potential standard, together with a reference open-source implementation. Both are introduced publicly for the first time in this paper. XML was designed to separate meaning from presentation. DGML applies that principle at the corpus level: instead of tagging one document, it defines a stable semantic vocabulary — a docset — shared by every document of a given type. A <docset:LiabilityCap> means exactly the same thing across every Master Services Agreement in a corpus. This is not a new idea; it is the original promise of XML namespaces, applied at industrial scale to unstructured enterprise content, at a moment when the audience for a document is as often a model as a person.

Everyone is currently figuring out how to feed AI agents business documents they can actually understand. Doing that well raises two separate questions, and existing formats answer neither: can the agent afford to process the document, and can the agent trust what it read. The first is a problem of tokens. The second is a problem of proof.

Every token sent to a language model costs money, consumes context, and dilutes the model's attention. Three obvious candidates for representing a business document to an LLM each have a structural problem in that economy.

Markdown and raw OCR text force the model to re-discover structure on every call. A model reading flattened text is reading to find connections rather than traversing them, and cannot natively express the relationships inside a long business document without the representation becoming unreadable. Structure that was implicit in the original — the containment of a liability cap inside an indemnification clause, the linkage of a payment term to an effective date — has to be reconstructed by the model from scratch, on every call, at the model's expense.

Feeding a model the source PDF or a page image burns the full document into every call with no structural leverage at all. To answer a question about one clause, the model must process the entire contract, every time the question is asked.

Structural markup — XHTML-like formats that replace visual layout with generic structural tags such as section, table, and li — is a genuine step up. It gives a model a navigable tree instead of a flat stream. But the tags describe shape, not meaning. A section containing a liability cap and a section containing a payment schedule are structurally identical; the model still has to read and interpret the content to determine what it is looking at. There is no stable vocabulary to query across documents, and no typed values — every amount, date, or identifier remains buried in text that must be re-parsed on every query.

The token problem is the half of this story the field already discusses. The other half goes largely unaddressed: once an agent is not merely reading a document but acting on it — approving a payment, certifying compliance, computing a net asset value from a thousand underlying leases — the fragment the agent consumed becomes evidence, and someone downstream will eventually ask not whether the file was authentic, but whether this specific clause, this specific number, was exactly what the source said. Existing attestation practice does not answer that question at the granularity agents operate at. A signed PDF, a notarized file, a blockchain hash of a whole document all certify the file as a unit — sufficient to prove a document has not been altered since it was filed, useless for proving that the $500,000 figure an agent extracted from page 14 is the same $500,000 figure that was in the signed original. Agents read and cite fragments, not files; a certification scheme pitched at the file level protects a boundary the agent never touches. DGML sets out to close both gaps with one architecture: a format economical enough to feed a model, and provable enough — down to a single data element — that an agent's fragment can be trusted without producing, or even seeing, the rest of the document it came from.

A DGML document is a well-formed XML file. Every element belongs to a namespace that identifies who defined it and what it means. Two namespaces are foundational: Prefix URI Purpose dg: http://dgml.io/ns/dg# Core structural elements and cross-document infrastructure attributes defined by the specification docset: http://www.dgml.io/{org}/{docset-name}# Semantic vocabulary defined by an organization for one document type Because XML namespaces are globally unique and decentralized, any organization can define its own docset: namespace, and a DGML document can mix elements from multiple namespaces without collision — enabling fragments from different organizations, different docsets, or different time periods to compose into a single document. DGML carries no visual or layout semantics of its own: there is no bold or indent element. A <docset:PaymentTerms> describes what the text is in the domain of the document, not how it happened to be rendered.

A docset is a named collection of documents of the same type produced by a specific organization — all Master Services Agreements issued by one counterparty, or all invoices from one supplier. The docset defines the tag vocabulary: which element names exist, what they mean, and how they relate to one another. Documents belong in the same docset when they serve the same functional purpose and share 70–80% of their semantic fields with consistent meaning; they are split into separate docsets when field semantics diverge, issuing organizations differ, or a document type has changed enough over time that old and new versions can no longer be compared field-by-field.

Only elements that carry a genuine domain concept receive a semantic tag. Every other structural role — headings, lists, list items, table cells, enumerators, an inline run with no resolved concept — is emitted as the generic dg:chunk element, with its visual role recorded in a dg:structure attribute (section, header, p, ol, li, table, tr, td, and two DGML-specific values, lim for a verbatim enumerator and span for an unresolved inline run). This is the defining rule of DGML element naming: a wrong semantic tag is worse than an honest dg:chunk. dg:chunk also serves as the document root. A representative fragment from a Master Services Agreement: <dg:chunk xmlns:dg="http://dgml.io/ns/dg#" xmlns:docset="http://www.dgml.io/acme-corp/master-services-agreements#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <docset:IndemnificationClause> <docset:IndemnifyingParty dg:origin="2 460 310 1800 355">Vendor</docset:IndemnifyingParty> <docset:LiabilityCap xsi:type="decimal" dg:value="500000" dg:origin="2 460 410 1800 455">$500,000</docset:LiabilityCap> <docset:EffectiveDate xsi:type="date" dg:value="2024-01-01" dg:origin="2 998 710 1466 755">January 1, 2024</docset:EffectiveDate> </docset:IndemnificationClause> </dg:chunk> Note the typed value convention: xsi:type carries a standard XSD type name, dg:value carries the canonical machine-readable form, and the element's text content preserves the display form exactly as it appeared in the source. An agent can query docset:LiabilityCap/@dg:value across a thousand contracts using identical logic — that cross-document consistency, not any single document's tagging, is DGML's headline property.

Stripped to its smallest form, a DGML document is a namespaced element tree with typed values and a semantic link — nothing more is required for a file to be valid DGML: <dg:chunk xmlns:dg="http://dgml.io/ns/dg#" xmlns:docset="http://www.dgml.io/acme-corp/master-services-agreements#"> <docset:VendorName xml:id="vendor">MagicSoft, Inc.</docset:VendorName> <docset:IndemnificationClause> <docset:LiabilityCap xsi:type="decimal" dg:value="500000">$500,000</docset:LiabilityCap> </docset:IndemnificationClause> <docset:SignatoryName dg:itemprop="signatoryOf" dg:href="#vendor">Jane Smith</docset:SignatoryName> </dg:chunk> Everything else in this paper — pixel provenance, attestation, browser rendering, graph export — is additive: attributes and packaging that layer onto this same tree as the documents, and the stakes, get real.

The tag machinery described so far — namespaced elements, a docset-level vocabulary, typed values — is not, on its own, new. What is new is who is capable of authoring and applying it. Building a semantic vocabulary for a document type, and then tagging a corpus against it, has traditionally depended on a human information architect to design the tag set and a human cataloguer — or a team of them — to apply it document by document. That work is careful and often excellent, but it does not scale with the number of document types or the number of documents an organization holds, and that cost is a large part of why semantic markup has stayed confined to well-funded corpora rather than becoming the default representation of business documents at large. What has changed is that a model can now do this first-pass work itself. Given a set of documents, a model can group them into docsets — clustering documents that share a functional purpose and a common set of semantic fields — read a representative sample of each, and surface the concepts that actually recur across it: the parties, dates, amounts, and clauses that make up the document type's real structure, as distinct from its visual layout. From that reading, the model drafts the docset's schema.rnc () and tags documents against it directly, producing the vocabulary and the tagged XML together, at a scale no team of human information architects and catalogers could match. A schema drafted this way can stand on its own. DGML also leaves room for people to tweak it when they want to: it can be annotated with ## Prompt: comments to tell a model where a field typically appears, or how a computed value is derived — a lightweight refinement, not a required step. The reference implementation released alongside this paper runs that workflow end to end: point it at a folder of source PDFs and it groups them into docsets, drafts schema.rnc from what it reads across the corpus, and tags the documents — applying dg:origin, xsi:type/dg:value, and dg:itemprop/dg:href as it goes — largely without a person in the loop at either step. That a model can discover a corpus's semantic structure and produce both the schema and the tagged XML at scale, with a working implementation to show for it, is the claim this paper makes — not that namespaces or typed values themselves are new.

What DGML gives an agent is four complementary layers that no flat format — and no purely structural markup — can replicate together. Each layer can be stripped or kept independently: one self-contained file serves an LLM call, a browser view, and a compliance audit trail.

Consistent tags across similar documents let an agent reason over a corpus without per-document prompt engineering. Each tag groups many surface tokens into a single named concept, and any XML element subtree can be sent to a model in isolation to focus its attention precisely — a single clause instead of an entire contract.

Every element may carry a dg:origin attribute recording where its content can be found in the rendered source page images: dg:origin="<page> <x1> <y1> <x2> <y2>" Coordinates are 1-based page numbers and pixel offsets in raster space (origin top-left, y increasing downward), matching a page_images/page_N.png rendered at a declared DPI. Multiple boxes, separated by semicolons, express a value spanning lines or pages. On a leaf element dg:origin pins one value; on a parent it spans the full extent of the subtree, so a viewer can highlight an entire clause as well as a single field. A reserved value, dg:origin="computed", marks a field whose value is derived from other elements rather than read directly from the page; such a field always pairs with dg:itemprop/dg:href pointing to its sources. Extracted values are consequently not floating assertions — each can be shown to a human as a highlighted rectangle on the original document. This is the difference between an answer and a verifiable answer. Stripping dg:origin before a model call — it exists for grounding, not reasoning — is itself a further 20–40% token reduction.

The deeper novelty for this audience is fragment-level attestation. The conventional blockchain use case hashes an entire document and anchors that single hash on-chain as proof of origin for the whole file. DGML goes further: because the semantic tree is structured, any XML element subtree — a single data point, a payment term, a liability cap — can be hashed and anchored independently, proving that specific data artifact's origin without producing the entire document. An element stake commits to a single XML element together with an inclusion proof tying it to the document root without revealing any other element. The element's canonical hash is checksum = SHA-256( exclusive_C14N(element) ) using Exclusive Canonical XML 1.0 so that the hash is independent of inherited namespace context: the same element hashes identically whether staked standalone or inside a full document. The proof itself is a standard binary Merkle audit path in the sense of RFC 6962 [] — the same construction used by Certificate Transparency logs — carrying a leaf hash, a 0-based DFS pre-order leaf index, the total leaf count, and an ordered list of sibling hashes: candidate = SHA-256( exclusive_C14N(element) ) if candidate != proof.leaf_hash: return False # the element itself changed current = candidate for step in proof.path: current = SHA-256( step.sibling + current ) if step.side == "L" SHA-256( current + step.sibling ) if step.side == "R" return current == root_hash A failed verification distinguishes two cases cleanly: if the re-hashed element differs from proof.leaf_hash, the element itself changed; if the element hash matches but the path fails to reconstruct root_hash, the tree around it changed. Only O(log N) sibling hashes are needed, so the full document is never stored or transmitted to verify one fragment. File-level anchoring composes with element-level anchoring rather than duplicating it: a file stake hashes four independent slots — the source bytes, each rendered page image, the RELAX NG schema, and the DGML XML itself — into one RFC 6962 Merkle root using the same construction as element staking, so a file-level record and an element-level record drawn from the same document are cryptographically consistent by construction, not by convention.

A DGML file is readable in any browser with no special viewer. Some elements — not every element — carry a dg:structure attribute recording a structural role drawn from a small, closed vocabulary (section, p, table, span, and a handful of others — no arbitrary HTML), and an optional dg:style attribute — a semicolon-separated list of standard CSS declarations, emitted only when the styling is visually evident in the source — copies verbatim into an HTML style attribute. Neither aims at full-fidelity reproduction of the original layout: the goal is a document a person can open, read, and understand, not a pixel-perfect facsimile of the source. A few lines of transform are enough to render a DGML document as a readable web page with no knowledge of the docset schema required, and combined with dg:origin a viewer can also overlay an element's bounding box on the original page image.

The XML hierarchy captures containment: sections contain clauses, clauses contain values. Named links across elements capture relationships that containment cannot — an amendment points to the clause it modifies, a receipt points to the obligation it fulfills. Any element can express such a relationship using two attributes borrowed respectively from XHTML Microdata and from XHTML/JSON-LD linking: <docset:VendorName xml:id="vendor-co">MagicSoft, Inc.</docset:VendorName> <docset:SignatoryName dg:itemprop="signatoryOf" dg:href="#vendor-co">Jane Smith</docset:SignatoryName> The subject is the element carrying the attributes, identified by its xml:id; the predicate is the dg:itemprop value; the object is the element identified by dg:href — #id for a same-file reference, or fileid#id for a cross-file reference stable across renames. Hierarchy plus links form a graph derived mechanically from the XML, with a defined lossless JSON-LD export (following the XAST convention []) so that a collection of DGML files in a docset is directly traversable by any standard JSON-LD processor [] — the XML remains ground truth; the JSON-LD is derived from it, never the reverse.

A docset's vocabulary is formally defined in RELAX NG Compact Syntax []. For a new docset, schema.rnc is not hand-authored: it is derived automatically, by a model reading a representative sample of the corpus and naming the concepts that recur across it. It is revised only when a later document introduces a concept genuinely absent from the existing schema — schema drift, not stabilizing a vocabulary once a docset exists, destroys the cross-document queryability that is DGML's central value, so an existing docset's schema is treated as a contract, not a suggestion. namespace docset = "http://www.dgml.io/acme-corp/master-services-agreements#" ## Agreed maximum liability exposure under the contract ## Example: $500,000 ## Prompt: Look for the dollar amount following "liability" or "not exceed" ## in the indemnification section LiabilityCap = element docset:LiabilityCap { (text | AnyTag)* } The ## Prompt: annotation carries meaning beyond bare RELAX NG: it guides an LLM to a field's location in a document, or, for a computed field, states its derivation rule. A schema, together with these prompt annotations, is sufficient for an LLM to both discover a document's fit within an existing docset and drive targeted, user-directed extraction into the same tag vocabulary used for full-document tagging — one schema, one vocabulary, driving three distinct output shapes: full document tree, extraction only, or both together under a single root.

DGMLX (.dgmlx) is the packaging format: a self-contained ZIP archive, structured according to the Open Packaging Conventions [] (the same container convention underlying the Office Open XML formats), bundling the original source document, its page images rendered at a declared DPI, the DGML XML, the docset's schema.rnc, OPC content-type and relationship declarations, and an attestation document: [Content_Types].xml _rels/.rels META-INF/dgml-attestation.xml schema.rnc <Document Title>.dgml.xml source/<Document Title>.<ext> page_images/page_1.png page_images/page_2.png ... The attestation document carries the package's Merkle root over its constituent artifacts, the DPI and renderer used to produce the page images, and permanent file and docset identifiers: <dgml-attestation xmlns="http://dgml.io/ns/attestation" version="1" page-image-dpi="150" page-image-renderer="ghostscript" file-id="5kqt9r5fowno" docset-id="o8vr8rs488vg"> <merkle-root>62f7a978b4b1b3f1eaf400514070e827873bed8b4fb4279bb4d6e7288f79df8e</merkle-root> </dgml-attestation> Where a package is one link in a provenance chain — an amended lease, a restated agreement — its attestation links back to its predecessor, so a chain of document versions is verifiable end to end without any party needing to trust an intermediary's record-keeping. No document content ever goes on-chain: only hashes, a dgmlx:// locator, and a small metadata blob are anchored, leaving the source documents themselves wherever confidentiality requires.

A one-page summary of the mechanisms covered above, for reference.

TermMeaning dg:Core structure and infrastructure attributes docset:Semantic vocabulary defined per organization and docset dg:chunkGeneric structural primitive; also the document root

AttributeCarries dg:structureVisual role (section, p, table, td, lim, …) dg:originPixel bounding box on the source page dg:value / xsi:typeCanonical machine-readable value dg:itemprop / dg:hrefNamed semantic link

LayerMechanism SemanticConsistent tags; one vocabulary per docset Spatialdg:origin, pixel-traced to source AttestationMerkle proof, at the element or the file level ReadableRenders in any browser, no viewer required

TermMeaning DocsetSame-type documents sharing one schema schema.rncDerived automatically by a model reading the corpus .dgmlxOPC ZIP: source, page images, XML, schema, attestation

DGML is being announced publicly for the first time as an open specification [] and open-source toolkit, released under the Apache 2.0 license with an explicit patent grant and no copyleft dependencies anywhere in the reference toolchain. Docugami is releasing it in partnership with Inveniam, whose CEO Patrick O'Meara has worked with Docugami on a shared premise: that a decentralized system of trust for business document data needs a semantic format underneath it, not just a ledger on top of one. The initiative has also been joined by John Patrick Mullin, whose work in blockchain infrastructure is central to the fragment-level attestation chain described in . The goal is a reference implementation and a vetted open specification developed with the community, governed eventually by a steering committee open to any organization with a real stake in the outcome. For the Balisage audience specifically, DGML is offered as a case study in applying XML's core design commitments — namespaces, schema-governed vocabularies, typed values, linking — to the constraints of the token economy. Every artifact in the stack is a standard already familiar to this community: RELAX NG for schema, OPC for packaging, JSON-LD for graph export, standard XSD types for typed values, and RFC 6962-style Merkle proofs for attestation. Nothing in the stack is proprietary, and nothing about applying these standards to a new problem required inventing new ones.

The problem DGML addresses — making enterprise documents legible to AI systems without giving up verifiability — is new. The tools it uses to address that problem are not: namespaced vocabularies, schema-governed typed values, mechanical graph derivation, and standard container formats are the markup community's oldest and best-tested instruments. Thirty years after that XML effort set out to separate meaning from presentation, that same separation — applied at corpus scale, with a cryptographic notion of proof attached to every fragment — turns out to be exactly what the current moment in document AI needs.

The examples throughout this paper each isolate one mechanism at a time. This appendix puts them together in a single fragment — a piece of a Master Services Agreement — carrying every concept discussed: namespaces, concept-driven semantic tags, generic dg:chunk scaffolding with dg:structure and dg:style, typed values, single- and multi-box dg:origin, and a semantic link. <dg:chunk xmlns:dg="http://dgml.io/ns/dg#" xmlns:docset="http://www.dgml.io/acme-corp/master-services-agreements#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <docset:VendorName xml:id="vendor" dg:origin="1 220 150 680 200">MagicSoft, Inc.</docset:VendorName> <docset:IndemnificationClause dg:structure="section" dg:origin="2 180 400 2360 1200"> <dg:chunk dg:structure="header" dg:style="font-weight: bold"> <dg:chunk dg:structure="lim">3.1</dg:chunk>Indemnification</dg:chunk> <docset:LiabilityCap xsi:type="decimal" dg:value="500000" dg:origin="2 460 410 1800 455">$500,000</docset:LiabilityCap> <docset:EffectiveDate xsi:type="date" dg:value="2024-01-01" dg:origin="2 998 710 1466 755">January 1, 2024</docset:EffectiveDate> </docset:IndemnificationClause> <docset:ConfidentialityObligation dg:origin="3 209 710 2341 755; 3 209 760 2341 805"> Each party shall hold the other's information in strict confidence. </docset:ConfidentialityObligation> <docset:SignatoryName dg:itemprop="signatoryOf" dg:href="#vendor" dg:origin="11 460 2430 1200 2475">Jane Smith</docset:SignatoryName> </dg:chunk> Every mechanism from this paper is present and locatable: docset: tags name what things are; dg:chunk with dg:structure="lim" carries the enumerator; dg:style reproduces the observed bold heading; xsi:type/ dg:value normalize the cap and the date; dg:origin traces every value to its page and spans two lines for the confidentiality clause; and dg:itemprop/ dg:href link the signatory to the vendor she signed for. Bray, Tim, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, eds. Extensible Markup Language (XML) 1.0. W3C Recommendation, 10 February 1998. https://www.w3.org/TR/1998/REC-xml-19980210. Clark, James, Makoto Murata, eds. RELAX NG Compact Syntax. OASIS Committee Specification, 3 December 2002. https://www.oasis-open.org/committees/relax-ng/compact-20021121.html. ECMA International. Open Packaging Conventions. ECMA-376, Part 2: Open Packaging Conventions (OPC). https://ecma-international.org/publications-and-standards/standards/ecma-376/. Sporny, Manu, Dave Longley, Gregg Kellogg, Markus Lanthaler, Pierre-Antoine Champin, Niklas Lindström, eds. JSON-LD 1.1. W3C Recommendation, 16 July 2020. https://www.w3.org/TR/json-ld11/. Laurie, Ben, Adam Langley, Emilia Kasper. Certificate Transparency. RFC 6962, Internet Engineering Task Force, June 2013. https://www.rfc-editor.org/rfc/rfc6962. Wooldridge, Titus, et al. xast — XML Abstract Syntax Tree. The unified collective. https://github.com/syntax-tree/xast. DGML Format Specification, Version 0.7. Docugami Inc. and Inveniam, 2026. https://github.com/dgml-io/dgml-spec.