Version 3.0
Document intelligence

Document intelligence

You teach the platform how to read a class of document once, and every new file of that type comes out shaped the same, validated against your rules, with page references for every value. AP invoices, vendor statements, bills of lading, contracts, quality reports, certificates of compliance: one template per document type, governed once, reused everywhere.

Audience: builders

Why you're here

Your AP team triages five hundred PDF invoices a week. Three vendors send the totals in the footer, two put them in the header, one ships a spreadsheet. Your shipping desk reads bills of lading from a dozen carriers, each with a different layout. Your quality engineers extract pass/fail readings out of certificates that come back as scanned PDFs. The work is the same shape every time: pull the structured fields out, check that the totals add up, hand the result to a downstream step.

Document intelligence is the surface where you encode that shape. You upload a real document, the platform drafts the fields it found, you refine them in the workbench, you write the validation rules as sentences, and the platform decides how to run each rule. Every extracted value carries a page reference back to where it came from.

Document intelligence builds on Schemas. A Document intelligence template is a Schema: it lives at .blockparty/schemas/<scope>/<slug>.json in your Project, it carries the same scoping and review flow, and Apps reference it by path. Document intelligence is what makes a Schema work on PDFs, spreadsheets, and images. See Schemas for the catalog and governance side.

What this section covers

Where the surface lives

Open your Project. Click the Context tab. Pick Schemas. The header reads "Schemas" with a one-line note: "A schema teaches the system to read a class of document. Build it once, then it runs on every new one that comes in." This is the Document intelligence workbench. Marketing calls it "Document intelligence"; the in-product navigation calls it "Schemas". They are the same surface.

How it fits with the rest of your Project

Three things connect:

  • The Schema is the file that names the fields, the prompt, and the rules. It lives in your Project at .blockparty/schemas/<scope>/<slug>.json. Save it once, and any App or Runbook can reference it by path.
  • The workbench is where you draft, refine, and test the Schema against real documents.
  • The runtime is sdk.docintel, the agent-side API that runs parse and extract against the Schema. Your Runbook does not have to call it by hand: when an App's output contract references the Schema, the agent fills it from each work item.

For the catalog view, the candidate review flow, and how versioning and supersession work, see Schemas. The articles in this section cover the parts unique to Document intelligence: the workbench, the rules, and the citations.