Core concepts & glossary
Almost everything in Document Blueprint comes down to a few core concepts: workspaces group the work, templates shape documents, cases are the durable records, and fields define what gets extracted or written. You change all of it in the UI, never in code.
The building blocks
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 (roles and seats are managed in the dashboard's Team view; billing in Settings). 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, answered inline on the always-present Data tab), 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 shows the Data tab first, then a tab per source. Build one template per document, 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: the durable record for 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 (teammates) and Clients (external collaborators with Portal access at /portal, where each row manages Forms to fill). Each collaborator's visibility is a per-case override (visibleCategoryIds / visibleFieldKeys) layered on top of their workspace-level baseline, set in the dashboard's Team view: teammates default to seeing everything, clients default to seeing nothing until granted. The same email can be a teammate 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 app 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, permanently: once you set a value by hand, later extractions leave that field alone.
Routing connects everything
A file that has been ingested, generated, or run on carries an invisible tag naming the document it is (e.g. W-9, Invoice). You never create or pick one: it comes from the documents your templates are built on. That tag is the connecting tissue across four subsystems: it ranks which templates apply to a file, routes automation intake (a Gmail or Drive rule pairs a trigger with a mailbox and a document; if the document can't be resolved at ingestion the file is skipped rather than half-imported), scopes collaborator visibility, and chooses which files a send template attaches. A file nobody has run a template on stays untagged, which is normal. See how files get routed.
Config-driven, not coded
Almost every behavior is UI-editable configuration: no developer, no build step. Dashboard columns, filters, and each teammate's or client's visibility come from workspace config, set in the Team view; 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.