Docling Graph: turning documents into validated knowledge graphs

The graph is typed, not merely embedded

Docling Graph starts from a plain claim about what makes document pipelines fail. It turns documents into validated Pydantic objects and then builds a directed knowledge graph with explicit semantic relationships. The project positions itself for chemistry, finance and legal work, where the connection between entities has to be exact, and states plainly that the point is to capture exact entity connections such as compounds and reactions, instruments and dependencies, or properties and measurements, rather than to rely on approximate text embeddings.

That is a meaningful difference in approach, not a wording preference. An embedding index tells you two passages look alike. A directed graph with typed edges tells you that instrument A depends on instrument B, and it can carry a provenance record pointing at the region of the page where that dependency was stated. The graph is a NetworkX directed graph built from the Pydantic objects, with stable IDs, edge metadata and provenance attached.

The project is Python, published on PyPI as docling-graph, MIT licensed, and sits under the Docling project with LF AI and Data and OpenSSF Best Practices badges in the documentation.

Two extraction paths share one config-driven pipeline

The toolkit supports two extraction paths. The first is local VLM extraction through Docling, which handles document parsing and layout understanding together. The second is LLM-based extraction routed through LiteLLM, which covers local runtimes such as vLLM and Ollama and API providers including OpenAI, Gemini, IBM watsonx and Mistral.

Both paths are configured through the same pipeline, with backend selection, chunking strategies and processing modes as configuration surfaces rather than code. Two processing details stand out. The dense extraction contract is a skeleton-then-flesh mode for complex documents, which it lists among the latest changes, and there is an optional serialization of the document as DocLang for the LLM input, alongside native parsing of .dclg and .dclx inputs.

The dependencies make the runtime picture concrete. pyproject.toml requires Python 3.10 or newer and pins docling at 2.105.0 or newer below 3.0.0 and docling-core with the chunking and chunking-openai extras at 2.86.0 or newer, with pydantic 2 and networkx 3 required as well. Remote conversion is supported through docling-serve, which offloads document conversion to a separate service when you would rather not convert locally.

Installing the package and creating a configuration

The stated requirement is Python 3.10 or higher, and the base install is a single pip command:

pip install docling-graph

That installs the core package with LiteLLM for remote and local LLM providers. The VLM backend needs the vlm extra, which the README shows as a second pip install with the vlm extra named in brackets; note that the snippet in the documentation is missing its closing quotation mark, so the command as printed will not paste cleanly into a shell. The documentation also points to an Installation Guide that covers the optional extras and GPU setup.

If you plan to use a hosted provider, the environment file is copied first:

cp .env.example .env

The template lists keys for OpenAI, Mistral AI, Google Gemini, IBM watsonx (key, project id and url) and Amazon Bedrock, plus a custom on-prem OpenAI-compatible endpoint, LM Studio and separate vLLM and Ollama base URLs for servers on a non-default host or port, and DOCLING_SERVE_URL with DOCLING_SERVE_API_KEY for a remote docling-serve instance. The comment at the top of the file notes that local inference through vLLM, Ollama or LM Studio needs none of these values, which matters if you plan to keep document content off hosted APIs.

A conversion run and the inspect step

The CLI takes a document location, a schema template, a processing mode, an extraction contract and optional debug output:

# Initialize configuration
docling-graph init

# Convert document from URL (each line except the last must end with \)
docling-graph convert "https://arxiv.org/pdf/2207.02720" \
    --template "docs.examples.templates.rheology_research.ScholarlyRheologyPaper" \
    --processing-mode "many-to-one" \
    --extraction-contract "dense" \
    --debug

# Visualize results
docling-graph inspect outputs

Reading that command tells you most of what the tool expects from you. The template argument is a dotted path to a Pydantic model, here a scholarly rheology paper schema shipped in the examples, so the schema is a Python class you import rather than a JSON file. The processing mode many-to-one and the dense extraction contract are the levers for a document that does not fit a simple one-page-per-record shape. The --debug flag enables the trace capture that the README describes as debug exports for extraction and fallback diagnostics, which is the mechanism to reach for when a field comes back empty.

The convert step writes into outputs, and inspect then visualizes those results. The documentation also offers an interactive HTML visualization and Markdown reports, which is the quickest way to see whether the extracted edges make sense before you wire the graph into a query.

Provenance and merging are deterministic, not model calls

Two of the newer capabilities are worth separating from the rest, because they do not spend model calls. Graph fusion merges multiple knowledge graphs into one, and the merge command is described as fully audited, deterministic and free of LLM calls. The provenance ledger is described as deterministic, with bounding-box geometry and no extra LLM calls.

For a regulated workflow that is the part that matters most. A provenance ledger with bounding-box geometry means each edge can be traced back to a rectangle on the page, so a reviewer can check the source rather than trust the extraction. Deterministic merging means two graph builds over the same inputs produce the same combined graph, which is what you need if the merge step sits in a repeatable pipeline rather than a one-off exploration.

The third deterministic feature is template generation. The tool can generate Pydantic templates from example documents or from ontologies in OWL or RDFS form, which is the practical route into the project for teams that have an ontology but not a schema. It also lowers the barrier for teams that have neither, since a handful of example documents can bootstrap the model.

Where this pipeline is the wrong shape

The design carries constraints that follow from being schema-driven. The first is that a fixed template has to be chosen before conversion, and a document whose structure does not match the schema will produce empty or wrong fields. The debug exports and fallback diagnostics exist for exactly this case, but the fallback is a recovery path, not a guarantee. If your corpus is heterogeneous enough that most documents need a different schema, the cost of maintaining one template per document family will dominate the benefit.

The second is cost and latency. Extraction runs through an LLM or a VLM, and dense extraction with skeleton-then-flesh is the heavier mode. The documentation does not publish throughput or cost figures for this, so there is no basis in the documentation for estimating either. A dense contract on a large corpus is a budget decision you have to make without published numbers, which is a real argument for starting with one document and measuring your own bill.

The third is scope. If you need readable text and a little structure, a plain parsing library gives you that with far less machinery. Docling Graph earns its complexity only when the edges between entities are the product.

Release cadence, dependency floors, and the MIT licence

The repository is not archived and the last push was on 2026-10-13, so the project is being worked on. The published releases are close together: v1.8.0 and v1.9.0 and v1.9.1 all landed on 2026-07-17, and pyproject.toml carries version 1.9.1. A CHANGELOG.md is present, and the package uses uv for lockfile management with a uv.lock in the tree and Ruff and Pydantic v2 in the tooling badges.

The dependency floors are the practical upgrade cost. The pyproject.toml comments explain why the docling floor sits where it does: DocLang input and export need docling 2.100 or newer and docling-core 2.86 or newer, the remote docling-serve client needs 2.104, and the floor was set at 2.105.0 because its service-client surface matches the locked version and it carries a multipart nested-options encoding fix. Those floors are inside the 2.x series, so a major docling release will require attention here rather than arriving automatically.

Licensing is MIT, declared in pyproject.toml and confirmed by the repository licence field. That allows commercial use and modification with attribution, and it applies to the code, not to the models or providers you point it at, which carry their own terms.

Editorial conclusion

Adopt Docling Graph when your documents carry typed relationships that a text answer cannot express, when you can define the schema as a Pydantic template, and when someone will maintain the extraction contract over time. Skip it when you only need text extraction, when the source documents are too irregular for a fixed template, or when a per-document LLM bill is unacceptable. Verify first that a single document converts cleanly with docling-graph convert against your own template, then check the exported provenance ledger before trusting the edge set.

Frequently asked questions

Official sources

1. docling-project/docling-graph on GitHub
2. Issues
3. License: MIT
4. README
5. Releases