Core concepts & glossary
Four pillars explain almost everything in Document Blueprint: workspaces group cases, templates shape documents, cases hold the work, and fields define what gets extracted or written, all reshaped through UI configuration, never code.
The four pillars
Workspace: top-level container for one document process. Owns its cases, templates, mailboxes, columns, filters, send templates, and the rules routing files into cases, all surfaced in the dashboard (the dashboard is the view onto the active workspace, not something the workspace contains). Lives inside an organization, the mostly-invisible tenant layer holding members, roles, capabilities, and billing (Settings → Account → Team). Every account always has one auto-provisioned free workspace; Pro is required to create more and to save settings for or delete any. Deletion is a permanent, no-undo cascade (cases, templates, sources, categories, mailboxes, filters, views, automations, send templates): the dialog previews counts and asks you to type the name. Delete your only one and a fresh blank workspace is auto-created. Cases live in mailboxes, persistent partitions of four kinds: inbox (the default landing), archive, trash (auto-purged after 30 days), and custom; the sidebar also lists a synthetic "All Mailboxes" entry.
Template: the blueprint for a generated document, defining fields, source tabs, placements, and an output filename pattern. Top-level sibling to workspaces (linked via template.workspaceId or standalone). Takes part in up to three operations: Extract (pulls AI data, needs an extracted input and a source PDF; exposes AI Instructions in the details dropdown), Fill (collects answers via question-input fields on the Form tab, which appears automatically once a question input exists), Generate (assembles source tabs into a PDF; its output category stays disabled until the template has at least one write zone). Extract and Generate are the two tracked capabilities (hasExtract / hasGenerate); Fill isn't tracked. Each field renders one of two ways: stamp text at exact coordinates (a write zone), or fill a named AcroForm field that came with the source PDF. Source tabs (formerly the document combiner) are the ordered sources shown in the document bar above the preview canvas; the bar auto-picks a multi-source, single-source, or form-only layout. Build one template per category, not per file variant, and let routing match incoming files. Test a template with the editor toolbar's split Run button (Test & Preview against stored sample documents); its dropdown's Run with your documents… fills the template against PDFs you upload, creating no case and auto-downloading the filled PDF (this replaced the former Quick Fill / "Lite Autofill" card). A per-template Document reflows toggle (details dropdown) re-anchors write zones when a document's layout shifts between fills; off by default, values land at authored coordinates.
Case: one unit of work (invoice, permit, contract). Holds files, extracted data, notes, generated outputs, and an activity timeline (assembled on open from notes, files, generations, form submissions, and collaborator changes, with no single master log). Its case identifier (case.identifier) uniquely identifies it within a workspace, backed by an atomic lock so two files sharing an identifier never spawn two cases. Sharing uses two peer panels: Team (workspace members) and Clients (external collaborators with Portal access at /portal, where each row manages Forms to fill), both scoped by per-collaborator visible categories (visibleCategoryIds). The same email can be a Worker in one organization and a Client in another. Autofill fills a template with a case's data and produces an output file, invoked from the review modal (per file, per case, or in batch from the dashboard); Re-extract re-runs AI on a file from the Documents section, where Update case saves input values without a document and Autofill also regenerates the filled PDF, both honoring _overrides. Send composes a {to, cc, subject, body, attachments} Gmail draft in the signed-in user's own mailbox (labels "Compose share" / "Compose Draft" / "Open Gmail Draft", never a plain "Send"); the product composes, the user clicks Send inside Gmail.
Field: a named concept with one or more inputs (each source: question, extracted, or static) acquiring values, plus optional outputs transforming them. AI extraction is bounded by the declared fields; the AI pulls only what you declare. Each output gets its own stable key and kind: static, prompt (AI over upstream outputs), computed (expression, re-evaluated live when it references $today/$now), or binding (email metadata, email body, system clock, company profile). A batch field holds repeating rows (line items) where the latest extraction replaces the whole row array (no per-row merging). Every value is filed under a permanent key, so renaming a field never moves data. Each tracks origin (from_extraction = AI set it, modified = a human edited it); re-extraction overwrites extracted rows but skips edits via the case.data._overrides map (clear an override in the field's history popover to let the next extraction re-overwrite).
Categories connect everything
Every file carries a category (e.g. W-9, Invoice), the single connecting tissue across five subsystems: it matches files to templates, routes automation intake (Gmail/Drive rules pair a trigger with a mailbox, category, template, and source; if the category or template can't be found at ingestion, the file is skipped rather than half-imported), scopes collaborator visibility, and chooses which files a send template attaches. See File categories.
Config-driven, not coded
Almost every behavior is UI-editable configuration: no developer, no build step. Dashboard columns, filters, and per-audience visibility come from workspace config; edit, save, live. Templates are live too: switch an input from question to extracted, save, the next run uses it. Filter presets are saved clause sets (e.g. status=review AND due_date < today) layered over a mailbox, views over the same data with no schema of their own (distinct from a mailbox, which is a physical partition). One exception: case-list sort is a personal per-device preference.