Tagging Unstructured Documents for AI: Four Levels of Richness

Somewhere in your company there is a folder of contracts, filings, manuals, or clinical reports that an AI agent is now expected to read. The documents have not changed. What changed is the reader. A person opening a PDF supplies the context themselves: they know which counterparty this is, which product line the table describes, which version of the policy is in force. An agent has none of that unless someone put it there. Putting it there is document tagging, and in 2026 it has gone from a records-management chore to the thing that decides whether an agent can be trusted with your content.

This guide covers the four levels of richness in document extraction: what each produces, what it cannot do, what it costs at ten million pages, how to stop paying a frontier model to reread every page forever, and how the four run on Fluree AI as one pipeline that learns from your reviewers.

What does document tagging mean for AI?

Tagging a document for AI means attaching machine-readable meaning to it so that a system can find it, trust it, and act on it, with a record of where that meaning came from.

This is not tagging in the PDF accessibility sense, where a tag tree tells a screen reader which text is a heading. It is labeling a document with the people, organizations, products, topics, dates, and relationships it contains, in a vocabulary your organization controls, so that search, retrieval, and agents can use it. Analysts call it intelligent document processing, developers call it extraction, and records people call it metadata tagging. The work underneath is one pipeline, and the useful question is how rich the output needs to be for the job.

Why is document tagging back on the agenda?

Because the consumer of the tags is now an agent that reads them directly and acts on the result, and most of the content agents need is unstructured and untagged.

The volume was never the news. Gartner’s Mark Beyer put the unstructured share of enterprise data at 70 to 90 percent at the Gartner Data & Analytics Summit in London in May 2026, and every version of that figure over the past decade has said roughly the same thing. What is new is who needs it and what happens when it is wrong.

• Content is the bottleneck for agents. In the 2026 Box and Harris Poll survey of 1,640 IT decision-makers, 96 percent said agents need company-specific content to be useful, and only 36 percent had connected agents to trusted internal content across multiple uses.
• Tagging is the hardest part of AI data preparation. In Komprise’s 2026 State of Unstructured Data Management survey of 300 enterprise storage leaders, classifying and tagging unstructured data was the top challenge in preparing it for AI, named by 56 percent, up from 41 percent the year before.
• Untagged data sinks projects. Gartner predicted in February 2025 that organizations would abandon 60 percent of AI projects unsupported by AI-ready data through 2026, and in June 2025 that 60 percent of data governance teams would prioritize governance of unstructured data by 2027 specifically to deliver generative AI use cases.

There is a cost warning in the same research. At the Sydney summit in June 2026, Gartner’s Jason Medd predicted that through 2028, teams building their own unstructured metadata solutions would incur costs more than 300 percent higher than if they used existing document and records solutions, skills, and practices. The vocabulary, review discipline, and provenance habits your records team already has are assets, and a pipeline that discards them costs more than one that reuses them.

What are the four levels of richness?

Each level adds a different kind of meaning, answers a different question, and has a different cost profile. They are additive, not alternatives.

The ordering matters. Embeddings are only as good as the chunks, chunks are only as good as the parse, and ontology-guided extraction is only as reliable as the identities it is asked to reconcile against.

Level 1: What does a vision model give you?

A faithful reading of the page, including the parts a text extractor cannot see, and the position of every element so that later tags can point back to it.

This is the level most teams underestimate, because it looks solved. A July 2026 analysis from Unsiloed described why it is not: a vision model downscales every page to a fixed resolution, so dense small print loses detail before the model starts reading, and the result is plausible-looking wrong values with nothing to flag which ones to distrust. As Cohere’s Nils Reimers put it when Cohere shipped its own document model, the hard part is not reading text, it is preserving structure and meaning.

The position we take at Fluree, and the way our document parser is built, is structure first and models second. A deterministic engine reads the PDF’s geometry, outline, fonts, and rules, and infers sections, headings, lists, and tables with no model at all. It escalates to a vision model only for the specific pages, regions, or tables it measured as unreadable: pixels where text should be, broken font encodings, or a table whose detected structure disagrees with itself. There is no quality dial. Escalation is earned per region, and the model’s reading is arbitrated against what the deterministic pass found rather than trusted outright.

Two consequences matter for tagging. Position survives: every element carries character offsets and, for PDFs, a page index and bounding box, so a tag applied later can point at the exact paragraph or cell it came from. And the model cannot invent: the parser’s instruction to its vision model is never to infer, compute, complete, or correct a value. On the public opendataloader-bench corpus of 200 PDFs, measured in August 2026, the deterministic engine alone scored 0.892 with no model, and the cascade with vision escalation scored 0.933, first among the 17 engines scored. The benchmark has no scanned PDFs, so treat it as a measure of layout fidelity, not of OCR.

What Level 1 cannot do is tell you what the document is about. It gives you a reliable substrate, which is why “just send the PDF to the LLM” is the most expensive way to get a worse Level 1.

Level 2: What do vector embeddings give you?

Retrieval by similarity: the ability to find passages that resemble a question, which is useful and is also the level most often mistaken for understanding.

Embeddings turn each chunk of a document into a vector so a question can be matched to passages by meaning rather than keyword. This is where most retrieval-augmented generation pipelines stop, and its limits are well documented. Anthropic’s contextual retrieval work showed that a chunk reading “the company’s revenue grew by 3% over the previous quarter” is unusable once separated from which company and which quarter, and that adding document context to each chunk and pairing vectors with lexical search cut top-20 retrieval failures by 49 percent. Google DeepMind’s 2025 paper on the theoretical limitations of embedding-based retrieval showed that for any embedding dimension there are combinations of documents no single query vector can return.

In Fluree’s pipeline, Level 2 inherits Level 1. Chunks are cut along the document’s structure rather than at a character count and carry their section path, a table cell is embedded with its headers, search is hybrid by default, and the vectors are stored in the graph as a property of the chunk.

What Level 2 cannot do is answer a completeness question. “Everything we know about this counterparty” is not a similarity query, and top-k retrieval has no way to know that a clause on page 41 is about the same entity as the definition on page 2. That is a matter of identity, and identity is what the next two levels supply. As we put it in Multimodal GraphRAG, a shared embedding space retrieves resemblance, not membership.

Level 3: What does simple entity extraction give you?

Every mention of a thing you already know, linked to the identifier it already has, at no token cost.

This is the level where document tagging in the records-management sense happens, and it is deliberately not AI. The input is a vocabulary you already own: a SKOS taxonomy of topics, a list of counterparties, a product catalog, an identity graph of customers. Every label of every concept goes into a dictionary, the document text is scanned for whole-word matches with case folding and stemming, and each hit becomes a mention that points at the concept’s existing IRI. The document ledger and the vocabulary ledger meet on the same node, and a query across both is a plain join.

Fluree AI’s Entities outcome runs exactly this scan, badged “No AI, fast,” against your vocabulary, your identity graph, and optionally a public pack of roughly 1.5 million entities derived from YAGO and Wikidata, with a rules tier that normalizes dates, quantities, and money. The Auto-Categorization outcome adds the taxonomy roll-up: a document that mentions “Apollo 11” is also tagged with Lunar Missions and Space Exploration if the taxonomy links them, with direct matches and rolled-up topics scored separately, so a consumer can tell “this document is about technology” from “this document says the word technology thirteen times.”

This is the level that carried our largest tagging deployment. A global financial services firm publishes investment research through a data portal, and manual, inconsistent tagging was dragging down relevance across nearly half a million documents and emails. Fluree replaced it with tagging controlled by one reference graph of the firm’s ontology, topical taxonomies, and named-entity datasets, applied in the publishing chain with disambiguation and relevance scoring, plus continuous discovery that surfaced new topics and fed them back into the model. The knowledge base grew tenfold and portal users went back to trusting the tags. The durable asset was the governed vocabulary, not a model.

Two properties make Level 3 the right foundation. Known things stay known: a mention is written under the entity’s existing IRI, nothing is copied or re-minted, so tags from documents join to CRM records and product masters without a mapping step. And the vocabulary is the model: when a reviewer marks a missed entity, the surface form is written into the vocabulary as an alternate or hidden label with a change note, and the next run finds it everywhere.

What Level 3 cannot do is handle ambiguity or novelty. “Apollo” might be a mission, a theater, or a project codename, and a name the vocabulary has never seen is invisible to it. Fluree AI handles the first with a linking cascade that commits confident, uncontested matches and escalates anything with competing candidates rather than silently committing it. The second problem is what Level 4 is for. Governing the vocabulary itself is the subject of our guide to controlling LLMs with enterprise taxonomies and of Fluree ITM.

Level 4: What does ontology-based extraction with a gazetteer give you?

Typed entities and typed relationships the document states, in your ontology’s classes and properties, resolved to the identities Level 3 found, with every claim carrying its evidence.

This is the richest level and the only one that uses a generative model to read the document. It is also where most pipelines go wrong, because they hand the model a blank page and accept whatever comes back. The fix the research community has converged on is schema-constrained extraction, where the prompt carries the allowed classes, predicates, and cardinality rules, as in the LREC 2026 schema-constrained evaluation framework and OntoMetric, plus explicit entity clustering, because raw LLM extraction duplicates entities freely. Fluree combines three ideas.

The ontology is the prompt. The model is given your ontology’s classes and properties as its system prompt and told to use only those. A predicate spelled loosely is repaired to the one property it can only mean; a predicate that matches nothing is recorded as rejected and never becomes an edge.

The gazetteer grounds it. The entities Level 3 found in the chunk are passed to the model as existing entities, and it is told to use exactly those names, so its output reconciles to the same IRIs. An entity nobody knows is minted once, and on the next run it is part of the gazetteer. The model can add to your graph, but it cannot rename or invent your vocabulary.

Every claim is gated and kept with its evidence. An entity whose excerpt cannot be found in the chunk is a hallucination and is dropped, along with any relation naming it. A new entity whose class is not in the ontology is flagged off-model. Every relation is stored with its subject, predicate, object, the exact excerpt that justified it, a verdict of valid, repaired, or rejected, and the document it came from. The documentation says what a direct edge means in plain words: what a document stated, not what is true.

In Fluree AI’s hosted pipeline, Level 4 continues into entity resolution and relevance scoring, and reviewers adjudicate relations in the Annotations view, including nearby pairs the extractor made no claim about, which is how missed relations get measured at all. This is the level that lets an agent answer “which of our suppliers has an obligation under this clause?” rather than “which passages resemble the word obligation.” It is also the level whose cost scales with document size.

What does each level cost at ten million pages?

Levels 1 through 3 are flat per document. Level 4 is metered per token. The economics of a pipeline are decided by how much text reaches the language model, and how often.

The per-page numbers are public. Anthropic’s documentation puts a PDF page at 1,500 to 3,000 text tokens plus image tokens, and Unsiloed’s mid-2026 measurements of a typical single-page extraction give the per-page prices below. Specialist document models such as Cohere’s Parse 5 and AWS Textract text detection sit an order of magnitude lower. Deterministic parsing costs compute only; Fluree’s parser reports about 8 milliseconds per document on a CPU. Here is that arithmetic for ten million pages read once, our calculations from the cited unit prices, excluding review and engineering time.

The first pass is not the problem. The problem is the word “once.” Tagging pipelines are rerun when the taxonomy gains a concept, a prompt is improved, a model is swapped, or a synced folder changes, and a pipeline that sends every page to a frontier model pays the full figure every time. As one comparison of parsing services put it, a price that is acceptable for 10,000 pages is prohibitive for 10 million. The design rule is simple: the cheapest tier that can decide honestly should decide, and the model should read only what the cheaper tiers could not settle.

How do you stop paying tokens on every document?

By letting review verdicts teach a small model and grow the vocabulary, so the language model is asked fewer questions each run, and by never re-asking a question whose answer has not changed.

The industry is converging on a pattern: use the large model to label and to handle exceptions, and let something small and cheap handle the bulk. One practitioner case from 2026 used a large model to annotate 900,000 headlines for about $70, then ran a fine-tuned small encoder at roughly $0.10 per hour with slightly higher F1 than the teacher. Fluree AI implements the pattern as a learning loop that lives inside the graph with the data it corrects. It is worth being precise about what learns, because “train the model” can mean many things.

• A trained ranker on your verdicts. Every linking decision records the candidates shown, the tier that decided, and its confidence. Reviewers confirm, correct, or reject in the Annotations view, and from at least four usable verdicts the Training tab fits a small listwise ranker, a linear model over the deterministic candidate features that trains on a CPU in milliseconds. It decides only what the deterministic tier escalated, at no AI cost, so it cannot regress the easy bulk. A fifth of your documents are held out so the benchmark measures generalization.
• Every “no” becomes a standing caution. Once a reviewer rejects a surface, later runs still detect it but must escalate it, so the same false match can never be silently re-committed.
• Recall grows through the vocabulary, not the weights. A missed entity a reviewer marks is written into the vocabulary itself. Documents also teach their own abbreviations: once “Brightwater Development Corp (BDC)” is seen, a bare “BDC” in any later document of the corpus resolves to it, always verified.
• Arbitrations are remembered. A rerun that reaches the AI arbiter with a question a prior run already answered replays the earlier verdict at no cost. Any change to the candidates, the vocabulary, or the arbiter reopens the question.
• Unchanged work is never redone. Parses are cached against the file’s exact bytes, a rerun after a vocabulary edit skips every document the edit cannot touch, and a rerun whose questions are all settled completes at zero metered cost.

We do not publish a single savings percentage, because the number depends on your corpus, your vocabulary, and how much reviewing you do. The shape of the curve is that each later run hands fewer questions to the arbiter, and the measurement to watch is the one the Training tab gives you: a gold set frozen after an adjudication pass and each run’s benchmark score against it.

Where should the tags live?

In a graph, attached to their evidence, under the same identifiers as the rest of your data, with a history that can be replayed and a policy that can be enforced.

Most extraction tools stop at a JSON file per document. That is fine for a one-time migration and wrong for tags an agent will act on. Forrester’s June 2026 state of agentic AI report put the bar plainly: every autonomous action has to be logged and defensible to an auditor, and the EU AI Act’s Article 12 record-keeping obligations for high-risk systems applied from August 2026. A tag with no source, no extractor, and no timestamp meets neither.

In Fluree, every mention carries its offsets, its source element with page and box, the document it came from, and whether the gazetteer or a language model produced it. Every relation carries its excerpt and verdict. A reingested document’s prior extraction is retracted and replaced, and the previous state remains queryable at its commit, so an agent’s answer can be replayed under the tags in force when it was given. And because extracted entities and relations are ordinary triples in FlureeDB, the policy engine that governs structured data governs them too. A tag in a graph inherits the governance of the thing it points to; a tag in a column does not.

A government biodiversity department is the clearest example we have of why that matters. Thirty years of species records lived in Oracle, Access, and spreadsheets, and the most valuable evidence lived outside them: camera-trap images, bioacoustic recordings, scanned PDFs, and field reports that no analytics or AI could see. Fluree extracted species, locations, dates, and relationships from that content into the same governed graph as six million structured records, under a taxonomy versioned in Fluree ITM with a full audit history. The policy consequence is the point: precise coordinates for protected species are obscured in public contexts and preserved for authorized staff, and that rule applies to a location extracted from a scanned report exactly as it applies to one in a database row. More than 60 downstream applications and a natural-language GraphRAG interface now read from that one graph.

The practical shape of all this is a query like the one below, which joins a ledger of people to a ledger of memos on shared identifiers, with the excerpt and file for every hit.

PREFIX doc: <https://ns.flur.ee/doc#>
PREFIX nif: <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#>
PREFIX schema: <https://schema.org/>

SELECT ?person ?email ?file ?excerpt
FROM <people:main>
FROM <memos:main>
WHERE {
  ?person a schema:Person ; schema:email ?email .
  ?m nif:entity ?person ; nif:anchorOf ?excerpt ; doc:sourceDocument ?d .
  ?d doc:relativePath ?file .
}

Separately, or together on Fluree AI?

You can run any of the four levels on its own with tools you already have. Fluree AI runs all four as one pipeline against one graph, and it is the only one of the two paths with the learning loop.

There are good standalone options at every level, from document parsers such as Docling, Reducto, and Cohere Parse to GLiNER or spaCy for generic entity types and a structured-output call to any frontier model for a version of Level 4. What you assemble yourself is four outputs in four formats with no shared identity, no shared provenance, and no feedback between them. The tag a reviewer corrects in one tool does not teach the others.

On Fluree AI, the four levels map to four outcomes in the Map to Knowledge Graph panel, and you pick outcomes rather than pipelines.

Everything lands in one graph, and the Training tab holds the verdicts, the ranker, the cautions, and the gold benchmark. Sign up at fluree.ai to run it on a folder of your own documents, or read the Fluree AI overview. The same parser and extraction prompt ship in the FlureeDB command line for offline and bring-your-own-model work, documented at Fluree Unstructured; the review loop is a hosted feature today. For enterprise deployments with content-system connectors, Fluree’s unstructured data product packages the pipeline with Fluree ITM for the vocabulary and FlureeDB for the graph.

What should you build first?

Start at Level 3 with a vocabulary you already govern, add Level 4 for one document type, and review before you scale.

1. Pick one corpus and one vocabulary you already own. A supplier list, a product taxonomy, a policy glossary. Run Semantic Search and Entities against it. You will have a searchable, tagged graph with no token spend and a clear picture of what the vocabulary misses.
2. Teach the vocabulary from the misses. Mark missed entities for a few dozen documents. Resist the urge to reach for a model to fix recall that a label would fix.
3. Add Entities & Relationships for one document type. Ground it in the ontology you have, even if it is small. The off-model entities and rejected relations tell you what the ontology is missing, which is a modeling decision, not a prompt decision. If that question is open for you, our guide to one ontology or many gives the six tests to apply.
4. Review, freeze a gold set, and train. Adjudicate a sample, freeze the gold set, train the ranker, and check the held-out numbers before activating it. Then rerun and watch which decisions the arbiter no longer sees.
5. Wire an agent to the graph, not to the documents. Give it queries over entities, relations, and provenance rather than a pile of chunks. This is where the enterprise AI context layer gets its unstructured half.

The two deployments above are this sequence at scale. The financial services portal began with a governed vocabulary; the biodiversity platform began with a decision about where the tags would live. Neither began with a model.

Document tagging is not a chore that precedes the AI project. It is the part of the project that decides whether the agent knows what your documents mean, and can show its work when asked.