Document intelligence

The outcome

An operations or finance team has a pile of unstructured documents — PDFs, contracts, invoices, forms, scanned tickets — with the useful information locked inside. Document intelligence turns that pile into structured, queryable data in production: extract the entities and fields that matter, route and triage each document, then search across the results and run SQL over them.

Why it matters:

• No manual data entry. Fields, parties, dates, totals, and identifiers come out automatically as documents arrive — nobody re-keys a contract into a spreadsheet.
• Searchable archives. Find the document you need by what’s in it, not by remembering its filename.
• Analytics on documents. Once the contents are rows, your documents become a dataset — aggregate, filter, join, and report on them like any other table.

You build it by describing the flow to Claude and letting it drive the dodil CLI — no ETL job to author, no services to stitch.

How it maps to Dodil

The flow is: documents land, a pipeline extracts structure on upload, and the results become rows you can query. The extraction runs automatically as files arrive, so there’s no glue to maintain. Each stage is one K3 engine:

• Intake — drop documents into K3 Objects . Every upload is an event the rest of the flow reacts to.
• Extraction — K3 pipelines  run extraction templates (e.g. entity extraction or document triage) against each new file and write structured rows into K3 SQL  — no glue code in between.
• Query — run SQL directly over the extracted rows: filter, aggregate, join, and build dashboards on top of your documents.
• Semantic retrieval (optional) — also index the documents in K3 Vector  for meaning-based search, so you can find passages by what they say rather than by exact keywords.
• Inference — the extraction and any reasoning over documents is powered by Ignite Models , the managed inference catalog behind the platform.

Why it’s faster and cheaper here

Without Dodil, document intelligence is a stack you assemble and operate piece by piece:

• an OCR / extraction service to pull text out of PDFs and scans,
• an LLM to structure that raw text into fields and entities,
• an ETL pipeline to move and shape the output,
• a warehouse or database to hold the structured results,
• a vector store for semantic retrieval,
• the glue code that wires all of it together,
• and an auth story spanning every one of those services.

Each is a separate vendor, account, bill, and on-call rotation — and the integration code between them is yours to build and maintain forever.

On Dodil that stack collapses into one platform. Documents land in Objects; pipelines extract-on-upload straight into SQL tables — extraction, structuring, and loading happen automatically as files arrive, with no ETL to author. The structured results are immediately queryable with SQL, and the same documents can be indexed in Vector for semantic search. Inference comes from Ignite Models, and everything authenticates with a single token behind one CLI an agent can drive.

The result is faster to ship — there’s no multi-service integration to design and debug; you point a pipeline at a bucket and rows appear in a table. And it’s cheaper to run — one vendor and one bill instead of a half-dozen, no glue to maintain, and no idle services to pay for between batches.

Build it

• K3 pipelines  — the extraction path: a pipeline that pulls entities and fields out of each uploaded document and writes structured rows. See the Documents → Warehouse recipe .
• K3 SQL  — the queryable destination for extracted rows.
• K3 Vector  — semantic retrieval over the same documents.
• For a full step-by-step walkthrough, see the blog .

See also

• Use Cases — the outcome-led overview and the rest of what teams build on Dodil
• CLI · MCP — the typed surface you (and Claude) drive to build this
• Ignite Models  — the managed inference behind extraction