Semantic XML
for the Age of
Document AI

1996

Separate meaning from presentation.
Let anyone name their own vocabulary.

That was the bet behind the XML effort we started in 1996.

There is something genuinely moving in watching this happen: a format that was never a modest effort, applied at a scale nobody anticipated, turns out to be exactly the right answer to one of the defining problems of the AI era.

Now

The audience for a document
is now, as often as not, a model.

What is the liability cap. When does the lease terminate. Has this clause been amended.

These are not retrieval questions — they are questions whose answers carry consequences. An enterprise cannot afford a hallucinated liability cap, or an unverifiable termination date.

Two Questions

Everyone is currently figuring out
how to feed AI agents documents
they can actually understand.

Can the agent afford to process it. Can the agent trust what it read.

The first is a problem of tokens. The second is a problem of proof. Existing formats answer neither.

The Token Problem

Three obvious ways to hand a document
to a model. Three failures.

Failure 1

A model reading flattened text is reading to find connections, not to traverse them.

The containment of a liability cap inside an indemnification clause, the linkage of a payment term to an effective date — structure that was implicit in the source has to be reconstructed by the model from scratch, on every call.

Failure 2

To answer a question about one clause, the model reprocesses the entire contract. Every time.

Raw PDF or page-image input gives a model no structural leverage whatsoever — every query pays the full cost of the whole document.

Failure 3

Shape is not meaning.

<section> Liability shall not exceed $500,000 </section>
<section> Invoices are due Net 30 </section>
// structurally identical. semantically opposite.

A <section> holding a liability cap and one holding a payment schedule are indistinguishable to the model. No stable vocabulary to query across documents, and no typed values.

The Trust Problem

Once an agent acts on a document,
the fragment it read becomes evidence.

Approving a payment. Certifying compliance. Computing a net asset value from a thousand underlying leases.

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.

The Trust Problem — cont'd

A signed PDF proves the file.
It proves nothing about the number on page 14.

Agents read and cite fragments, not files — a certification scheme pitched at the file level protects a boundary the agent never touches.

DGML closes both gaps with one architecture: economical enough to feed a model, and provable enough — down to a single data element — to trust without producing the rest of the document it came from.

Overview

Opening the AI black box:
documents in, a trusted subtree out.

PDF source files are grouped into a docset — Docset Master Service Agreement, Docset Invoices; a DGML Process (using an LLM) creates the docsets, tags them, and builds a DGML tree rooted at dg:chunk, at least four layers deep; one subtree — a clause and its typed children — is hashed and anchored on a chain, NVNM Chain for example; an AI Agent (also LLM-based) reads the anchored hash and the subtree itself before trusting either.

Namespaces & Docsets

Same tag. Same meaning. Every document.

A docset is a named collection of same-type documents sharing one schema. An agent that can query one contract's LiabilityCap can query the same element across a thousand contracts — identical logic, no per-document prompt engineering.

The Naming Rule

Only real concepts get a semantic tag.
Everything else is an honest dg:chunk.

Headings, lists, cells, enumerators, an inline run with no resolved concept — all fall back to the generic structural element, with its visual role recorded separately.

A wrong semantic tag is worse than an honest dg:chunk. dg:chunk is also the document root.

Hello, DGML

The smallest complete document.
Root to close.

<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>

A namespaced element tree, a typed value, a semantic link. Nothing more is required to be valid DGML — everything else in this talk is what you add as the documents get real.

Authored by Models

Building a vocabulary, then tagging
a corpus by hand, doesn't scale.

Traditionally: a human information architect designs the tag set; a human cataloguer — or a team of them — tags documents one at a time.

What has changed: a model can now group documents into docsets, read across a corpus, and surface the concepts that actually recur — the parties, dates, amounts, and clauses that make up a document type's real structure.

Authored by Models — cont'd

One model, one pass: schema and
tagged XML together, at scale.

folder of source PDFs
  → group into docsets
  → draft schema.rnc
  → tag the corpus

A schema drafted this way can stand on its own. ## Prompt: comments remain available for people who want to tweak it — a lightweight refinement, not a required step.

The Architecture

Four layers. One file.
Strip what you don't need.

Layer 01

Semantic

Each tag groups many surface tokens into one named concept.

Any XML subtree can be sent to a model in isolation — a single clause instead of an entire contract — to focus its attention precisely.

Layer 02

Spatial

dg:origin="2 460 410 1800 455"
// page 2 · x1 460 · y1 410 · x2 1800 · y2 455

An extracted value is not a floating assertion — it can be shown to a human as a highlighted rectangle on the original page. Strip it before the model call; keep it in the file for grounding. A further 20–40% token reduction.

Layer 03

Attestation — Proof of Origin at
the data-element level.

The conventional blockchain use case hashes a whole document. DGML goes further: any element subtree — a liability cap, a payment term — can be hashed and anchored independently.

checksum = SHA-256( exclusive_C14N(element) )

Verification is an RFC 6962 audit path — the same construction as Certificate Transparency: only O(log N) sibling hashes are needed to prove one element unchanged, without producing the rest of the file.

Layer 04

Readable

Some elements carry dg:structure — a role from a small, closed vocabulary: section, p, table, span, and a handful of others. dg:style carries only what's visually evident in the source, verbatim into CSS.

Neither aims at full-fidelity reproduction — the goal is readable, not pixel-perfect. A few lines of transform render any DGML document as a readable web page, no knowledge of the docset schema required.

A Tree and a Graph

Containment is the tree.
Relationships are the graph.

<docset:SignatoryName
    dg:itemprop="signatoryOf" dg:href="#vendor-co">Jane Smith</docset:SignatoryName>

Subject, predicate, object — borrowed from XHTML Microdata and JSON-LD. Hierarchy plus links form a graph derived mechanically from the XML; the XML stays ground truth, the JSON-LD is always derived, never the reverse.

Putting It All Together

One document. Every concept.

<dg:chunk xmlns:dg="..." xmlns:docset="...">
  <docset:VendorName xml:id="vendor" dg:origin="1 220 150 680 200">MagicSoft, Inc.</docset:VendorName>
  <docset:IndemnificationClause dg:structure="section">
    <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">... in strict confidence.</docset:ConfidentialityObligation>
  <docset:SignatoryName dg:itemprop="signatoryOf" dg:href="#vendor">Jane Smith</docset:SignatoryName>
</dg:chunk>

Namespaces, dg:chunk scaffolding, dg:structure, dg:style, typed values, single- and multi-box dg:origin, and a semantic link — one fragment, every mechanism.

Schema

One schema. Derived automatically,
not hand-authored.

## Agreed maximum liability exposure under the contract
## Prompt: the dollar amount following "liability" or "not exceed"
LiabilityCap =
  element docset:LiabilityCap {
    (text | AnyTag)*
  }

For a new docset, schema.rnc is derived by a model reading a representative sample of the corpus and naming the concepts that recur across it. The schema can stand on its own; ## Prompt: comments remain available for people who want to tweak it — a lightweight refinement, not a required step.

Packaging — DGMLX

One self-contained package.
Open Packaging Conventions.

One-Page Summary

DGML at a Glance

Announced Today

Opening the format itself —
not just an implementation.

Docugami, in partnership with Inveniam (CEO Patrick O'Meara) and joined by John Patrick Mullin in blockchain infrastructure — a decentralized system of trust for business document data.

DGML is being opened to the industry at large as a potential standard, alongside a reference open-source implementation, under Apache 2.0 — governed eventually by a steering committee open to any organization with a real stake in the outcome.

30 Years On

The same separation of meaning
from presentation — applied at corpus
scale, with proof attached to every fragment.

That turns out to be exactly what this moment in document AI needs.