@talonic/docs 0.20.12 → 0.20.14

package/dist/content.js

@@ -422,15 +422,19 @@ var sections = [
     content: [
       {
         type: "paragraph",
-        text: "Transform unstructured documents into structured, validated data \u2014 with per-cell provenance and AI reasoning traces."
+        text: "Transform unstructured documents into structured, validated data \u2014 with per-cell provenance and AI reasoning traces. Whether you are processing invoices, contracts, purchase orders, or any other document type, Talonic automatically discovers every data point and maps it to a unified knowledge graph. The platform handles the entire pipeline from OCR and classification through to structured output delivery, so you can focus on defining what data you need rather than building extraction logic."
       },
       {
         type: "paragraph",
-        text: "**Supported Formats:** 25+ file types. **Resolution:** 4-phase pipeline. **Instant Matches:** ~30% of cells (free)."
+        text: "**Supported Formats:** 25+ file types. **Resolution:** 4-phase pipeline. **Instant Matches:** ~30% of cells (free). The platform ingests PDF, DOCX, XLSX, images (PNG, JPG), HTML, JSON, CSV, email formats (EML, MSG), and ZIP archives. ZIP files are unpacked automatically and each contained document is processed individually through the same pipeline."
       },
       {
         type: "paragraph",
-        text: "Talonic is an **agentic data structuring platform**. It ingests documents of any type, discovers every data point inside them, builds a knowledge graph of canonical fields, and deploys AI agents to fill structured output schemas. Every cell in the output carries provenance metadata \u2014 which pipeline phase filled it, the confidence score, and an AI reasoning trace linking back to the source document."
+        text: "Talonic is an **agentic data structuring platform**. It ingests documents of any type, discovers every data point inside them, builds a knowledge graph of canonical fields, and deploys AI agents to fill structured output schemas. Every cell in the output carries provenance metadata \u2014 which pipeline phase filled it, the confidence score, and an AI reasoning trace linking back to the source document. The knowledge graph grows with every document you process \u2014 fields are clustered semantically, promoted through tiers, and enriched with master extraction instructions. This accumulated intelligence means extraction accuracy and speed improve over time without any manual tuning."
+      },
+      {
+        type: "paragraph",
+        text: "The platform is organized around three sections accessible from the sidebar: **Sources** (where documents enter the system), **Structuring** (where you define schemas, run extraction jobs, and review results), and **Outputs** (where approved data is delivered to downstream systems). Most teams start by uploading a small sample of documents, reviewing the auto-generated schemas, and then creating targeted extraction jobs. As the knowledge graph matures, an increasing share of cells are resolved instantly through graph lookup rather than AI extraction."
       },
       {
         type: "list",
@@ -440,13 +444,19 @@ var sections = [
           "**4-phase extraction pipeline** \u2014 resolve from the knowledge graph, extract with AI agents, re-resolve, then transform and validate.",
           "**~30% instant matches** \u2014 cells filled from graph lookup are free and instant, reducing both cost and latency.",
           "**Per-cell provenance** \u2014 every value traces back to its source with confidence scores and reasoning.",
-          "**Batch mode** \u2014 process large backlogs at 50% cost with a 48-hour delivery window."
+          "**Batch mode** \u2014 process large backlogs at 50% cost with a 48-hour delivery window.",
+          "**10 source connectors** \u2014 Google Drive, Gmail, SharePoint, OneDrive, Outlook, Teams, Notion, SQL databases, Amazon S3, and Azure Blob Storage.",
+          "**6 delivery connectors** \u2014 webhook (HMAC-SHA256), SFTP, Amazon S3, Azure Blob, Google Drive, and OneDrive for pushing results downstream."
         ]
       },
+      {
+        type: "paragraph",
+        text: "The extraction pipeline uses a cascading design that minimizes both cost and latency. Phase 1 fills cells using deterministic graph lookups at zero AI cost. Phase 2 deploys AI agents only for cells that Phase 1 could not resolve. Phase 3 re-runs lookups on AI output to normalize values to canonical codes. Phase 4 applies transforms, validates constraints, and fills remaining gaps with full grid context. This approach ensures that the cheapest, fastest method always runs first."
+      },
       {
         type: "callout",
         variant: "info",
-        text: "Talonic uses Anthropic Claude for intelligent extraction and reasoning. The platform handles OCR, classification, field discovery, and schema generation automatically \u2014 you provide documents and define what output you need."
+        text: "Talonic uses Anthropic Claude for intelligent extraction and reasoning. The platform handles OCR, classification, field discovery, and schema generation automatically \u2014 you provide documents and define what output you need. Document AI (Mistral) handles OCR by default, with automatic fallback to the Talonic API for unsupported formats."
       }
     ],
     related: [
@@ -457,19 +467,19 @@ var sections = [
     faq: [
       {
         question: "What is the Talonic Platform?",
-        answer: "Talonic is an agentic data structuring platform that ingests unstructured documents, discovers fields, builds a knowledge graph, and produces structured output with per-cell provenance and confidence scores."
+        answer: "Talonic is an agentic data structuring platform that ingests unstructured documents, discovers fields, builds a knowledge graph, and produces structured output with per-cell provenance and confidence scores. It supports 25+ file formats and uses a 4-phase extraction pipeline that combines deterministic graph lookups with AI agents to maximize accuracy while minimizing cost."
       },
       {
         question: "How many file formats does Talonic support?",
-        answer: "Talonic supports 25+ file types including PDF, DOCX, XLSX, images (PNG, JPG), plain text, HTML, JSON, CSV, email formats (EML, MSG), and ZIP archives."
+        answer: "Talonic supports 25+ file types including PDF, DOCX, XLSX, images (PNG, JPG), plain text, HTML, JSON, CSV, email formats (EML, MSG), and ZIP archives. ZIP files are unpacked automatically and each contained document is processed individually through the full extraction pipeline."
       },
       {
         question: 'What does "per-cell provenance" mean?',
-        answer: "Every cell in the structured output carries metadata about which pipeline phase filled it, a confidence score, an AI reasoning trace, and references back to the source document. This makes every value auditable and explainable."
+        answer: "Every cell in the structured output carries metadata about which pipeline phase filled it, a confidence score, an AI reasoning trace, and references back to the source document. This makes every value auditable and explainable. You can hover any cell to see its confidence score and click it to expand the full provenance panel with reasoning details."
       },
       {
         question: "How much do instant graph matches cost?",
-        answer: "Graph matches (approximately 30% of cells) are free. They are filled from the knowledge graph through deterministic lookup, so no LLM call is needed. Only cells that require AI extraction incur cost."
+        answer: "Graph matches (approximately 30% of cells) are free. They are filled from the knowledge graph through deterministic lookup, so no LLM call is needed. Only cells that require AI extraction incur cost. As your knowledge graph grows from processing more documents, the percentage of free graph matches increases, further reducing per-job costs."
       }
     ],
     mentions: [
@@ -564,11 +574,11 @@ var sections = [
     faq: [
       {
         question: "What is the Field Registry?",
-        answer: "The Field Registry is a unified knowledge graph of all canonical fields discovered across your documents, organized by tier, clustered semantically, and enriched with master extraction instructions."
+        answer: "The Field Registry is a unified knowledge graph of all canonical fields discovered across your documents, organized by tier, clustered semantically, and enriched with master extraction instructions. Fields progress through three tiers as they mature: Tier 3 (emerging, newly discovered), Tier 2 (established, promoted after repeated occurrence), and Tier 1 (universal, core fields present across most document types). Each tier transition triggers instruction synthesis so the platform learns the optimal way to extract that field."
       },
       {
         question: "What is provenance in Talonic?",
-        answer: "Provenance is per-cell metadata that tracks which pipeline phase filled the value, the confidence score, an AI reasoning trace, and source references back to the original document."
+        answer: "Provenance is per-cell metadata that tracks which pipeline phase filled the value, the confidence score, an AI reasoning trace, and source references back to the original document. You can inspect provenance by hovering any cell in the job results grid to see its confidence score, then clicking to expand the full provenance panel. The panel shows which strategy resolved the value, the raw source text it was derived from, and the AI reasoning chain when applicable."
       },
       {
         question: "How do Cases form?",
@@ -727,11 +737,11 @@ var sections = [
     faq: [
       {
         question: "What is the fastest way to get started with Talonic?",
-        answer: "Upload documents in Sources, then go to Structuring > Runs > New to create your first extraction job. Results appear progressively as each phase completes."
+        answer: "Upload documents in Sources, then go to Structuring > Runs > New to create your first extraction job. Results appear progressively as each phase completes. For a single document, use the quick extract shortcut (Cmd+J / Ctrl+J) to upload and process from any page without navigating to Sources first. Most users see their first structured output within two to three minutes of uploading."
       },
       {
         question: "How is the Talonic platform organized?",
-        answer: "The platform is organized into three primary sections: Sources (document ingest), Structuring (processing & validation), and Outputs (delivery to downstream systems)."
+        answer: "The platform is organized into three primary sections: Sources (document ingest), Structuring (processing & validation), and Outputs (delivery to downstream systems). Sources handles all document ingestion \u2014 manual uploads, cloud connectors, email inboxes, and API ingestion. Structuring is where you define schemas, run extraction jobs, review results, and approve output. Outputs manages delivery bindings that push approved data to webhooks, SFTP, cloud storage, and other downstream systems."
       },
       {
         question: "Do I need to define a schema before processing documents?",
@@ -757,7 +767,7 @@ var sections2 = [
     content: [
       {
         type: "paragraph",
-        text: "Talonic includes an embedded AI agent accessible from every page via `Cmd+I` (`Ctrl+I` on Windows). The agent understands your workspace context and can inspect schemas, search documents, analyze extraction quality, explore cases, and build schemas \u2014 all through natural language."
+        text: "Talonic includes an embedded AI agent accessible from every page via `Cmd+I` (`Ctrl+I` on Windows). The agent understands your workspace context and can inspect schemas, search documents, analyze extraction quality, explore cases, and build schemas \u2014 all through natural language. It serves as a conversational interface to your entire workspace, eliminating the need to navigate through multiple pages to find information or perform common operations."
       },
       {
         type: "paragraph",
@@ -769,7 +779,7 @@ var sections2 = [
       },
       {
         type: "paragraph",
-        text: "There are important limitations to be aware of. The agent cannot access external systems or the internet \u2014 it only works with data already in your Talonic workspace. It cannot bypass permission boundaries, so team members with read-only access cannot use the agent to make changes. Long-running operations like full batch extractions cannot be triggered through the agent; those must be initiated from the relevant UI page."
+        text: "There are important limitations to be aware of. The agent cannot access external systems or the internet \u2014 it only works with data already in your Talonic workspace. It cannot bypass permission boundaries, so team members with read-only (Viewer) access cannot use the agent to make changes. Long-running operations like full batch extractions cannot be triggered through the agent; those must be initiated from the relevant UI page. The agent also cannot modify field registry entries directly \u2014 those changes flow through the resolution pipeline."
       },
       { type: "heading", level: 3, id: "agent-capabilities", text: "What the Agent Can Do" },
       {
@@ -842,7 +852,11 @@ var sections2 = [
       },
       {
         question: "Can the AI agent access external systems or the internet?",
-        answer: "No. The agent only works with data already in your Talonic workspace. It cannot browse the internet, call external APIs, or access systems outside the platform."
+        answer: "No. The agent only works with data already in your Talonic workspace. It cannot browse the internet, call external APIs, or access systems outside the platform. All data the agent references comes from your documents, schemas, field registry, and job results."
+      },
+      {
+        question: "What are good questions to ask the agent?",
+        answer: 'Try questions like "Show me all invoices processed this week", "What fields does my Invoice schema have?", "Create a schema for purchase orders with vendor name, PO number, and total amount", or "Why was this document classified as a Service Agreement?" The agent handles both read-only queries and schema creation commands.'
       }
     ],
     mentions: [
@@ -862,7 +876,7 @@ var sections2 = [
     content: [
       {
         type: "paragraph",
-        text: "Every agent action is classified into an impact level that determines how it executes. Higher-impact operations require progressively more explicit confirmation."
+        text: "Every agent action is classified into an impact level that determines how it executes. Higher-impact operations require progressively more explicit confirmation. This graduated safety model ensures that the agent can be used freely for exploration and analysis while preventing accidental modifications to live data."
       },
       {
         type: "param-table",
@@ -902,9 +916,29 @@ var sections2 = [
         type: "paragraph",
         text: 'The `live_mutation` and `irreversible` levels provide escalating safety gates for operations that affect production data. A `live_mutation` \u2014 such as triggering a job run or publishing a schema \u2014 presents a confirmation dialog that you must accept. An `irreversible` action \u2014 such as deleting a source or purging documents \u2014 requires you to type a confirmation keyword (e.g., "DELETE") to proceed, preventing accidental data loss.'
       },
+      {
+        type: "heading",
+        level: 3,
+        id: "impact-examples",
+        text: "Common Actions by Impact Level"
+      },
+      {
+        type: "list",
+        ordered: false,
+        items: [
+          '**read** \u2014 "Show me the fields in this document", "What schemas do I have?", "How many invoices were processed today?"',
+          `**draft_mutation** \u2014 "Create a schema for invoices with these fields", "Add a 'due date' field to my schema draft"`,
+          '**live_mutation** \u2014 "Publish this schema draft", "Run extraction on these 50 documents"',
+          '**irreversible** \u2014 "Delete this source and all its documents", "Purge all data for this document type"'
+        ]
+      },
+      {
+        type: "paragraph",
+        text: "The impact level system also respects your team role. Team members with the Viewer role can only trigger `read` level actions through the agent \u2014 attempting commands that would modify data will be rejected with a clear permissions error. Members, Admins, and Owners can trigger higher impact levels according to their role permissions."
+      },
       {
         type: "callout",
-        text: "The agent always operates workshop-first: schema changes create drafts, not live versions. You review and publish when ready."
+        text: "The agent always operates workshop-first: schema changes create drafts, not live versions. You review and publish when ready. This means you can experiment freely with schema designs through the agent without any risk to your production configuration."
       }
     ],
     related: [
@@ -936,7 +970,7 @@ var sections2 = [
     content: [
       {
         type: "paragraph",
-        text: "The home page (click the Talonic logo) shows smart suggested prompts based on your workspace state. Prompts adapt to what is happening: active runs, schema creation opportunities, document types waiting for extraction. The agent input field lets you type any question directly from the dashboard."
+        text: "The home page (click the Talonic logo) shows smart suggested prompts based on your workspace state. Prompts adapt to what is happening: active runs, schema creation opportunities, document types waiting for extraction, and pending field confirmations. The agent input field lets you type any question directly from the dashboard, making it the natural starting point for each session."
       },
       {
         type: "paragraph",
@@ -949,6 +983,21 @@ var sections2 = [
       {
         type: "paragraph",
         text: "Every conversation with the agent is preserved in your session history, accessible from the dashboard. You can revisit previous questions and their answers, which is useful for auditing decisions or recalling how you configured a particular schema. The conversation history also provides continuity \u2014 if you asked the agent to analyze extraction quality last week, you can pick up where you left off."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "dashboard-metrics",
+        text: "Dashboard Metrics"
+      },
+      {
+        type: "paragraph",
+        text: "The dashboard surfaces key telemetry metrics from your workspace. **Capture rate** measures the percentage of schema fields that were successfully extracted across your latest job runs. **Resolve rate** tracks how many extracted fields were resolved against the registry without AI intervention. **Synthesize rate** shows how many registry fields have master instructions. Together, these three metrics give you a quick health check on your extraction pipeline \u2014 a high resolve rate means your registry is mature and extraction costs are low."
+      },
+      {
+        type: "callout",
+        variant: "info",
+        text: 'Try asking the agent questions like "What is my capture rate?", "Which document types need schemas?", or "Show me recent extraction failures" directly from the dashboard. The suggested prompts adapt to your workspace state, but you can always type any question.'
       }
     ],
     related: [
@@ -984,11 +1033,11 @@ var sections3 = [
     content: [
       {
         type: "paragraph",
-        text: "Sources are the entry point for all data. Every document belongs to a source \u2014 whether uploaded manually, synced from Google Drive, or ingested via API."
+        text: "Sources are the entry point for all data in Talonic. Every document belongs to a source \u2014 whether uploaded manually, synced from Google Drive, or ingested via the public API. A source acts as a container that groups related documents together and tracks their ingestion method, processing status, and connection credentials. You can create multiple sources to organize documents by department, client, or workflow."
       },
       {
         type: "paragraph",
-        text: "The Sources page provides a drag-and-drop upload interface. You can upload individual files, multiple files, or entire folders. ZIP archives are unpacked recursively. When uploading folders, the original file path is preserved as a data field (`source_file_path`) on each document \u2014 available for downstream processing and export."
+        text: "The Sources page provides a drag-and-drop upload interface. You can upload individual files, multiple files, or entire folders. ZIP archives are unpacked recursively \u2014 nested ZIPs are also extracted, so deeply packaged archives are handled automatically. When uploading folders, the original file path is preserved as a data field (`source_file_path`) on each document \u2014 available for downstream processing and export."
       },
       {
         type: "ui-excerpt",
@@ -998,11 +1047,37 @@ var sections3 = [
       },
       {
         type: "paragraph",
-        text: "Files are deduplicated via SHA-256 hashing \u2014 uploading the same file twice won't create duplicates. Processing runs asynchronously so you can continue working."
+        text: "Files are deduplicated via SHA-256 hashing \u2014 uploading the same file twice won't create duplicates. The hash is computed from the raw file bytes before any processing begins, so identical files are caught regardless of filename or upload method. Processing runs asynchronously so you can continue working while documents flow through OCR, classification, and extraction in the background."
       },
       {
         type: "paragraph",
         text: "When uploading folders or ZIP archives, the original directory structure is preserved as a `source_file_path` metadata field on each document (e.g., `contracts/2026/lease.pdf`). This field is available for filtering, export, and schema mapping \u2014 just like any AI-extracted field. It provides a natural way to organize and trace documents back to their original location in your file system."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "upload-workflow",
+        text: "Upload Workflow"
+      },
+      {
+        type: "list",
+        ordered: true,
+        items: [
+          "Navigate to the **Sources** page from the sidebar.",
+          "Click **New Source** to create a container, or select an existing source.",
+          "Drag files, folders, or ZIP archives onto the upload area.",
+          "Monitor the progress indicator \u2014 each file shows its current stage (uploading, OCR, classifying, extracting).",
+          "Once processing completes, documents appear in the source list with their extracted fields and classification."
+        ]
+      },
+      {
+        type: "paragraph",
+        text: "Large uploads (100+ files) are throttled to avoid overloading the pipeline, but you can monitor progress from the source page where each document shows its current processing stage. For very large ingestion jobs, consider using **batch processing mode** which defers AI extraction to run at 50% cost. You can also combine manual uploads with source connectors \u2014 for example, uploading a backlog of historical files manually while connecting Google Drive for ongoing ingestion."
+      },
+      {
+        type: "callout",
+        variant: "info",
+        text: "Use the **quick extract** shortcut (`Cmd+J` / `Ctrl+J`) to upload a single document from any page without navigating to Sources first. This opens a streamlined upload interface that processes the document immediately and shows results inline."
       }
     ],
     related: [
@@ -1013,15 +1088,19 @@ var sections3 = [
     faq: [
       {
         question: "How do I upload documents to Talonic?",
-        answer: "Drag files or folders onto the Sources page upload area. You can upload individual files, multiple files, entire folders, or ZIP archives that are unpacked recursively."
+        answer: "Drag files or folders onto the Sources page upload area. You can upload individual files, multiple files, entire folders, or ZIP archives that are unpacked recursively. You can also use the quick extract shortcut (Cmd+J / Ctrl+J) to upload a single file from any page."
       },
       {
         question: "Does Talonic detect duplicate uploads?",
-        answer: "Yes. Files are deduplicated via SHA-256 hashing. Uploading the same file twice will not create duplicates."
+        answer: "Yes. Files are deduplicated via SHA-256 hashing computed from the raw file bytes. Uploading the same file twice will not create duplicates, regardless of filename or upload method."
       },
       {
         question: "What happens when I upload a folder or ZIP archive?",
-        answer: "ZIP archives are unpacked recursively and each file is processed individually. Folders preserve the original directory structure as a source_file_path metadata field on each document, available for filtering and export."
+        answer: "ZIP archives are unpacked recursively and each file is processed individually. Nested ZIPs are also extracted. Folders preserve the original directory structure as a source_file_path metadata field on each document, available for filtering, schema mapping, and export."
+      },
+      {
+        question: "Can I upload large batches of documents?",
+        answer: "Yes. Large uploads (100+ files) are automatically throttled to prevent pipeline overload. Each document processes independently through OCR, classification, and extraction. For very large batches, consider batch processing mode which defers extraction at 50% cost."
       }
     ],
     mentions: [
@@ -1082,6 +1161,10 @@ var sections3 = [
         type: "paragraph",
         text: "The **text fast-path** is the most efficient route: files like CSV, JSON, and plain text are read directly into memory with no external API call. This means they process almost instantly and incur no OCR cost. Email files (EML, MSG) are parsed to extract both the message body and any attachments, with each attachment processed as a separate document."
       },
+      {
+        type: "paragraph",
+        text: "Email files receive special handling. EML files are parsed to extract both the message body and any attachments, with each attachment processed as a separate document linked back to the parent email. MSG files (Microsoft Outlook format) follow the OCR path and similarly extract embedded attachments. This means a single email file can produce multiple documents \u2014 the email body and each of its attachments \u2014 all processed independently through the full pipeline."
+      },
       {
         type: "callout",
         variant: "info",
@@ -1099,7 +1182,7 @@ var sections3 = [
       },
       {
         question: "How does Talonic handle image files?",
-        answer: "Image files (PNG, JPG, JPEG, GIF, WEBP) are sent to AI for multimodal visual extraction."
+        answer: "Image files (PNG, JPG, JPEG, GIF, WEBP) are sent to AI for multimodal visual extraction. The AI model sees the image directly and extracts data visually, which is useful for photos of receipts, scanned handwritten notes, or diagrams. If an image was previously OCR'd and produced meaningful Markdown (more than 100 characters), the system uses the Markdown extraction path instead, which enables richer quality metrics and confidence scoring."
       },
       {
         question: "How does Talonic handle large PDF files?",
@@ -1117,7 +1200,7 @@ var sections3 = [
     content: [
       {
         type: "paragraph",
-        text: "When a document is uploaded, it flows through a multi-stage pipeline:"
+        text: "When a document is uploaded, it flows through a multi-stage pipeline that transforms raw files into structured, queryable data. Each stage runs automatically and its progress is visible in the document's processing log. The pipeline handles everything from OCR conversion to AI-powered field extraction, with built-in retry logic for resilience."
       },
       {
         type: "ui-excerpt",
@@ -1125,9 +1208,29 @@ var sections3 = [
         title: "Document \u2014 Processing Log",
         caption: "Every document shows a structured processing log with per-stage timing."
       },
+      {
+        type: "heading",
+        level: 3,
+        id: "processing-stages",
+        text: "Processing Stages"
+      },
+      {
+        type: "list",
+        ordered: true,
+        items: [
+          "**Document AI OCR** \u2014 Converts files to Markdown and produces structured annotations (type, sensitivity, PII categories, jurisdiction) in a single pass.",
+          "**Classification** \u2014 Verifies the annotation against the 529-type document ontology. If the label and content disagree, AI resolves the correct type from the actual text.",
+          "**Triage** \u2014 Tags the document with sensitivity level, department, jurisdiction, and compliance signals derived from the OCR annotations.",
+          "**AI Data Field Capture** \u2014 Extracts every data point from the document content using Claude, producing fields with confidence scores and source text provenance."
+        ]
+      },
       {
         type: "paragraph",
-        text: "**Document AI OCR** converts files to Markdown and produces structured annotations (type, sensitivity, PII categories, jurisdiction) in a single pass. **Classification** verifies the annotation against the 529-type document ontology \u2014 if the label and content disagree, AI resolves the correct type from the actual text. **AI Data Field Capture** extracts every data point. Large documents are automatically chunked and processed in parallel."
+        text: "**Document AI OCR** converts files to Markdown and produces structured annotations (type, sensitivity, PII categories, jurisdiction) in a single pass. **Classification** verifies the annotation against the 529-type document ontology \u2014 if the label and content disagree, AI resolves the correct type from the actual text. **AI Data Field Capture** extracts every data point. Large documents (PDFs exceeding 25 pages) are automatically split into page chunks, processed in parallel, and merged \u2014 so even lengthy documents complete efficiently without timeouts."
+      },
+      {
+        type: "paragraph",
+        text: "The extraction stage uses a chunk-first approach by default: document sections are labelled inline and sent to Claude in a single call. The response combines JSON metadata with CSV-formatted fields, capturing confidence scores, source text, and chunk coverage for every extracted value. Optional quality passes \u2014 field count estimation, verification, and cross-reference enrichment \u2014 run as lightweight Haiku calls to catch extraction gaps. Six quality metrics are computed post-extraction: confidence per chunk, noise detection, semantic dissimilarity, text coverage, connection awareness, and consistency awareness."
       },
       {
         type: "paragraph",
@@ -1152,9 +1255,13 @@ var sections3 = [
         type: "paragraph",
         text: "Both fields appear in the **Raw Extraction** tab with full confidence (1.0) and are available for schema mapping, job resolution, filtering, and export \u2014 just like any AI-extracted field."
       },
+      {
+        type: "paragraph",
+        text: "If OCR or extraction fails, the platform automatically retries using a fallback chain. OCR failures cascade from Document AI to the Talonic API to local parsers. Extraction parse failures retry in realtime mode (never as new batches). Each retry stage is logged in the processing log so you can see exactly what happened. Documents that exhaust all retries are marked with a terminal status (`extraction_failed` or `ocr_failed`) and remain visible in the source for manual review."
+      },
       {
         type: "callout",
-        text: "Documents are marked **complete** after AI extraction finishes. You can start using them in jobs immediately \u2014 no need to wait for further processing."
+        text: "Documents are marked **complete** after AI extraction finishes. You can start using them in jobs immediately \u2014 no need to wait for field resolution, which runs separately and enriches the registry in the background."
       }
     ],
     related: [
@@ -1199,7 +1306,7 @@ var sections3 = [
       },
       {
         type: "paragraph",
-        text: 'Documents sharing the same ontology type are automatically merged into one document type. When a new canonical type appears, it is auto-created with ontology metadata. Unresolvable documents are assigned "Unclassified Document".'
+        text: 'Documents sharing the same ontology type are automatically merged into one document type. When a new canonical type appears, it is auto-created with ontology metadata including category, subcategory, and typical fields. Unresolvable documents are assigned "Unclassified Document" \u2014 they can still be processed and extracted, but the platform cannot map them to a specific type in the ontology.'
       },
       {
         type: "paragraph",
@@ -1209,6 +1316,23 @@ var sections3 = [
         type: "paragraph",
         text: "Document types drive several downstream features. The platform auto-generates a **schema** for each document type, pre-populated with fields discovered from documents of that type. **Routing rules** can be configured per document type to automatically assign schemas or trigger jobs when new documents arrive. The **Field Registry** tracks which fields appear in which document types, building a cross-type knowledge graph over time."
       },
+      {
+        type: "heading",
+        level: 3,
+        id: "ontology-examples",
+        text: "Example Ontology Types"
+      },
+      {
+        type: "list",
+        ordered: false,
+        items: [
+          "**Financial** \u2014 Invoice, Purchase Order, Credit Note, Bank Statement, Tax Return",
+          "**Legal** \u2014 Employment Contract, Non-Disclosure Agreement, Lease Agreement, Power of Attorney",
+          "**Logistics** \u2014 Bill of Lading (Ocean), Commercial Invoice, Packing List, Certificate of Origin",
+          "**Healthcare** \u2014 Medical Record, Lab Report, Insurance Claim, Prescription",
+          "**Corporate** \u2014 Articles of Incorporation, Board Resolution, Annual Report, Meeting Minutes"
+        ]
+      },
       {
         type: "callout",
         variant: "info",
@@ -1251,7 +1375,7 @@ var sections3 = [
     content: [
       {
         type: "paragraph",
-        text: "Click any document to see its detail page with four views:"
+        text: "Click any document to see its detail page with four views. The detail page is where you inspect individual extraction results, verify field accuracy, and debug processing issues. It serves as the single source of truth for everything the platform knows about a document \u2014 from raw AI output to resolved canonical fields."
       },
       {
         type: "param-table",
@@ -1290,6 +1414,10 @@ var sections3 = [
         type: "paragraph",
         text: "The **Processing Log** tab provides a stage-by-stage timeline of how the document was processed, including per-stage timing. You can see exactly how long OCR, classification, and extraction took, which is useful for diagnosing slow processing or understanding why a document was classified a particular way. The **Original File** tab lets you view or download the source file, so you can always compare the AI's extraction against the original document."
       },
+      {
+        type: "paragraph",
+        text: "When reviewing extraction quality, start with the **Raw Extraction** tab to check that the AI found all expected fields. Compare the confidence scores across fields \u2014 values above 0.90 are typically reliable, while values below 0.70 may warrant manual verification. If a field is missing, check the **Original File** tab to confirm the information exists in the source document. The **Processing Log** tab can reveal whether the document was split into chunks, which sometimes causes fields near chunk boundaries to be missed."
+      },
       {
         type: "callout",
         variant: "info",
@@ -1332,11 +1460,11 @@ var sections3 = [
     content: [
       {
         type: "paragraph",
-        text: "Routing rules automatically assign actions to documents based on their type. Configure rules to auto-assign schemas, trigger jobs, or route documents to specific workflows. Manage rules from **Documents → Routing**."
+        text: "Routing rules automatically assign actions to documents based on their type. Configure rules to auto-assign schemas, trigger jobs, or route documents to specific workflows. Manage rules from **Documents → Routing**. Routing is the bridge between document ingestion and structured output \u2014 it eliminates the manual step of selecting a schema and starting a job for each new document."
       },
       {
         type: "paragraph",
-        text: "Each routing rule specifies a **document type** as the trigger condition and one or more **actions** to execute when a document of that type is processed. Actions include assigning a specific user schema, automatically creating a job run, or tagging the document for a particular workflow. Rules are evaluated in priority order, so you can layer general rules with more specific overrides."
+        text: "Each routing rule specifies a **document type** as the trigger condition and one or more **actions** to execute when a document of that type is processed. Actions include assigning a specific user schema, automatically creating a job run, or tagging the document for a particular workflow. Rules are evaluated in priority order, so you can layer general rules with more specific overrides. If multiple rules match the same document type, the highest-priority rule wins."
       },
       {
         type: "paragraph",
@@ -1346,10 +1474,25 @@ var sections3 = [
         type: "paragraph",
         text: "You can review rule execution history from the routing page to see which rules fired, which documents they matched, and what actions were taken. This audit trail helps you verify that your routing configuration is working as expected and diagnose cases where documents were not routed correctly."
       },
+      {
+        type: "heading",
+        level: 3,
+        id: "routing-actions",
+        text: "Available Routing Actions"
+      },
+      {
+        type: "list",
+        ordered: false,
+        items: [
+          "**Assign schema** \u2014 Automatically link a user schema to matching documents, so they are ready for extraction without manual configuration.",
+          "**Trigger job** \u2014 Create and start a job run as soon as a document of the matching type completes processing.",
+          "**Tag workflow** \u2014 Apply a workflow tag that can be used for filtering, reporting, or downstream delivery bindings."
+        ]
+      },
       {
         type: "callout",
         variant: "info",
-        text: "Start with a simple routing rule for your most common document type. Once you verify it works correctly, expand to additional types. Rules are evaluated in priority order, so you can add specific overrides without disrupting existing rules."
+        text: "Start with a simple routing rule for your most common document type. Once you verify it works correctly, expand to additional types. Rules are evaluated in priority order, so you can add specific overrides without disrupting existing rules. Review the execution history regularly to ensure documents are being routed as expected."
       }
     ],
     related: [
@@ -1368,7 +1511,7 @@ var sections3 = [
       },
       {
         question: "Can routing rules fully automate my document processing pipeline?",
-        answer: "Yes. By combining routing rules with source connectors and delivery bindings, you can create a fully automated pipeline: documents arrive from a connected source, routing rules assign schemas and trigger extraction jobs, and delivery bindings push approved results to downstream systems."
+        answer: "Yes. By combining routing rules with source connectors and delivery bindings, you can create a fully automated pipeline: documents arrive from a connected source, routing rules assign schemas and trigger extraction jobs, and delivery bindings push approved results to downstream systems. For example, a Google Drive folder receiving weekly invoices can be connected as a source with a routing rule that auto-assigns your Invoice schema and triggers extraction. A delivery binding then pushes approved results to your ERP via webhook \u2014 zero manual steps required."
       }
     ],
     mentions: ["routing rules", "auto-assign", "schema assignment", "document workflows"]
@@ -1382,7 +1525,7 @@ var sections3 = [
     content: [
       {
         type: "paragraph",
-        text: "Beyond manual upload and API ingestion, Talonic connects to external systems to automatically ingest documents. Each connector authenticates via OAuth or credentials and syncs documents into a source."
+        text: "Beyond manual upload and API ingestion, Talonic connects to external systems to automatically ingest documents. Each connector authenticates via OAuth or credentials and syncs documents into a source. Connectors turn Talonic into a continuous ingestion pipeline \u2014 once configured, new files arriving in a connected folder or inbox are available for processing without manual intervention."
       },
       {
         type: "param-table",
@@ -1452,9 +1595,31 @@ var sections3 = [
         type: "paragraph",
         text: "Credential-based connectors (SQL, Amazon S3, Azure Blob) authenticate with access keys or connection strings rather than OAuth. SQL connections support PostgreSQL, MySQL, and MSSQL, with a built-in read-only safety layer that prevents accidental writes. S3-compatible storage like MinIO and Cloudflare R2 also works through the S3 connector. All credentials are encrypted at rest before being stored."
       },
+      {
+        type: "heading",
+        level: 3,
+        id: "connector-setup",
+        text: "Setting Up a Connector"
+      },
+      {
+        type: "list",
+        ordered: true,
+        items: [
+          "Navigate to **Sources** and click **New Source**.",
+          "Select the connector type from the dropdown (e.g., Google Drive, SharePoint, S3).",
+          "For OAuth connectors, complete the authorization flow \u2014 you will be redirected to the provider to grant access.",
+          "For credential-based connectors, enter the required credentials (access key, connection string, or API key).",
+          "Browse the connected system to select specific folders, mailboxes, buckets, or tables to import.",
+          "Optionally enable **Batch Processing** to defer extraction at 50% cost."
+        ]
+      },
+      {
+        type: "paragraph",
+        text: "Email connectors (Gmail and Outlook) ingest attachments from messages rather than the messages themselves. Gmail supports query passthrough so you can use standard Gmail search syntax to filter which messages are scanned for attachments. Outlook supports date range filtering and an option to include email bodies as documents. Microsoft Teams ingests meeting transcripts and channel attachments, with configurable surface filters for channels, chats, and meetings."
+      },
       {
         type: "callout",
-        text: "Connectors are feature-gated on their OAuth client ID/secret. Without credentials configured, the connector dropdown entry is disabled."
+        text: "Connectors are feature-gated on their OAuth client ID/secret. Without credentials configured, the connector dropdown entry is disabled. Microsoft Teams requires tenant-admin consent for privileged scopes like `ChannelMessage.Read.All`."
       }
     ],
     related: [
@@ -1465,15 +1630,19 @@ var sections3 = [
     faq: [
       {
         question: "What external sources can Talonic connect to?",
-        answer: "Google Drive, Gmail, SharePoint, OneDrive, Outlook, Teams, Notion, SQL databases (MSSQL/PostgreSQL), Amazon S3, and Azure Blob Storage."
+        answer: "Google Drive, Gmail, SharePoint, OneDrive, Outlook, Teams, Notion, SQL databases (MSSQL/PostgreSQL/MySQL), Amazon S3 (and S3-compatible storage like MinIO and Cloudflare R2), and Azure Blob Storage. Each connector authenticates via OAuth or credentials."
       },
       {
         question: "How are OAuth tokens stored?",
-        answer: "OAuth access and refresh tokens are encrypted at rest using AES-256-GCM. The encryption key is SOURCE_ENCRYPTION_KEY (falls back to JWT_SECRET)."
+        answer: "OAuth access and refresh tokens are encrypted at rest using AES-256-GCM. The encryption key is SOURCE_ENCRYPTION_KEY (falls back to JWT_SECRET). Tokens are decrypted only when making API calls to the connected service."
       },
       {
         question: "What happens if a connector loses its credentials or authorization?",
-        answer: "If OAuth credentials are revoked or expire, the source enters a disconnected state. Reconnecting via the source settings page automatically refreshes the credentials without losing your existing documents or configuration."
+        answer: "If OAuth credentials are revoked or expire, the source enters a disconnected state. Reconnecting via the source settings page automatically refreshes the credentials without losing your existing documents or configuration. No documents are deleted during disconnection."
+      },
+      {
+        question: "Does the SQL connector support write operations?",
+        answer: "No. SQL connections have a built-in read-only safety layer. A two-layer defense ensures no writes: an AST parser rejects anything that is not a single SELECT statement, and per-transaction read-only mode is enforced at the database level. MSSQL connections additionally reject accounts with elevated privileges."
       }
     ],
     mentions: [
@@ -1504,7 +1673,7 @@ var sections4 = [
     content: [
       {
         type: "paragraph",
-        text: "The Field Registry is the heart of Talonic's intelligence. As documents are processed, AI discovers fields and resolves them into a unified knowledge graph that grows smarter with every document."
+        text: "The Field Registry is the heart of Talonic's intelligence. As documents are processed, AI discovers fields and resolves them into a unified knowledge graph that grows smarter with every document. The registry is what makes Talonic a learning system \u2014 each new document contributes to a shared understanding of field names, types, and extraction patterns that benefits all future processing."
       },
       {
         type: "paragraph",
@@ -1527,6 +1696,10 @@ var sections4 = [
       {
         type: "paragraph",
         text: "The registry is the foundation for several downstream features. **Jobs** use registry fields to pre-fill schema values via lookup cascades before resorting to LLM extraction. **Semantic clusters** group related registry fields together. **Generated schemas** are auto-built from registry fields that appear in a given document type. Understanding the registry is key to understanding how Talonic reduces extraction cost and improves accuracy over time."
+      },
+      {
+        type: "paragraph",
+        text: "Each registry field maintains two separate embedding vectors: one optimized for **resolution matching** (based on the canonical name and synonyms) and one for **graph visualization** (based on name, type, and instruction). This dual-embedding approach ensures that each concern uses the most appropriate representation. The resolution embedding is what powers the three-band matching during document processing, while the visualization embedding drives the Field Map clustering view."
       }
     ],
     related: [
@@ -1565,7 +1738,7 @@ var sections4 = [
     content: [
       {
         type: "paragraph",
-        text: "Fields are organized into three tiers based on how frequently they appear:"
+        text: "Fields are organized into three tiers based on how frequently they appear across your document corpus. The tier system is Talonic's primary quality signal \u2014 it tells you at a glance how well-established and reliable a field is. Tiers also directly affect extraction cost: higher-tier fields are cheaper to extract because they can be resolved via lookup rather than AI calls."
       },
       {
         type: "param-table",
@@ -1599,9 +1772,19 @@ var sections4 = [
         type: "paragraph",
         text: "**Tier 3** fields are newly discovered and may require a full Claude API call to extract during job runs, making them the most expensive tier. As more documents are processed and a Tier 3 field appears consistently, it is automatically promoted. You can also manually adjust a field's tier from the registry detail page if you know a field is stable enough to promote early."
       },
+      {
+        type: "heading",
+        level: 3,
+        id: "promotion-thresholds",
+        text: "Promotion Thresholds"
+      },
+      {
+        type: "paragraph",
+        text: "Promotion from Tier 3 to Tier 2 requires meeting one of two thresholds: **5 occurrences** (the field appears in at least 5 documents) or a **10% occurrence rate** (the field appears in at least 10% of all documents in your workspace). Promotion is evaluated automatically after every batch resolution run, so fields graduate without manual intervention as your document corpus grows. Once promoted to Tier 2, a field gains a synthesized master instruction and becomes eligible for lookup-based resolution in job runs."
+      },
       {
         type: "callout",
-        text: "Tier badges appear throughout the platform as the primary quality signal. Tier 1 = green, Tier 2 = amber, Tier 3 = gray."
+        text: "Tier badges appear throughout the platform as the primary quality signal. Tier 1 = green, Tier 2 = amber, Tier 3 = gray. You can see tier badges on the Field Registry page, in document detail views, on schema fields, and in job result grids."
       }
     ],
     related: [
@@ -1633,7 +1816,7 @@ var sections4 = [
     content: [
       {
         type: "paragraph",
-        text: 'Fields with similar meanings are automatically grouped using AI embeddings. For example, "Vendor Name", "Supplier Name", and "Company Name" cluster together. You can manually merge or split clusters from the Field Map view.'
+        text: 'Fields with similar meanings are automatically grouped into semantic clusters using AI embeddings. For example, "Vendor Name", "Supplier Name", and "Company Name" cluster together because they represent the same underlying concept. You can manually merge or split clusters from the Field Map view. Clusters are a key mechanism for cross-document field normalization \u2014 they allow the platform to recognize that different document types use different names for the same data point.'
       },
       {
         type: "paragraph",
@@ -1647,10 +1830,25 @@ var sections4 = [
         type: "paragraph",
         text: 'Semantic clusters serve a practical purpose beyond organization. When a job runs, the resolution engine uses clusters to transfer values between fields that belong to the same cluster. If a document has a field called "Supplier Name" and your schema expects "Vendor Name", the cluster linkage allows the value to transfer automatically without an AI call. This is one of the key mechanisms that reduces extraction cost as your registry matures.'
       },
+      {
+        type: "heading",
+        level: 3,
+        id: "cluster-operations",
+        text: "Cluster Operations"
+      },
+      {
+        type: "list",
+        ordered: false,
+        items: [
+          "**Merge** \u2014 Combine two clusters that represent the same concept. All fields from both clusters are unified under a single canonical entry.",
+          "**Split** \u2014 Remove a field from a cluster if it was incorrectly grouped. The split field becomes its own independent cluster.",
+          "**Inspect** \u2014 View all fields in a cluster, their source document types, and occurrence counts to understand why they were grouped."
+        ]
+      },
       {
         type: "callout",
         variant: "info",
-        text: "Manual cluster adjustments are permanent and improve the model for all future documents. If you notice the platform grouping unrelated fields together, split them early \u2014 this prevents incorrect value transfers during job runs."
+        text: "Manual cluster adjustments are permanent and improve the model for all future documents. If you notice the platform grouping unrelated fields together, split them early \u2014 this prevents incorrect value transfers during job runs. Conversely, merging clusters that should be together improves resolution accuracy across your entire corpus."
       }
     ],
     related: [
@@ -1689,7 +1887,7 @@ var sections4 = [
     content: [
       {
         type: "paragraph",
-        text: "When a document is processed, each extracted field is resolved against the registry using a three-band matching model. The bands determine whether a match is accepted automatically, flagged for confirmation, or treated as a new field."
+        text: "When a document is processed, each extracted field is resolved against the registry using a three-band matching model. The bands determine whether a match is accepted automatically, flagged for confirmation, or treated as a new field. Resolution is the core mechanism that turns raw, document-specific field names into canonical registry entries \u2014 building a unified knowledge graph across all your documents."
       },
       {
         type: "param-table",
@@ -1711,9 +1909,19 @@ var sections4 = [
           }
         ]
       },
+      {
+        type: "heading",
+        level: 3,
+        id: "resolution-process",
+        text: "How Resolution Works"
+      },
       {
         type: "paragraph",
-        text: "Resolution runs concurrently across documents. Each document's fields are resolved in an isolated transaction to prevent lock contention. Occurrence rates are updated after each transaction commits, keeping the registry eventually consistent without blocking concurrent ingestion."
+        text: "Resolution follows a strict three-band order that is never skipped. First, the system checks for an **exact name match** against existing registry entries. If no exact match is found, it checks for a **cluster member match** \u2014 whether the field name matches any synonym in an existing semantic cluster. Finally, it computes **semantic embedding similarity** using AI embeddings to find conceptually similar fields. This graduated approach prioritizes fast, deterministic matches before falling back to more expensive similarity comparisons."
+      },
+      {
+        type: "paragraph",
+        text: "Resolution runs concurrently across documents. Each document's fields are resolved in an isolated transaction to prevent lock contention. Occurrence counts are updated atomically in the same SQL transaction using upserts with deadlock retry logic. This keeps the registry eventually consistent without blocking concurrent ingestion, even when hundreds of documents are being processed simultaneously."
       },
       {
         type: "paragraph",
@@ -1732,15 +1940,19 @@ var sections4 = [
     faq: [
       {
         question: "How does field resolution work in Talonic?",
-        answer: "Each extracted field is matched against the registry using three bands: auto (>=0.80 similarity, auto-linked), confirm (0.50-0.79, flagged for review), and new (<0.50, creates a new Tier 3 field)."
+        answer: "Each extracted field is matched against the registry using three bands in strict order: exact name match, cluster member match, then semantic embedding similarity. Results fall into auto (>=0.80, auto-linked), confirm (0.50-0.79, flagged for review), or new (<0.50, creates a new Tier 3 field). The three-band order is never skipped."
       },
       {
         question: "Where can I review pending field confirmations?",
-        answer: "Navigate to Resolution > Pending Confirmations to review fields in the confirm band. Accept to merge into an existing cluster, or reject to create a new field."
+        answer: "Navigate to Resolution > Pending Confirmations to review fields in the confirm band. Accept to merge the field into an existing cluster, or reject to create a new independent field. Processing confirmations promptly improves resolution accuracy for future documents."
       },
       {
         question: "What happens after resolution completes?",
-        answer: "After resolution, the platform evaluates tier promotions and regenerates affected schemas in a fixed chain: resolve, then promote, then regenerate. This ensures that newly promoted fields immediately appear in auto-generated schemas."
+        answer: "After resolution, the platform evaluates tier promotions and regenerates affected schemas in a fixed chain: resolve, then promote, then regenerate. This ensures that newly promoted fields immediately appear in auto-generated schemas. The chain is atomic \u2014 it never breaks midway."
+      },
+      {
+        question: "How does resolution reduce extraction cost during job runs?",
+        answer: "During job runs, the system uses a 3-tier lookup cascade \u2014 string normalization, token fuzzy matching, then AI fallback \u2014 to fill 60-80% of cells without a full LLM call. Fields that are well-established in the registry with high occurrence counts are the most likely to resolve via lookup, making Tier 1 and Tier 2 fields essentially free to extract."
       }
     ],
     mentions: [
@@ -1760,7 +1972,7 @@ var sections4 = [
     content: [
       {
         type: "paragraph",
-        text: "As the same field is extracted from many documents, AI synthesizes a **master instruction** \u2014 a reusable directive that captures the best way to extract that field. Master instructions improve accuracy over time and are automatically used when running jobs."
+        text: "As the same field is extracted from many documents, AI synthesizes a **master instruction** \u2014 a reusable directive that captures the best way to extract that field. Master instructions improve accuracy over time and are automatically used when running jobs. They encode domain-specific knowledge about where a field typically appears in a document, what format it takes, and how to disambiguate it from similar fields."
       },
       {
         type: "paragraph",
@@ -1774,9 +1986,26 @@ var sections4 = [
         type: "paragraph",
         text: `You can view and edit master instructions from the field detail page in the registry. Editing an instruction overrides the AI-synthesized version, which is useful when you have domain expertise the AI hasn't captured. The **"Synthesize All"** button in the Field Registry triggers the full pipeline \u2014 embedding, resolution, and synthesis \u2014 for all qualifying fields in a single operation.`
       },
+      {
+        type: "heading",
+        level: 3,
+        id: "instruction-lifecycle",
+        text: "Instruction Lifecycle"
+      },
+      {
+        type: "list",
+        ordered: true,
+        items: [
+          "A field is discovered and added to the registry as Tier 3 with no instruction.",
+          "As more documents are processed, the field accumulates occurrences and extraction examples.",
+          "When the field is promoted to Tier 2, the platform synthesizes a master instruction by analyzing all extraction patterns for that field.",
+          "The instruction is injected into AI prompts during future job runs, improving extraction accuracy.",
+          "You can manually edit the instruction at any time from the field detail page to incorporate domain expertise."
+        ]
+      },
       {
         type: "callout",
-        text: 'Click **"Synthesize All"** in the Field Registry to generate instructions for all qualifying fields. This runs the combined pipeline: embed &rarr; resolve &rarr; synthesize.'
+        text: 'Click **"Synthesize All"** in the Field Registry to generate instructions for all qualifying fields. This runs the combined pipeline: embed &rarr; resolve &rarr; synthesize. The operation processes all fields that meet the synthesis criteria in a single batch.'
       }
     ],
     related: [
@@ -1818,11 +2047,11 @@ var sections5 = [
     content: [
       {
         type: "paragraph",
-        text: "Schemas define the structure of your output data. There are two types: AI-generated schemas created per document type, and user templates you define yourself."
+        text: "Schemas define the structure of your output data. There are two types: AI-generated schemas created per document type, and user templates you define yourself. Generated schemas give you an automatic, always-up-to-date view of what the platform has discovered about each document type, while user templates let you define exactly which fields you need for a specific downstream use case."
       },
       {
         type: "paragraph",
-        text: "For each document type, Talonic generates a schema containing all Tier 1 and Tier 2 fields with occurrences in that type. Generated schemas are versioned \u2014 new versions are created when the registry changes. You can diff any two versions to see what changed."
+        text: "For each document type, Talonic generates a schema containing all Tier 1 and Tier 2 fields with occurrences in that type. Generated schemas are versioned \u2014 new versions are created when the registry changes. You can diff any two versions to see what changed. The diff view highlights added fields, removed fields, type changes, and updated instructions so you can track how your field landscape evolves over time."
       },
       {
         type: "paragraph",
@@ -1832,9 +2061,13 @@ var sections5 = [
         type: "paragraph",
         text: "Generated schemas are most useful as a starting point for understanding what Talonic has discovered about your documents. Review the generated schema for a document type to see which fields the system has identified, then use that knowledge to build a **User Template** containing only the fields you actually need. You can also use the diff view to monitor how your field landscape evolves over time as new documents are processed and new fields are promoted."
       },
+      {
+        type: "paragraph",
+        text: "The tier system determines which fields appear in generated schemas. **Tier 1** (core) fields are the most frequently occurring and reliably extracted data points \u2014 they appear in nearly every document of the type. **Tier 2** (established) fields occur in a significant portion of documents and have been validated through repeated extraction. **Tier 3** (emerging) fields are too new or infrequent to be included in generated schemas, but they may be promoted as more documents are processed and their occurrence rate crosses the promotion threshold."
+      },
       {
         type: "callout",
-        text: "Generated schemas are read-only and cannot be used directly for job execution. To run an extraction job, create a **User Template** and map its fields to the registry."
+        text: "Generated schemas are read-only and cannot be used directly for job execution. To run an extraction job, create a **User Template** and map its fields to the registry. Generated schemas serve as a discovery tool to understand what the platform has found in your documents."
       }
     ],
     related: [
@@ -1845,15 +2078,15 @@ var sections5 = [
     faq: [
       {
         question: "What are generated schemas?",
-        answer: "Generated schemas are AI-created output definitions for each document type, containing all Tier 1 and Tier 2 fields found in that type. They are versioned and support diffing between versions."
+        answer: "Generated schemas are AI-created output definitions for each document type, containing all Tier 1 and Tier 2 fields found in that type. They are versioned and support diffing between versions. Each field in the schema includes data type information, the AI-synthesized master instruction, and occurrence statistics."
       },
       {
         question: "How are generated schemas updated?",
-        answer: "New versions are created automatically when the Field Registry changes (new fields promoted, clusters merged). You can diff any two versions to see what changed."
+        answer: "New versions are created automatically when the Field Registry changes (new fields promoted, clusters merged). You can diff any two versions to see what changed. The versioning system is append-only, so every previous version is preserved in the timeline for reference."
       },
       {
         question: "Can I run an extraction job using a generated schema?",
-        answer: "No. Generated schemas are read-only references. To run a job, create a User Template, select the fields you need, map them to the registry, and publish a version."
+        answer: "No. Generated schemas are read-only references. To run a job, create a User Template, select the fields you need, map them to the registry, and publish a version. Generated schemas are designed as a discovery tool \u2014 use them to understand what the platform has found, then build a focused template for your specific output needs."
       }
     ],
     mentions: ["generated schemas", "AI-generated", "versioning", "schema diff"]
@@ -1867,7 +2100,7 @@ var sections5 = [
     content: [
       {
         type: "paragraph",
-        text: "User templates are the primary way to define your output structure. Navigate to **Structuring &rarr; Schemas** to create one."
+        text: "User templates are the primary way to define your output structure. Navigate to **Structuring &rarr; Schemas** to create one. Templates give you complete control over which fields appear in your output, how they are extracted, and what validation rules apply. Unlike generated schemas, templates are executable \u2014 once published, they can be used to run extraction jobs."
       },
       {
         type: "list",
@@ -1905,15 +2138,15 @@ var sections5 = [
     faq: [
       {
         question: "How do I create a user template?",
-        answer: "Navigate to Structuring > Schemas, create a template with a name and description, add fields with data types and instructions, map to the registry, add reference tables, and publish."
+        answer: "Navigate to Structuring > Schemas, create a template with a name and description, add fields with data types and instructions, map to the registry, add reference tables, and publish. You can also import from Excel, CSV, or JSON to bootstrap a template from an existing spreadsheet \u2014 column headers become field names and data types are inferred automatically."
       },
       {
         question: "What is the difference between generated schemas and user templates?",
-        answer: "Generated schemas are AI-created per document type with all Tier 1/2 fields. User templates are custom-defined output structures where you choose exactly which fields to include and how to map them."
+        answer: "Generated schemas are AI-created per document type with all Tier 1/2 fields \u2014 they are read-only and cannot run jobs. User templates are custom-defined output structures where you choose exactly which fields to include, how to map them to the registry, and what validation rules apply. Only published user templates can be used for extraction jobs."
       },
       {
         question: "Can I update a published template?",
-        answer: "Published versions are immutable. To make changes, open the Workshop draft, edit your fields, and publish a new version. The previous version remains available in Version History for reference and diffing."
+        answer: "Published versions are immutable. To make changes, open the Workshop draft, edit your fields, and publish a new version. The previous version remains available in Version History for reference and diffing. This append-only versioning ensures that historical job results always reference the exact schema that produced them."
       }
     ],
     mentions: ["user templates", "schema creation", "field mapping", "reference tables", "publish"]
@@ -1927,7 +2160,7 @@ var sections5 = [
     content: [
       {
         type: "paragraph",
-        text: "Every field in a template supports advanced features beyond the basic name and type. These features control how values are extracted, validated, transformed, and delivered."
+        text: "Every field in a template supports advanced features beyond the basic name and type. These features control how values are extracted, validated, transformed, and delivered. You can layer features independently \u2014 for example, a single field can have a format constraint, a reference table for code lookup, modifiers for post-processing, and an output name remap for delivery. Features compose without conflicts, giving you fine-grained control over every aspect of the extraction and output pipeline."
       },
       {
         type: "param-table",
@@ -1979,6 +2212,20 @@ var sections5 = [
         type: "paragraph",
         text: "When configuring a field, start with the basics \u2014 name, type, and registry mapping \u2014 then layer on advanced features as needed. For example, add a **format constraint** to enforce a date pattern, attach a **reference table** for code lookups, or define **capture submoves** to control the exact extraction sequence. Features compose independently, so you can mix and match without conflicts."
       },
+      {
+        type: "list",
+        ordered: false,
+        items: [
+          "**Format constraint** \u2014 Regex validation with configurable mismatch behavior (clear, flag, or replace).",
+          "**Modifiers** \u2014 Post-processing pipeline: format (date/number conversion), alias (value mapping), max_length (truncation).",
+          "**Constraints** \u2014 Validation rules: required, enum, date-format, length, cross-field expressions.",
+          "**Bypass strategy** \u2014 Skip AI extraction: constant value, deterministic ID generator, or reference table lookup.",
+          "**Reference table** \u2014 Key-value pairs for code mapping with a 3-tier lookup cascade (normalization, fuzzy, AI).",
+          "**Manual instruction** \u2014 User-written extraction directive that overrides the AI-synthesized master instruction.",
+          "**Capture submoves** \u2014 Ordered extraction sequence: match (field matching), compute (calculation), reason (LLM inference).",
+          "**Output name** \u2014 Remap the field name in delivery and export output without changing the internal schema name."
+        ]
+      },
       {
         type: "paragraph",
         text: "The **modifier pipeline** runs in a fixed order during Phase 4 of the extraction pipeline: format transforms first (converting dates or numbers to your target format), then alias mapping (replacing values using a lookup), and finally max_length truncation. Constraint evaluation happens after all modifiers have been applied, so constraints validate the final transformed value, not the raw extraction."
@@ -2083,15 +2330,15 @@ var sections5 = [
     faq: [
       {
         question: "How does field matching work in Talonic schemas?",
-        answer: "Schema fields are matched to the registry using four types: Exact (direct name match), Semantic (AI finds equivalent field), Composite (multiple fields combine), and Unmapped (no match, needs manual instructions)."
+        answer: "Schema fields are matched to the registry using a three-band resolution process. First, exact name matching against canonical names and synonyms. Then, embedding similarity for semantic matches (auto-accept above 0.8, confirm between 0.5 and 0.8). Four match types result: Exact (direct name match), Semantic (AI finds equivalent field), Composite (multiple fields combine), and Unmapped (no match, needs manual instructions)."
       },
       {
         question: "What happens when a field is unmapped?",
-        answer: "Unmapped fields have no registry match. They require manual extraction instructions to guide the AI on how to extract the value from documents."
+        answer: "Unmapped fields have no registry match and do not inherit a master extraction instruction. They require manual extraction instructions to guide the AI on how to extract the value from documents. Write clear, specific instructions describing where in the document to look and what formatting to expect for best results."
       },
       {
         question: "Can I re-run field matching after adding more documents?",
-        answer: "Yes. Use the Rematch button in the template editor to re-run matching against the current registry. Fields that were previously unmapped may find new matches as your registry grows."
+        answer: "Yes. Use the Rematch button in the template editor to re-run matching against the current registry. Fields that were previously unmapped may find new matches as your registry grows through processing additional documents. For best results, use descriptive field names that reflect the actual data rather than generic labels."
       }
     ],
     mentions: ["field matching", "exact match", "semantic match", "composite", "unmapped"]
@@ -2105,7 +2352,7 @@ var sections5 = [
     content: [
       {
         type: "paragraph",
-        text: "Reference tables map human-readable values to system codes. Each table is a list of key-value pairs where `key` = output code and `value` = label. During extraction, a 3-tier lookup cascade runs:"
+        text: 'Reference tables map human-readable values to system codes. Each table is a list of key-value pairs where `key` = output code and `value` = label. For example, a country reference table might map "United States" to `US`, "Germany" to `DE`, and "United Kingdom" to `GB`. During extraction, a 3-tier lookup cascade runs automatically against the table to normalize extracted values to your canonical codes:'
       },
       {
         type: "param-table",
@@ -2136,13 +2383,17 @@ var sections5 = [
         type: "paragraph",
         text: "Reference tables are used in two pipeline stages. In **Phase 1**, the lookup cascade runs as part of the resolve step, mapping extracted labels to codes without any AI calls (Tier 1 and Tier 2). In **Phase 3**, the cascade runs again on values produced by Phase 2's AI extraction, normalizing free-text AI output to your canonical codes. This two-pass approach ensures maximum code coverage across the entire pipeline."
       },
+      {
+        type: "paragraph",
+        text: 'For example, consider a "Contract Type" field with a reference table mapping codes to labels: `std_master` = "Master Agreement", `std_service` = "Service Agreement", `std_nda` = "Non-Disclosure Agreement". When the AI extracts "Frame Agreement" from a document, the Phase 3 lookup cascade normalizes it: Tier 1 finds no exact match, Tier 2 fuzzy matching scores "Frame Agreement" against "Master Agreement" at ~0.65 (below the threshold), so Tier 3 AI fallback maps it to `std_master` at 0.50 confidence. Adding "Frame Agreement" as a synonym pointing to `std_master` would promote this to a Tier 1 match (0.95 confidence) in future runs.'
+      },
       {
         type: "paragraph",
         text: 'For best results, include common variations and abbreviations as separate value entries all pointing to the same key. For example, if your code is `US`, add values for "United States", "USA", "U.S.A.", and "United States of America". The more variations you cover, the more values resolve at Tier 1 (highest confidence) without falling through to fuzzy or AI matching.'
       },
       {
         type: "callout",
-        text: "Reference table quality directly determines lookup accuracy. A properly loaded table produces 90-100% accurate results within a single run."
+        text: "Reference table quality directly determines lookup accuracy. A properly loaded table produces 90-100% accurate results within a single run. Review the lookup_failed validation flag in Phase 3 results to identify values that could not be mapped \u2014 these are candidates for adding new entries to your table."
       }
     ],
     related: [
@@ -2197,7 +2448,7 @@ var sections5 = [
       },
       {
         type: "callout",
-        text: "Breaking changes include field removals and type changes. The system surfaces these warnings at publish time so you can assess the impact on active delivery bindings and downstream systems before committing."
+        text: "Breaking changes include field removals and type changes. The system surfaces these warnings at publish time so you can assess the impact on active delivery bindings and downstream systems before committing. Always run a **Test Extraction** on representative documents before publishing a draft that includes breaking changes."
       }
     ],
     related: [
@@ -2208,15 +2459,15 @@ var sections5 = [
     faq: [
       {
         question: "How does schema versioning work?",
-        answer: "Templates use a workshop system: Live (published, read-only), Workshop (mutable draft), and Version History (timeline with diffs). Breaking changes like field removals or type changes are detected on promotion."
+        answer: "Templates use a workshop system with three states: Live (published, read-only), Workshop (mutable draft), and Version History (timeline with diffs). Breaking changes like field removals or type changes are detected on promotion. Every published version is immutable, creating a complete audit trail of how your schema evolved over time. The diff view highlights added fields, removed fields, type changes, and updated instructions between any two versions."
       },
       {
         question: "What are breaking changes in a schema?",
-        answer: "Breaking changes include field removals and type changes. The system detects and warns about these when promoting a draft to live, helping you avoid unintended downstream impacts."
+        answer: "Breaking changes include field removals and data type changes. The system detects and warns about these when promoting a draft to live, helping you avoid unintended downstream impacts. If a downstream delivery binding depends on a specific field, the warning helps you assess the impact before committing the change. Always run a Test Extraction on representative documents before publishing a draft that includes breaking changes."
       },
       {
         question: "Can I revert to a previous schema version?",
-        answer: "Version history is append-only, so you cannot revert directly. However, you can review any previous version in the timeline, compare it with the current live version using the diff view, and manually re-add fields or settings that were changed."
+        answer: "Version history is append-only, so you cannot revert directly. However, you can review any previous version in the timeline, compare it with the current live version using the diff view, and manually re-add fields or settings that were changed. This design ensures that every historical job result always references the exact schema version that produced it. For safe iteration, always use the Workshop draft to test changes via Test Extraction before publishing a new version."
       }
     ],
     mentions: ["versioning", "drafts", "workshop", "live version", "breaking changes"]
@@ -2230,23 +2481,27 @@ var sections5 = [
     content: [
       {
         type: "paragraph",
-        text: "Before publishing a draft, run a test extraction to compare draft vs. live results side-by-side. Select a few documents, run the test, and see exactly how your changes affect output."
+        text: "Before publishing a draft, run a test extraction to compare draft vs. live results side-by-side. Select a few documents, run the test, and see exactly how your changes affect output. This is the safest way to validate schema changes \u2014 you can iterate on field instructions, reference tables, and format constraints without affecting production jobs or published data."
       },
       {
         type: "paragraph",
-        text: "After running a test, you will see a comparison grid highlighting cells that changed between the draft and live versions. Focus on fields you modified \u2014 new fields, updated instructions, or changed reference tables \u2014 to verify they produce the expected values. This workflow catches regressions before they reach production, so you can iterate on your schema with confidence."
+        text: "After running a test, you will see a comparison grid highlighting cells that changed between the draft and live versions. Focus on fields you modified \u2014 new fields, updated instructions, or changed reference tables \u2014 to verify they produce the expected values. Cells that improved show in green, cells that regressed show in red, and unchanged cells are neutral. This workflow catches regressions before they reach production, so you can iterate on your schema with confidence."
       },
       {
         type: "paragraph",
-        text: "Test extractions run through the same 4-phase pipeline as production jobs, so the results you see are identical to what a full job would produce. The test uses a simplified single-call extraction mode under the hood, which is faster but still applies all schema features including reference table lookups, format constraints, and modifiers. This gives you a reliable preview without the cost of a full pipeline run."
+        text: "Test extractions run through the same extraction pipeline as production jobs, so the results you see are representative of what a full job would produce. The test uses a simplified single-call extraction mode under the hood, which is faster but still applies all schema features including reference table lookups, format constraints, modifiers, and bypass strategies. This gives you a reliable preview without the cost and time of a full 4-phase pipeline run."
       },
       {
         type: "paragraph",
         text: 'For best results, select 3-5 representative documents that cover the variety in your corpus \u2014 include at least one "clean" document and one with unusual formatting or missing fields. This gives you confidence that your schema handles both typical and edge-case documents correctly. Run the test after every significant change to a field instruction, reference table, or format constraint.'
       },
+      {
+        type: "paragraph",
+        text: "A typical iteration workflow looks like this: add or modify a field in the Workshop draft, run a test extraction on your sample documents, review the comparison grid to check that the new field produces correct values, adjust the instruction if needed, re-test, and publish when satisfied. This tight feedback loop is the fastest way to refine extraction accuracy without impacting production jobs or consuming unnecessary credits."
+      },
       {
         type: "callout",
-        text: "Test extractions do not affect your live data or consume production job credits differently. They are designed for rapid iteration \u2014 run as many tests as you need before publishing."
+        text: "Test extractions do not affect your live data or consume production job credits differently. They are designed for rapid iteration \u2014 run as many tests as you need before publishing. Results are temporary and do not appear in your job history."
       }
     ],
     related: [
@@ -2279,7 +2534,7 @@ var sections5 = [
     content: [
       {
         type: "paragraph",
-        text: "Dialects define the output format for structured data. They control how values are serialized when delivered or exported. A dialect can be shared across schemas or defined inline for a specific schema. Configure dialects in the **Schema &rarr; Delivery** tab."
+        text: "Dialects define the output format for structured data. They control how values are serialized when delivered or exported \u2014 everything from date formatting and number locale to CSV delimiters and character encoding. A dialect can be shared across schemas or defined inline for a specific schema. Configure dialects in the **Schema &rarr; Delivery** tab. Shared dialects ensure consistent formatting across all your exports without duplicating configuration on every schema."
       },
       {
         type: "param-table",
@@ -2317,6 +2572,10 @@ var sections5 = [
           }
         ]
       },
+      {
+        type: "paragraph",
+        text: 'For example, to configure date formatting for a European accounting system: set `date_format` to `DD.MM.YYYY` so dates render as `15.03.2025` instead of the default `YYYY/MM/DD`. Pair this with `number_locale: "de-DE"` for comma-decimal formatting (`1.234,56`) and `delimiter: ";"` so CSV files open correctly in Excel on European locale machines. Save this configuration as a shared dialect named "EU Accounting" and attach it to every schema that feeds into that system \u2014 all future exports and deliveries will use consistent formatting without per-schema configuration.'
+      },
       {
         type: "paragraph",
         text: "When working with international data, configure the dialect to match your downstream system requirements. For example, set **number_locale** to `fr-FR` for European comma-decimal formatting, switch the **delimiter** to semicolon for CSV compatibility, and choose **UTF-8-BOM** encoding if your data will be opened in Excel. Creating a shared dialect and reusing it across schemas ensures consistent formatting across all your exports."
@@ -2371,7 +2630,7 @@ var sections5 = [
     content: [
       {
         type: "paragraph",
-        text: "Bypass strategies determine how a schema field is populated when it should not go through LLM extraction. Each strategy provides a deterministic value without consuming AI credits."
+        text: "Bypass strategies determine how a schema field is populated when it should not go through LLM extraction. Each strategy provides a deterministic value without consuming AI credits. This is useful for fields whose values are known ahead of time, can be derived from other fields, or should be looked up from reference data rather than extracted from the document text."
       },
       {
         type: "param-table",
@@ -2403,6 +2662,17 @@ var sections5 = [
         type: "paragraph",
         text: 'Use bypass strategies for fields whose values are known ahead of time or can be derived without reading the document. For example, set a **constant** of `"USD"` for a currency field that is always the same, or use a **generator** to produce a deterministic ID for each row. Fields with bypass strategies skip the AI extraction phase entirely, reducing processing time and credit usage.'
       },
+      {
+        type: "list",
+        ordered: false,
+        items: [
+          "**none** \u2014 Use when a field should always be blank. Useful for placeholder columns in your output that will be populated by a downstream system.",
+          '**constant** \u2014 Use when the value never varies across documents (e.g., currency `"USD"`, data source `"talonic"`, processing status `"pending"`).',
+          "**generator (deterministic-id)** \u2014 Use when you need a unique, reproducible identifier for each row. Produces a hash-based ID from entity attributes.",
+          "**generator (context-fallback)** \u2014 Use when the value can be derived from other fields in the schema without reading the document.",
+          "**reference** \u2014 Use when the value should be looked up from a reference table using a `key_expression` that references another schema field (e.g., map supplier name to ERP vendor code)."
+        ]
+      },
       {
         type: "paragraph",
         text: "The **reference** bypass strategy is particularly powerful for enrichment fields. Define a `key_expression` that references another field in the schema (e.g., the supplier name), and the system will automatically look up the corresponding code from your reference table without any AI involvement. This is ideal for mapping extracted entity names to internal system identifiers, ERP codes, or classification labels."
@@ -2413,7 +2683,7 @@ var sections5 = [
       },
       {
         type: "callout",
-        text: "When a `generator` strategy fails to produce a value, the field falls through to LLM extraction as a safety net. Strategy values are normalized via generator mappings in Phase 4 of the pipeline."
+        text: "When a `generator` strategy fails to produce a value, the field falls through to LLM extraction as a safety net \u2014 your data is never left incomplete due to a bypass misconfiguration. Strategy values are normalized via generator mappings in Phase 4 of the pipeline. Bypass strategies execute during Phase 1, before any AI calls are made."
       }
     ],
     related: [
@@ -2452,7 +2722,7 @@ var sections5 = [
     content: [
       {
         type: "paragraph",
-        text: "Format constraints apply regex-based validation to schema fields. They are evaluated post-extraction in Phase 4 of the pipeline, after all transforms have been applied. Original values are preserved for audit in `original_extractions`."
+        text: "Format constraints apply regex-based validation to schema fields. They are evaluated post-extraction in Phase 4 of the pipeline, after all transforms have been applied. Original values are preserved for audit in `original_extractions`. This means you can always review what the AI originally extracted before the constraint was applied, giving you full visibility into the extraction pipeline even when values are cleared or replaced."
       },
       {
         type: "param-table",
@@ -2477,7 +2747,7 @@ var sections5 = [
       },
       {
         type: "paragraph",
-        text: "Define format constraints in the schema field editor. The pattern uses standard regex syntax. The editor provides a live test input so you can verify the pattern before saving."
+        text: "Define format constraints in the schema field editor. The pattern uses standard regex syntax with support for inline flags like `(?i)` for case-insensitive matching. The editor provides a live test input so you can verify the pattern against sample values before saving. This immediate feedback loop helps you catch overly strict or overly permissive patterns before they affect real extraction runs."
       },
       {
         type: "paragraph",
@@ -2489,7 +2759,7 @@ var sections5 = [
       },
       {
         type: "callout",
-        text: "The regex evaluator includes ReDoS protection: nested quantifiers are rejected and input is capped at 1,000 characters. Use the `(?i)` inline flag for case-insensitive matching."
+        text: "The regex evaluator includes ReDoS protection: nested quantifiers are rejected and input is capped at 1,000 characters. Use the `(?i)` inline flag for case-insensitive matching. Format constraints support standard JavaScript regex syntax, so you can use character classes, alternation, and lookahead assertions for complex validation patterns."
       }
     ],
     related: [
@@ -2500,15 +2770,15 @@ var sections5 = [
     faq: [
       {
         question: "What are format constraints?",
-        answer: "Format constraints apply regex-based validation to schema fields, evaluated post-extraction in Phase 4. Mismatch behaviors: empty (clear), flag (amber dot), or constant (replace with a fixed value)."
+        answer: 'Format constraints apply regex-based validation to schema fields, evaluated post-extraction in Phase 4 after all transforms have been applied. Mismatch behaviors: empty (clear the cell, the default), flag (keep the value but show an amber dot in the results grid), or constant (replace with a fixed value like "INVALID" or "N/A"). The constraint validates the final transformed value, not the raw extraction.'
       },
       {
         question: "Are original values preserved when format constraints clear a cell?",
-        answer: "Yes. Original values are always preserved for audit in the original_extractions table, regardless of the mismatch behavior applied."
+        answer: "Yes. Original values are always preserved for audit in the original_extractions table, regardless of the mismatch behavior applied. This means you can always review what the AI originally extracted before the constraint was applied, giving you full visibility into the extraction pipeline."
       },
       {
         question: "Can I use case-insensitive regex patterns?",
-        answer: "Yes. Use the (?i) inline flag at the start of your pattern for case-insensitive matching. The evaluator supports standard JavaScript regex syntax with inline flags."
+        answer: "Yes. Use the (?i) inline flag at the start of your pattern for case-insensitive matching. The evaluator supports standard JavaScript regex syntax including character classes, alternation, and lookahead assertions. ReDoS protection is built in \u2014 nested quantifiers are rejected and input is capped at 1,000 characters."
       }
     ],
     mentions: [
@@ -2532,23 +2802,27 @@ var sections6 = [
     content: [
       {
         type: "paragraph",
-        text: "Extraction jobs are the core of the platform \u2014 where schemas meet documents and AI agents produce structured data. A job produces a grid: rows = documents, columns = schema fields."
+        text: "Extraction jobs are the core of the platform \u2014 where schemas meet documents and AI agents produce structured data. A job produces a grid: rows = documents, columns = schema fields. Each cell in the grid contains an extracted value along with metadata including a confidence score, the resolution type, the pipeline phase that produced it, and an AI reasoning trace explaining how the value was derived from the source document."
       },
       {
         type: "paragraph",
-        text: "Navigate to **Structuring &rarr; Runs &rarr; New**. Select your template and documents, then click Start. Results appear progressively as each phase completes."
+        text: "Navigate to **Structuring &rarr; Runs &rarr; New**. Select your template and documents, then click Start. Results appear progressively as each phase completes. You can choose between three extraction modes: **pipeline** (full 4-phase extraction, the default), **simple** (single AI call, faster but less thorough), or **field registry** (no AI, deterministic strategies only \u2014 useful for benchmarking registry coverage)."
       },
       {
         type: "paragraph",
-        text: "When you start a job, the platform runs a pre-flight check to ensure all selected documents have completed their field resolution step. If any document was uploaded recently and has not yet been resolved against the Field Registry, the system automatically resolves it before entering Phase 1. This lazy resolution gate prevents silent data loss where registry-based lookups would return empty results for unresolved documents."
+        text: "When you start a job, the platform runs a pre-flight check to ensure all selected documents have completed their field resolution step. If any document was uploaded recently and has not yet been resolved against the Field Registry, the system automatically resolves it before entering Phase 1. This lazy resolution gate prevents silent data loss where registry-based lookups would return empty results for unresolved documents. The pre-flight resolution runs with a concurrency of 3 and failures are non-fatal \u2014 Phase 1 will proceed with whatever is resolved."
       },
       {
         type: "paragraph",
         text: "For best results, select documents of the same type or closely related types for a single job. The schema you choose should match the document content \u2014 using an invoice schema on contract documents will produce poor results. Start with a small batch of 5-10 documents to validate your schema, review the output, apply corrections, and then scale up to larger runs once you are confident in the extraction quality."
       },
+      {
+        type: "paragraph",
+        text: "The platform supports scaling caps to ensure reliable processing: Phase 2 extraction handles up to 2,000 documents per job, and Phase 4 transforms support up to 1,000 documents. Grid results are flushed to the database in batches of 200 documents per phase. For very large document collections, consider splitting into multiple jobs by document type for optimal results and easier review."
+      },
       {
         type: "callout",
-        text: "Results appear progressively as each pipeline phase completes. You do not need to wait for the entire job to finish \u2014 you can begin reviewing Phase 1 results while Phase 2 is still running."
+        text: "Results appear progressively as each pipeline phase completes. You do not need to wait for the entire job to finish \u2014 you can begin reviewing Phase 1 results while Phase 2 is still running. The phase timeline on the job detail page shows which phase is active and the cumulative fill rate at each stage."
       }
     ],
     related: [
@@ -2581,7 +2855,7 @@ var sections6 = [
     content: [
       {
         type: "paragraph",
-        text: "Every job runs through four phases. Each fills more cells in the output grid, reducing the problem space for the next. Results are visible as each phase completes."
+        text: "Every job runs through four phases. Each fills more cells in the output grid, reducing the problem space for the next. Results are visible as each phase completes. The grid is the single source of truth during execution and is flushed to the database after each phase, enabling progressive rendering in the UI. A confidence gate protects high-quality values from being overwritten by later phases \u2014 once a cell is filled with high confidence, it is permanently locked."
       },
       {
         type: "paragraph",
@@ -2603,7 +2877,7 @@ var sections6 = [
       },
       {
         type: "callout",
-        text: "Phase order is fixed: Phase 1 &rarr; 2 &rarr; 3 &rarr; 4. Phases are never skipped or reordered. This guarantees that high-confidence deterministic values from Phase 1 are always protected by the confidence gate before AI extraction runs."
+        text: "Phase order is fixed: Phase 1 &rarr; 2 &rarr; 3 &rarr; 4. Phases are never skipped or reordered. This guarantees that high-confidence deterministic values from Phase 1 are always protected by the confidence gate before AI extraction runs. The confidence gate is the single most important pipeline rule \u2014 once a cell is filled with a high-confidence value, no later phase can overwrite it with a lower-confidence result."
       }
     ],
     related: [
@@ -2614,11 +2888,11 @@ var sections6 = [
     faq: [
       {
         question: "What are the four phases of the extraction pipeline?",
-        answer: "Phase 1: Resolve (graph matches, ~30% of cells), Phase 2: Agent (AI strategies), Phase 3: Validation (cross-field checks), and Phase 4: Re-read (targeted gap filling)."
+        answer: "Phase 1: Resolve (graph matches and deterministic lookups, fills 30-80% of cells depending on registry maturity). Phase 2: Agent (AI extraction for remaining gaps, grouped into batches of 10 fields per call). Phase 3: Validation (cross-field checks and reference table re-normalization of AI output). Phase 4: Re-read (targeted gap filling with full grid context, plus deterministic transforms and format constraint evaluation)."
       },
       {
         question: "Can I see results before all phases complete?",
-        answer: "Yes. Results are visible as each phase completes. The fill rate increases progressively through the pipeline."
+        answer: "Yes. The grid is flushed to the database after each phase, enabling progressive rendering in the UI. You can watch cells fill in real time and begin reviewing Phase 1 results while Phase 2 is still running. The phase timeline on the job detail page shows which phase is active and the cumulative fill rate at each stage."
       },
       {
         question: "Why does the pipeline use multiple phases instead of a single AI call?",
@@ -2636,7 +2910,7 @@ var sections6 = [
     content: [
       {
         type: "paragraph",
-        text: "The fastest phase (~30% of cells in seconds). For each document x each schema field, the system checks if the cell can be filled from existing extracted data. **No AI calls** (except rare Haiku fallback for ambiguous lookups)."
+        text: "The fastest phase (~30% of cells in seconds). For each document x each schema field, the system checks if the cell can be filled from existing extracted data. **No AI calls** (except rare Haiku fallback for ambiguous lookups). Phase 1 is the workhorse of cost efficiency \u2014 it fills a large portion of the grid using pre-computed graph matches and deterministic lookups at near-zero cost. As your Field Registry grows from processing more documents, Phase 1 fill rates steadily improve."
       },
       {
         type: "param-table",
@@ -2681,6 +2955,10 @@ var sections6 = [
         type: "paragraph",
         text: "The resolution strategies execute in a fixed order: registry transfer first, then raw extraction mapping, then the 3-tier lookup cascade, and finally deterministic compute (formulas like `Total = Unit Price x Quantity`). Each strategy only attempts to fill cells that are still empty after the previous strategy ran. This ordering ensures that the highest-confidence method always gets priority."
       },
+      {
+        type: "paragraph",
+        text: `For example, consider an invoice with a "Vendor Name" field. The system first checks the Field Registry for a direct transfer \u2014 if "Vendor Name" was extracted from a previous document and promoted to Tier 1, it resolves instantly at 0.85+ confidence. If no registry match exists, the raw extraction mapping looks for a semantically equivalent field in the document's extracted data (e.g., "supplier_name"). If that also misses, the 3-tier lookup cascade checks the reference table: exact normalization first (0.95), then fuzzy token overlap (~0.70), then AI fallback (0.50). Only if all four strategies fail does the cell pass to Phase 2 for AI extraction.`
+      },
       {
         type: "callout",
         text: "Phase 1 fill rates improve over time as your Field Registry grows. The more documents you process, the richer the registry becomes, and the more cells Phase 1 can resolve without AI \u2014 reducing both cost and latency for every subsequent job."
@@ -2723,7 +3001,7 @@ var sections6 = [
     content: [
       {
         type: "paragraph",
-        text: "An AI agent reviews the grid's gap patterns and produces a typed strategy:"
+        text: "An AI agent reviews the grid's gap patterns and produces a typed strategy for each remaining empty cell. The agent uses Anthropic Claude Sonnet to analyze the source document alongside the schema field definitions, any already-resolved values from Phase 1, and reference table codes when available. This context-aware approach allows the AI to use related extracted values as clues for finding dependent data points."
       },
       {
         type: "paragraph",
@@ -2763,7 +3041,7 @@ var sections6 = [
       },
       {
         type: "paragraph",
-        text: "Phase 2 processes documents with grouped extraction calls \u2014 schema fields are divided into batches of up to 10 fields per call to balance extraction quality with throughput. For each document, the agent sends the document text along with the schema field definitions and any already-resolved values from Phase 1 as context. This context-aware approach means the AI can use related values (like a contract start date) to more accurately extract dependent values (like the end date)."
+        text: 'Phase 2 processes documents with grouped extraction calls \u2014 schema fields are divided into batches of up to 10 fields per call to balance extraction quality with throughput. For each document, the agent sends the document text along with the schema field definitions and any already-resolved values from Phase 1 as context. This context-aware approach means the AI can use related values (like a contract start date) to more accurately extract dependent values (like the end date). For example, if Phase 1 resolved "Contract Start Date" to 2025-01-15 via a registry transfer, and the "Contract End Date" cell is still empty, the agent receives the start date as context and can search the document for a corresponding end date with higher precision \u2014 producing a more accurate result than extracting the end date in isolation.'
       },
       {
         type: "paragraph",
@@ -2812,7 +3090,7 @@ var sections6 = [
     content: [
       {
         type: "paragraph",
-        text: "Cross-field sanity checks. Flags are **informational only** \u2014 they never block output but help you prioritize review:"
+        text: "Cross-field sanity checks and re-resolution. Phase 3 performs two critical tasks: it re-runs the reference table lookup cascade on values produced by Phase 2 to normalize free-text AI output to your canonical codes, and it runs informational validation checks across related fields. Flags are **informational only** \u2014 they never block output but help you prioritize review:"
       },
       {
         type: "paragraph",
@@ -2857,6 +3135,10 @@ var sections6 = [
         type: "paragraph",
         text: "Validation flags are designed to surface the most impactful issues first. The **low_confidence_outlier** flag is particularly useful \u2014 it highlights cells where the system is uncertain in an otherwise high-confidence row, pointing you to the exact cells most likely to contain errors. For large runs with hundreds of documents, filtering by flags and reviewing those cells first can reduce your review time by 80% or more."
       },
+      {
+        type: "paragraph",
+        text: "What gets flagged and why depends on cross-field relationships, not just individual values. A **date_sanity** flag fires when temporal fields contradict each other \u2014 for example, a contract end date that falls before the start date, or a signature date after the effective date. An **amount_mismatch** flag fires when a computed total deviates more than 20% from the product of its component values (e.g., monthly rent times term length versus total contract value). The **unexpected_empty** flag fires when a field that appears in over 80% of documents in your registry is missing from this particular document, suggesting the AI may have missed it rather than it being genuinely absent."
+      },
       {
         type: "callout",
         text: "Validation flags never modify cell values. They are purely informational annotations that help you prioritize review. The actual cell value and confidence score remain unchanged by Phase 3 flagging."
@@ -2898,7 +3180,7 @@ var sections6 = [
     content: [
       {
         type: "paragraph",
-        text: "Context-aware gap filling. For each empty cell or low-confidence value, AI re-reads the original document with the field instruction and full grid context. This focused approach often finds values missed in earlier phases."
+        text: "Context-aware gap filling and deterministic transforms. Phase 4 serves two purposes: for each empty cell or low-confidence value, AI re-reads the original document with the field instruction and full grid context to find values missed in earlier phases. It also applies deterministic transforms to all cell values \u2014 ISO code normalization, date format standardization, unit conversion \u2014 and evaluates format constraints (regex patterns) with configurable mismatch behaviors. The modifier pipeline runs in a fixed order: format transforms first, then alias mapping, then max_length truncation."
       },
       {
         type: "paragraph",
@@ -2914,7 +3196,7 @@ var sections6 = [
       },
       {
         type: "callout",
-        text: "Phase 4 respects the **confidence gate**: it can only fill empty cells or upgrade cells below the confidence threshold. High-confidence values from Phase 1 are permanently protected."
+        text: "Phase 4 respects the **confidence gate**: it can only fill empty cells or upgrade cells below the confidence threshold. High-confidence values from Phase 1 are permanently protected. Original values are always preserved in the `original_extractions` table for audit, regardless of whether format constraints clear, flag, or replace them."
       }
     ],
     related: [
@@ -2925,15 +3207,15 @@ var sections6 = [
     faq: [
       {
         question: "What does Phase 4 Re-read do?",
-        answer: "Phase 4 performs context-aware gap filling by re-reading the original document with field instructions and full grid context for each empty or low-confidence cell."
+        answer: "Phase 4 performs context-aware gap filling by re-reading the original document with field instructions and full grid context for each empty or low-confidence cell. Because it has access to all values resolved in earlier phases, it can use surrounding data as clues \u2014 for example, using a resolved start date to locate the corresponding end date more accurately."
       },
       {
         question: "Can Phase 4 overwrite high-confidence values?",
-        answer: "No. Phase 4 respects the confidence gate \u2014 it can only fill empty cells or upgrade cells below the confidence threshold. High-confidence values from earlier phases are permanently protected."
+        answer: "No. Phase 4 respects the confidence gate \u2014 it can only fill empty cells or upgrade cells below the confidence threshold. High-confidence values from earlier phases are permanently protected. This is the single most important pipeline rule, ensuring that reliable lookup results are never replaced by lower-confidence AI extractions."
       },
       {
         question: "What else happens in Phase 4 besides gap filling?",
-        answer: "Phase 4 also applies deterministic transforms (ISO codes, dates, units), evaluates format constraints (regex validation), and runs the modifier pipeline (format, alias, max_length). Original values are preserved for audit."
+        answer: "Phase 4 also applies deterministic transforms (ISO codes, dates, units), evaluates format constraints (regex validation), and runs the modifier pipeline in a fixed order: format transforms first, then alias mapping, then max_length truncation. Constraint evaluation happens after all modifiers. Original values are always preserved in the original_extractions table for audit, regardless of whether constraints clear, flag, or replace them."
       }
     ],
     mentions: ["Phase 4", "re-read", "gap filling", "confidence gate", "targeted extraction"]
@@ -2953,7 +3235,7 @@ var sections6 = [
       },
       {
         type: "paragraph",
-        text: "The job detail page provides: a **progress bar** with fill rate, a **phase timeline**, the **strategy panel** (agent actions), a **filter bar** (Show All / Clean / Flagged), and **CSV export** (clean or full with metadata)."
+        text: "The job detail page provides: a **progress bar** with fill rate, a **phase timeline**, the **strategy panel** (agent actions), a **filter bar** (Show All / Clean / Flagged), and **CSV export** (clean or full with metadata). The strategy yield breakdown shows how cells were distributed across resolution methods \u2014 registry transfer, raw extraction mapping, lookup cascade, deterministic compute, LLM extract, and bypass \u2014 giving you a clear picture of pipeline efficiency for each run."
       },
       {
         type: "paragraph",
@@ -2969,7 +3251,7 @@ var sections6 = [
       },
       {
         type: "callout",
-        text: "The full CSV export includes metadata columns for each field: confidence score, resolution type, phase number, and reasoning trace. Use this export for audit trails or to analyze extraction performance across your document corpus."
+        text: "The full CSV export includes metadata columns for each field: confidence score, resolution type, phase number, and reasoning trace. Use this export for audit trails or to analyze extraction performance across your document corpus. The clean export omits metadata and includes only the extracted values, ready for direct import into downstream systems."
       }
     ],
     related: [
@@ -2980,15 +3262,15 @@ var sections6 = [
     faq: [
       {
         question: "What do the colored dots in the results grid mean?",
-        answer: "Each dot indicates how a cell was resolved: blue = graph match, purple = computed, teal = agent transfer, indigo = agent extract, amber = lookup."
+        answer: "Each dot indicates how a cell was resolved: blue = graph match (Phase 1 registry transfer, highest reliability), purple = computed (deterministic formula), teal = agent transfer (copy from equivalent field), indigo = agent extract (AI read from document), amber = lookup result or format flag. A grid dominated by blue and purple dots typically requires minimal review."
       },
       {
         question: "Can I export extraction results?",
-        answer: "Yes. Use CSV export from the job detail page. You can export clean data only or full data with metadata including confidence scores and resolution types."
+        answer: "Yes. Use CSV export from the job detail page. The clean export includes only extracted values, ready for direct import into downstream systems. The full export includes metadata columns for each field: confidence score, resolution type, phase number, and reasoning trace \u2014 useful for audit trails or analyzing extraction performance across your document corpus."
       },
       {
         question: "What is the most efficient way to review a large extraction run?",
-        answer: "Start with the Flagged filter to address cells with validation warnings, low confidence, or format mismatches. Then spot-check a random sample of Clean rows. Focus corrections on recurring field-level patterns rather than individual cells."
+        answer: "Start with the Flagged filter to address cells with validation warnings, low confidence, or format mismatches. Then spot-check a random sample of Clean rows. Focus corrections on recurring field-level patterns rather than individual cells. If you find a field that is consistently wrong, update its manual instruction or reference table in the schema rather than correcting cells one by one \u2014 this improves future runs as well."
       }
     ],
     mentions: [
@@ -3008,7 +3290,7 @@ var sections6 = [
     content: [
       {
         type: "paragraph",
-        text: "Every cell carries detailed provenance. Hover a cell for confidence; click for full detail."
+        text: "Every cell carries detailed provenance metadata that makes every extracted value auditable and explainable. Hover a cell for a quick confidence score glance; click it to expand the full provenance panel showing the resolution type, pipeline phase, reasoning trace, and source document references. This transparency is essential for building trust in automated extraction \u2014 you can always understand exactly how and why the platform produced a specific value."
       },
       {
         type: "paragraph",
@@ -3049,6 +3331,17 @@ var sections6 = [
         type: "paragraph",
         text: "Confidence scores follow predictable patterns by resolution type. Graph matches from Phase 1 typically score 0.7-0.95 because they are derived from verified registry data. Reference table lookups score 0.95 for exact normalization matches, ~0.70 for fuzzy matches, and 0.50 for AI fallback. Agent-derived values from Phase 2 generally score 0.5-0.9 depending on the clarity of the source document and the specificity of the extraction instruction."
       },
+      {
+        type: "list",
+        ordered: false,
+        items: [
+          "**0.90-0.95** \u2014 Tier 1 lookup or exact registry transfer. Highest reliability; safe to trust without review in most workflows.",
+          "**0.70-0.89** \u2014 Strong graph match or fuzzy registry transfer. Generally reliable; spot-check a sample to validate.",
+          "**0.50-0.69** \u2014 AI extraction or fuzzy lookup result. Review recommended; the system found a plausible value but certainty is moderate.",
+          "**0.30-0.49** \u2014 Low-confidence AI extraction. The source document was ambiguous or the field instruction was vague. Always review manually.",
+          "**Below 0.30** \u2014 Very low confidence. The value is likely a best guess. Consider updating the schema instruction or adding a reference table to improve future runs."
+        ]
+      },
       {
         type: "paragraph",
         text: "Use confidence scores to set your review threshold. Cells above 0.8 are generally reliable and can be trusted without manual verification for most use cases. Cells between 0.5 and 0.8 warrant a quick check. Cells below 0.5 should always be reviewed manually. You can use the full CSV export to filter and sort by confidence, making it easy to batch-review low-confidence cells efficiently."
@@ -3095,7 +3388,7 @@ var sections6 = [
     content: [
       {
         type: "paragraph",
-        text: "Click any cell to edit its value. Corrections are logged with the original value, timestamp, and user. Choose a propagation scope: `this_document_only` or `all_similar` (same field + method + source field across all documents). Corrections feed back as training signals for future runs."
+        text: "Click any cell to edit its value. Corrections are logged with the original value, timestamp, and user. Choose a propagation scope: `this_document_only` or `all_similar` (same field + method + source field across all documents). Corrections feed back as training signals for future runs, helping the system learn from your edits and improve accuracy over time. When you correct a value, the system records both the original AI-extracted value and your correction, creating a complete audit trail that is preserved even after subsequent jobs run."
       },
       {
         type: "paragraph",
@@ -3111,7 +3404,7 @@ var sections6 = [
       },
       {
         type: "callout",
-        text: "Corrections with **all_similar** propagation apply instantly across all documents in the run. Use this for systematic errors like wrong reference table mappings, but verify the preview count before confirming \u2014 the system shows how many cells will be affected."
+        text: "Corrections with **all_similar** propagation apply instantly across all documents in the run. Use this for systematic errors like wrong reference table mappings, but verify the preview count before confirming \u2014 the system shows how many cells will be affected. For recurring field-level errors, consider updating the schema instruction or reference table rather than correcting cells individually across multiple runs."
       }
     ],
     related: [
@@ -3122,15 +3415,15 @@ var sections6 = [
     faq: [
       {
         question: "How do I correct an extracted value?",
-        answer: "Click any cell in the results grid to edit its value. Choose propagation scope: this_document_only (single cell) or all_similar (same field + method across all documents)."
+        answer: "Click any cell in the results grid to edit its value. Choose propagation scope: this_document_only (single cell) or all_similar (same field + method across all documents). When using all_similar, the system shows a preview count of how many cells will be affected before you confirm \u2014 always verify this count to avoid unintended bulk changes."
       },
       {
         question: "Do corrections improve future extractions?",
-        answer: "Yes. Corrections feed back as training signals for future runs, helping the system learn from your corrections and improve accuracy over time."
+        answer: "Yes. Corrections feed back as training signals for future runs, helping the system learn from your corrections and improve accuracy over time. For maximum impact, correct the root cause rather than individual symptoms \u2014 update the schema field instruction or reference table so that future runs resolve correctly without manual intervention."
       },
       {
         question: "Is there an audit trail for corrections?",
-        answer: "Yes. Every correction logs the original value, the corrected value, the user who made the change, and the timestamp. This audit history is preserved and included in full metadata CSV exports."
+        answer: "Yes. Every correction logs the original value, the corrected value, the user who made the change, and the timestamp. This audit history is preserved even after subsequent jobs run and is included in full metadata CSV exports. Downstream systems can use this data to distinguish between AI-extracted and human-corrected values."
       }
     ],
     mentions: [
@@ -3193,9 +3486,25 @@ var sections7 = [
         type: "paragraph",
         text: "Use link keys whenever your documents share identifying information that should connect them. For best results, ensure your field names follow clear naming conventions \u2014 this maximizes the hit rate of the automatic classifier and minimizes the need for manual overrides."
       },
+      {
+        type: "paragraph",
+        text: 'High-frequency entity exclusion is an important safeguard. If an entity value appears in more than 30% of all documents \u2014 for example, a generic department name like "Operations" or a common currency code like "USD" \u2014 it is automatically excluded from case formation. Without this filter, a single high-frequency value would pull most documents into one enormous case, making the grouping meaningless. The 30% threshold strikes a balance between connecting genuinely related documents and avoiding over-connection from generic values.'
+      },
+      {
+        type: "list",
+        items: [
+          "Identity: company names, supplier names, person names \u2014 connects documents referencing the same party",
+          "Transaction: contract numbers, PO numbers, invoice numbers \u2014 connects documents in the same transaction chain",
+          "Reference: project codes, cost centers, shared IDs \u2014 connects documents under the same organizational grouping",
+          "Auto-classified by field name patterns (e.g., company_name, invoice_number)",
+          "AI classifier handles ambiguous fields that heuristics cannot resolve",
+          "High-frequency entities (>30% of documents) excluded automatically",
+          "Manual overrides available in the Field Registry"
+        ]
+      },
       {
         type: "callout",
-        text: "Link key classification runs automatically when new fields appear in the registry. You do not need to trigger it manually \u2014 just upload documents and the system handles the rest."
+        text: "Link key classification runs automatically when new fields appear in the registry. You do not need to trigger it manually \u2014 just upload documents and the system handles the rest. Manual overrides in the Field Registry take precedence over automatic classifications and persist across future jobs."
       }
     ],
     related: [
@@ -3248,9 +3557,24 @@ var sections7 = [
         type: "paragraph",
         text: "For best results, ensure your source documents contain consistent identifiers. The pipeline handles minor variations automatically, but wildly inconsistent naming (e.g., abbreviations vs. full legal names) may require manual link key tuning in the Field Registry."
       },
+      {
+        type: "paragraph",
+        text: 'A typical entity linking workflow looks like this: you upload a batch of invoices, contracts, and purchase orders. The pipeline extracts link key values \u2014 vendor names, PO numbers, contract references \u2014 normalizes them, and builds the graph. An invoice referencing "ACME Corp" and a contract referencing "Acme Corporation" both resolve to the same entity node after normalization, so the two documents become connected. If a purchase order also references the same vendor, all three documents end up in the same case.'
+      },
+      {
+        type: "list",
+        items: [
+          "Runs automatically after document extraction \u2014 no manual trigger required",
+          "Normalizes values: lowercasing, suffix stripping (Ltd, Inc, Corp, GmbH), whitespace normalization",
+          "Builds a bipartite graph: document nodes connected to entity nodes via link key edges",
+          "Connected components in the graph become the basis for case formation",
+          "Incremental: new documents extend the existing graph rather than rebuilding it",
+          "Handles minor naming variations automatically; wildly inconsistent names may need manual tuning"
+        ]
+      },
       {
         type: "callout",
-        text: "Entity linking is incremental \u2014 when new documents arrive, the pipeline extends the existing graph rather than rebuilding it from scratch. Existing cases grow as new connections are discovered."
+        text: "Entity linking is incremental \u2014 when new documents arrive, the pipeline extends the existing graph rather than rebuilding it from scratch. Existing cases grow as new connections are discovered. This means your cases stay up-to-date without manual intervention as new documents flow into the workspace."
       }
     ],
     related: [
@@ -3321,11 +3645,30 @@ var sections7 = [
       },
       {
         type: "paragraph",
-        text: "Cases display an AI-generated **case label** as the primary title and include anomaly count badges in the header. Evidence and Timeline tabs support export to MD, CSV, and JSON."
+        text: 'Cases display an AI-generated **case label** as the primary title and include anomaly count badges in the header. The label is generated by analyzing the documents and entities in the case to produce a human-readable summary \u2014 for example, "ACME Corp Invoice #4521 &rarr; PO #8890". You can rename a case manually if the AI label does not capture the right context. Evidence and Timeline tabs support export to MD, CSV, and JSON for offline review or compliance reporting.'
       },
       {
         type: "paragraph",
-        text: "Additional case operations: **merge** multiple cases into one, **split** a case into separate groups, **pin** or remove documents from a case, and **confirm** or **reject** individual linking edges."
+        text: "Additional case operations: **merge** multiple cases into one, **split** a case into separate groups, **pin** or remove documents from a case, and **confirm** or **reject** individual linking edges. Merging is useful when two cases refer to the same real-world transaction but were not connected by the linking pipeline \u2014 for example, when a vendor uses slightly different names across documents. Splitting lets you break apart a case that was over-connected by a high-frequency entity value. Edge confirmation and rejection feed back into the linking model, improving future case formation accuracy."
+      },
+      {
+        type: "paragraph",
+        text: "Cases follow a lifecycle: **discovered** when the linking engine first identifies a cluster, **confirmed** when a reviewer validates the grouping, **active** during ongoing work, and **resolved** when all documents have been reviewed and processed. The lifecycle status is visible on the cases list page and can be updated from the case detail header. Filtering by lifecycle status makes it easy to focus on cases that need attention."
+      },
+      {
+        type: "list",
+        items: [
+          "AI-generated case labels with manual rename option",
+          "Four tabs: Overview, Anomalies (Advanced mode), Evidence, and Timeline",
+          "Merge, split, pin, remove, confirm, and reject operations",
+          "Lifecycle tracking: discovered &rarr; confirmed &rarr; active &rarr; resolved",
+          "Anomaly count badges in the case header for quick triage",
+          "Export Evidence and Timeline to MD, CSV, or JSON"
+        ]
+      },
+      {
+        type: "callout",
+        text: "Case formation runs automatically after entity linking completes. You do not need to create cases manually \u2014 the system discovers them from the document-entity graph. Use merge, split, and edge operations to refine cases when the automatic grouping needs adjustment."
       }
     ],
     related: [
@@ -3374,9 +3717,24 @@ var sections7 = [
         type: "paragraph",
         text: "Most teams use the graph view during initial workspace setup to verify that linking is producing sensible clusters. Once you are confident in your link key configuration, the list view is more practical for day-to-day case review and triage."
       },
+      {
+        type: "paragraph",
+        text: "The graph view is particularly useful during onboarding. When you first upload documents to a workspace, the graph gives you immediate visual feedback on whether your link key configuration is producing sensible clusters. If you see one massive cluster with everything connected, a high-frequency entity value may be acting as a bridge \u2014 check the Field Registry and exclude or reclassify the offending field. If you see many disconnected single-document nodes, your documents may lack shared identifiers, or the normalization rules may need adjustment."
+      },
+      {
+        type: "list",
+        items: [
+          "D3-force layout with distinct visual styles for document and entity nodes",
+          "Hover to highlight connections and trace document-entity relationships",
+          "Toggle between graph view and list view from the Cases page",
+          "Case templates auto-discovered after 3+ cases share the same document type pattern",
+          "Templates include a match threshold controlling how closely a case must match",
+          "Missing document type anomalies raised when a case does not match its template"
+        ]
+      },
       {
         type: "callout",
-        text: "Templates are auto-discovered \u2014 you do not need to define them manually. The system analyzes existing cases and proposes templates when it detects at least 3 cases sharing the same document type pattern."
+        text: "Templates are auto-discovered \u2014 you do not need to define them manually. The system analyzes existing cases and proposes templates when it detects at least 3 cases sharing the same document type pattern. You can also trigger template discovery manually from the API via POST /cases/templates/discover."
       }
     ],
     related: [
@@ -3453,9 +3811,23 @@ var sections7 = [
         type: "paragraph",
         text: "Use anomaly detection to surface data quality issues that would otherwise require manual comparison across documents. For best results, configure case templates so the **Missing Document Type** detector (D4) can flag incomplete cases. Most teams find that D2 (Field Conflict) and D3 (Duplicate Key Divergence) catch the highest-value issues in procurement and financial workflows."
       },
+      {
+        type: "paragraph",
+        text: "A typical workflow starts on the cases list page, where anomaly count badges give you an at-a-glance view of which cases need attention. Click into a case with anomalies, switch to the **Anomalies** tab, and use the severity filter pills to focus on critical issues first. Each anomaly card explains the affected fields and the specific violation detected. Dismiss false positives with the dismiss button \u2014 they remain accessible via the **show dismissed** toggle if you need to revisit them later."
+      },
+      {
+        type: "list",
+        items: [
+          "D1 \u2014 Validation Cluster: multiple validation failures concentrated in the same document or field group",
+          "D2 \u2014 Field Conflict: contradictory values for the same field across documents in a case",
+          "D3 \u2014 Duplicate Key Divergence: shared link key but differing values on fields that should match",
+          "D4 \u2014 Missing Document Type: case template expects a document type that is absent",
+          "D5 \u2014 Value Reuse: identical values across unrelated fields, suggesting copy-paste or extraction errors"
+        ]
+      },
       {
         type: "callout",
-        text: "Anomaly detection requires **Advanced mode** to be enabled. In Simple mode, anomalies are still computed but not displayed in the case detail page."
+        text: "Anomaly detection requires **Advanced mode** to be enabled. In Simple mode, anomalies are still computed but not displayed in the case detail page. Toggle Advanced mode from the sidebar to access the full anomaly workflow."
       }
     ],
     related: [
@@ -3466,11 +3838,11 @@ var sections7 = [
     faq: [
       {
         question: "What anomalies does Talonic detect?",
-        answer: "Five structural patterns: validation clusters, field conflicts, duplicate key divergence, missing document types, and value reuse. Each is surfaced as a dismissable card on the case detail page."
+        answer: "Five structural patterns: validation clusters (D1), field conflicts (D2), duplicate key divergence (D3), missing document types (D4), and value reuse (D5). Each is surfaced as a dismissable card on the case detail page. D2 and D3 are the highest-value detectors for procurement and financial workflows \u2014 they catch contradictory values across related documents, such as mismatched amounts between an invoice and its corresponding purchase order."
       },
       {
         question: "Do anomalies update automatically when cases change?",
-        answer: "Yes. The detection engine re-runs whenever case membership changes \u2014 documents added or removed, cases merged or split. Anomaly badges in the case header update in real time."
+        answer: "Yes. The detection engine re-runs whenever case membership changes \u2014 documents added or removed, cases merged or split. Anomaly badges in the case header update in real time. Each detector operates independently, so a single case can trigger multiple anomaly types simultaneously. This continuous re-evaluation ensures that anomalies stay current as your document corpus evolves."
       },
       {
         question: "Can I dismiss anomalies?",
@@ -3515,9 +3887,26 @@ var sections7 = [
         type: "paragraph",
         text: "The checksum validator (S7) uses a parameterized factory pattern \u2014 it accepts a checksum algorithm name and applies the corresponding verification logic. Supported algorithms include Luhn (credit card numbers), ABA (bank routing numbers), IBAN (international bank accounts), and ISBN (book identifiers). For best results, ensure your schema fields are typed correctly so the engine knows which checksum to apply."
       },
+      {
+        type: "paragraph",
+        text: "A typical evidence validation workflow starts automatically after extraction and linking. You navigate to a case, open the **Evidence** tab, and immediately see colored badges next to each field value. Red badges indicate failures that need attention \u2014 click a badge to see which validator fired and what the expected format or value was. Use the filter bar to narrow results by status (pass/fail/warning), by document, by category, or by free-text search. Group-by-document collapsible sections let you review one document at a time within a case."
+      },
+      {
+        type: "list",
+        items: [
+          "S1 \u2014 Free-text spillover: unstructured text leaked from adjacent content",
+          "S2 \u2014 Empty value: required field is blank or whitespace-only",
+          "S3 \u2014 Email/URL misclassification: value looks like an email or URL in the wrong field type",
+          "S4 \u2014 Name in URL field: person or company name extracted into a URL-typed field",
+          "S5 \u2014 Alpha in numeric field: alphabetic characters in a numeric-only field",
+          "S6 \u2014 Cross-field duplicate: identical value in multiple unrelated fields on the same document",
+          "S7 \u2014 Checksum validation: Luhn, ABA, IBAN, ISBN verification via parameterized factory",
+          "Domain packs: industry-specific rules (e.g., freight: DOT numbers, MC numbers)"
+        ]
+      },
       {
         type: "callout",
-        text: "Evidence validation results are stored in a separate `evidence_validation_results` table keyed by (document_id, entity_id, field_key) \u2014 not in the extraction or linking tables."
+        text: "Evidence validation results are stored separately from extraction and linking data. This means you can re-run validation independently without re-extracting documents. Results are keyed by (document_id, entity_id, field_key) for precise field-level tracking."
       }
     ],
     related: [
@@ -3572,9 +3961,24 @@ var sections8 = [
         type: "paragraph",
         text: "For best results, create one template per downstream consumer. If your finance team and operations team need different column subsets from the same schema, define two templates rather than manually reconfiguring each export. Most teams version their templates alongside schema changes to maintain backward compatibility with existing integrations."
       },
+      {
+        type: "paragraph",
+        text: "To create a dataset template, navigate to **Data Products &rarr; Dataset Templates** and click **New Template**. Select the user schema that defines the field set, then configure column mappings to rename, reorder, or exclude fields from the output. Add default transforms \u2014 such as date formatting to ISO 8601, currency normalization to a base currency, or unit conversion \u2014 that run automatically during assembly. Save the template and it becomes available to any team member when creating a new job or assembly."
+      },
+      {
+        type: "list",
+        items: [
+          "Linked to a user schema \u2014 fields are inherited automatically as the schema evolves",
+          "Column mappings: rename, reorder, or exclude fields from the final output",
+          "Default transforms: date formatting, currency normalization, unit conversion",
+          "Independent versioning: evolve the template without affecting existing data products",
+          "Workspace-scoped: any team member can create, edit, or use any template",
+          "One template per downstream consumer is the recommended pattern"
+        ]
+      },
       {
         type: "callout",
-        text: "Dataset templates are workspace-scoped. Any team member can create, edit, or use a template \u2014 there is no per-user ownership restriction."
+        text: "Dataset templates are workspace-scoped. Any team member can create, edit, or use a template \u2014 there is no per-user ownership restriction. Version your templates alongside schema changes to maintain backward compatibility with existing integrations and downstream consumers."
       }
     ],
     related: [
@@ -3627,9 +4031,24 @@ var sections8 = [
         type: "paragraph",
         text: "Use assemblies whenever you need a repeatable, auditable output for downstream systems or stakeholders. Most teams create one assembly per reporting period or delivery cycle. Because assemblies reference a template, you can regenerate the same output shape from different document sets without reconfiguring columns or transforms each time."
       },
+      {
+        type: "paragraph",
+        text: "Assemblies also support incremental updates. When new documents arrive in a source that is already part of an assembly, you can regenerate the assembly to include them without reconfiguring anything. The system re-applies the template, pulls the updated document set, and produces a fresh output. Previous assembly versions are retained for comparison, so you can track how your dataset evolves over successive runs."
+      },
+      {
+        type: "list",
+        items: [
+          "Select a dataset template and one or more document sources to create an assembly",
+          "Column mappings and transforms from the template are applied automatically",
+          "Full traceability from every output row back to its source document",
+          "Incremental updates \u2014 regenerate to include newly arrived documents",
+          "Previous assembly versions retained for comparison and auditing",
+          "Export the assembled dataset as CSV with leading zero preservation"
+        ]
+      },
       {
         type: "callout",
-        text: "Assemblies are the recommended way to produce production datasets. They provide a single audit trail from source documents through extraction, resolution, and validation to the final output."
+        text: "Assemblies are the recommended way to produce production datasets. They provide a single audit trail from source documents through extraction, resolution, and validation to the final output. If your workflow requires repeatable, auditable deliverables, assemblies eliminate the need for manual export configuration on every run."
       }
     ],
     related: [
@@ -3644,11 +4063,11 @@ var sections8 = [
       },
       {
         question: "Why should I use assemblies for production data?",
-        answer: "Assemblies provide a single audit trail from source documents through extraction, resolution, and validation to the final output, making them the recommended approach for production datasets."
+        answer: "Assemblies provide a single audit trail from source documents through extraction, resolution, and validation to the final output, making them the recommended approach for production datasets. Unlike ad-hoc exports, assemblies are versioned and reproducible \u2014 you can regenerate the same output shape from different document sets without reconfiguring columns or transforms. Previous versions are retained automatically, so you can compare outputs across time periods and demonstrate compliance with audit requirements."
       },
       {
         question: "Can an assembly pull from multiple sources?",
-        answer: "Yes. An assembly can combine documents from any number of sources \u2014 uploaded files, connected drives, email attachments, and more \u2014 into a single structured dataset."
+        answer: "Yes. An assembly can combine documents from any number of sources \u2014 uploaded files, connected drives, email attachments, and more \u2014 into a single structured dataset. This is particularly useful for cross-functional reporting where data arrives through different channels. For example, you can combine invoices from a Google Drive connector, purchase orders uploaded manually, and contracts ingested via the API into a single unified procurement dataset."
       }
     ],
     mentions: [
@@ -3693,7 +4112,22 @@ var sections8 = [
       },
       {
         type: "paragraph",
-        text: "ID rules are persisted before generating IDs. Navigate to a data product detail page and use **Apply ID Rules** to generate or **Regenerate IDs** to refresh."
+        text: "ID rules are persisted before generating IDs. Navigate to a data product detail page and use **Apply ID Rules** to generate or **Regenerate IDs** to refresh. The generation process evaluates each row against the configured rules: it reads the source field value, applies the resolution map if one exists, prepends the prefix, and writes the resulting ID. If the source field is empty, the dispenser walks the fallback chain in order until it finds a non-empty value. If all fields in the chain are empty, a prefix-less sequential ID is assigned so no row is left without an identifier."
+      },
+      {
+        type: "paragraph",
+        text: "A typical workflow starts by choosing a high-cardinality field as the source \u2014 contract numbers, invoice IDs, or purchase order references work well because they are unique per document. Next, configure a fallback chain with one or two alternative fields (e.g., document name, then upload date) so the dispenser always has a value to work with. Finally, add a resolution map if your source data contains variant spellings of the same entity. The map normalizes these variants before they become part of the ID, preventing duplicate IDs for rows that refer to the same real-world record."
+      },
+      {
+        type: "list",
+        items: [
+          "Source field: the primary field used to derive each row ID",
+          "Fallback chain: ordered list of alternative fields tried when the source is empty",
+          "Resolution map: key-value lookup that normalizes values before ID generation",
+          "Prefix: optional string prepended to every generated ID for namespacing",
+          "Deterministic: same rules + same data always produces the same IDs",
+          "Non-destructive: regenerating IDs only updates the ID column, all other values remain unchanged"
+        ]
       },
       {
         type: "paragraph",
@@ -3738,7 +4172,7 @@ var sections8 = [
     content: [
       {
         type: "paragraph",
-        text: "Each data product can generate a **share token** \u2014 a public URL that grants read access without authentication. The delivery website renders three toggle views:"
+        text: "Each data product can generate a **share token** \u2014 a public URL that grants read access without authentication. Share tokens are ideal for distributing finalized datasets to external stakeholders, auditors, or downstream teams that do not have Talonic accounts. The token is scoped to a single data product and can be revoked at any time from the data product detail page without affecting other shared links. The delivery website renders three toggle views:"
       },
       {
         type: "param-table",
@@ -3762,11 +4196,30 @@ var sections8 = [
       },
       {
         type: "paragraph",
-        text: "The delivery website includes the Talonic logo, per-run selection, and **CSV export** with leading zero and long number preservation (values are not coerced to numbers)."
+        text: "The delivery website includes the Talonic logo, per-run selection, and **CSV export** with leading zero and long number preservation (values are not coerced to numbers). When multiple runs exist for the same data product, the delivery website lets viewers switch between runs using a dropdown selector, making it easy to compare outputs across time periods or pipeline configurations. CSV downloads preserve the exact cell values shown in the active view \u2014 including leading zeros on codes like ZIP codes and account numbers \u2014 so recipients can open the file in Excel or Google Sheets without data loss."
+      },
+      {
+        type: "paragraph",
+        text: "**Auto-review** and **auto-resolve singles** are available to streamline the approval process: auto-review uses LLM to propose approve/reject decisions, and auto-resolve singles automatically accepts fields with only one candidate value. Together, these features can reduce the manual review burden by 60-80% on typical workloads. Auto-review examines each pending field against the extraction context and proposes a decision with a confidence indicator, while auto-resolve singles handles the common case where a field has exactly one candidate \u2014 no ambiguity to resolve, so automatic acceptance is safe."
       },
       {
         type: "paragraph",
-        text: "**Auto-review** and **auto-resolve singles** are available to streamline the approval process: auto-review uses LLM to propose approve/reject decisions, and auto-resolve singles automatically accepts fields with only one candidate value."
+        text: "To set up sharing, navigate to the data product detail page and click **Generate Share Link**. The system creates a unique token and displays the public URL. You can copy this URL and send it to anyone \u2014 no Talonic login is required to view the delivery website. If you need to revoke access, delete the share token from the same page. The data product itself is unaffected; only the public URL stops working."
+      },
+      {
+        type: "list",
+        items: [
+          "Three toggle views: Structured Data (raw extraction), Resolved (post-normalization), and Data Product (final assembled output)",
+          "Per-run selector for comparing outputs across pipeline runs or time periods",
+          "CSV export with leading zero and long number preservation \u2014 values are never coerced to numeric types",
+          "Auto-review with LLM-proposed approve/reject decisions for pending fields",
+          "Auto-resolve singles for fields with exactly one candidate value",
+          "Share tokens are revocable and scoped to a single data product"
+        ]
+      },
+      {
+        type: "callout",
+        text: "Share tokens grant read-only access. Recipients can view and export data but cannot modify the data product, run new jobs, or access any other workspace resources. Revoke a token at any time from the data product detail page."
       }
     ],
     related: [
@@ -3822,9 +4275,24 @@ var sections9 = [
         type: "paragraph",
         text: "For best results, start with a small set of high-confidence rules and expand over time. Most teams begin with field format checks for critical identifiers (invoice numbers, dates, amounts) and add cross-field consistency rules as they learn their data patterns. Validation failures do not block extraction \u2014 they flag records for review."
       },
+      {
+        type: "paragraph",
+        text: "A typical setup workflow looks like this: run your first job, review the extraction results, and identify fields where errors are common. Navigate to **Validation &rarr; Checks** and create rules for those fields \u2014 a date format check on invoice_date, a value range check on total_amount, a cross-field consistency check that start_date precedes end_date. On subsequent jobs, Phase 3 evaluates every record against your active rules and flags failures for review in the Approval Queue."
+      },
+      {
+        type: "list",
+        items: [
+          "Field format: verify values match expected patterns (ISO dates, phone numbers with country codes, email addresses)",
+          "Value range: ensure numeric or date values fall within acceptable bounds",
+          "Cross-field consistency: compare two or more fields on the same record (e.g., start date before end date)",
+          "AI-proposed coherence rules: generated from patterns in completed job results, require explicit approval",
+          "Schema-scoped: rules on one schema do not affect other schemas",
+          "Non-blocking: validation failures flag records for review but do not prevent extraction"
+        ]
+      },
       {
         type: "callout",
-        text: "Validation checks are schema-scoped. Rules defined on one schema do not affect other schemas in the same workspace. This lets you tailor quality rules to each document type independently."
+        text: "Validation checks are schema-scoped. Rules defined on one schema do not affect other schemas in the same workspace. This lets you tailor quality rules to each document type independently. Start with a few high-confidence rules and expand as you learn your data patterns."
       }
     ],
     related: [
@@ -3876,9 +4344,25 @@ var sections9 = [
         type: "paragraph",
         text: "For best results, create golden samples from a representative mix of document types and complexity levels. Most teams maintain 5-10 golden samples per schema and re-run benchmarks after schema changes, instruction updates, or model upgrades to track quality trends over time."
       },
+      {
+        type: "paragraph",
+        text: "A typical benchmarking workflow starts after a schema change or model upgrade. Navigate to **Validation &rarr; Golden Samples**, select the samples you want to benchmark, and click **Run Benchmark**. The system re-extracts each document independently and compares every field against your known-correct values. The results page shows a per-field accuracy matrix with pass/fail indicators and AI judge verdicts explaining each comparison. Use this data to pinpoint fields that need schema instruction tuning or additional extraction context."
+      },
+      {
+        type: "list",
+        items: [
+          "Create golden samples by selecting a document and entering known-correct values for each field",
+          "Benchmark runs compare extraction results field-by-field against the golden sample baseline",
+          'AI judge evaluates semantic equivalence (e.g., "United States" matches "US" for country fields)',
+          "Per-field accuracy scores identify exactly which fields are underperforming",
+          "Maintain 5-10 golden samples per schema for representative coverage",
+          "Re-run benchmarks after schema changes, instruction updates, or model upgrades",
+          "Benchmark results are stored historically for tracking quality trends over time"
+        ]
+      },
       {
         type: "callout",
-        text: "Golden samples are not used during normal extraction \u2014 they exist solely for benchmarking. Changing a golden sample does not affect how documents are processed."
+        text: "Golden samples are not used during normal extraction \u2014 they exist solely for benchmarking. Changing a golden sample does not affect how documents are processed. This separation ensures that ground truth data remains a pure measurement tool without introducing bias into the extraction pipeline."
       }
     ],
     related: [
@@ -3925,9 +4409,25 @@ var sections9 = [
         type: "paragraph",
         text: "Approval gates integrate directly with the delivery pipeline. When a result passes all gates, a `result.approved` signal is emitted automatically. Bind this signal to a destination to create a fully automated flow from document upload through extraction, validation, approval, and delivery \u2014 no manual steps required for high-confidence results."
       },
+      {
+        type: "paragraph",
+        text: "A practical example: you configure an approval gate on your invoice schema with 90% confidence, 95% validation pass rate, and 80% field coverage. An invoice extraction scores 96% confidence, passes all validation checks, and has all fields populated. It clears all three gates and is auto-approved \u2014 a `result.approved` signal fires immediately. A second invoice scores 85% confidence. It fails the confidence gate and is routed to the Approval Queue for manual review. This two-track approach lets high-quality results flow through instantly while ensuring borderline cases get human attention."
+      },
+      {
+        type: "list",
+        items: [
+          "Minimum confidence: lowest acceptable extraction confidence score",
+          "Validation pass rate: minimum percentage of validation checks that must pass",
+          "Field coverage: minimum percentage of schema fields with non-empty values",
+          "All three gates must be cleared for auto-approval \u2014 any failure routes to manual review",
+          "Configured per schema for independent tuning per document type",
+          "Emits result.approved signal on auto-approval for delivery pipeline integration",
+          "Start conservative (high thresholds) and loosen as pipeline trust builds"
+        ]
+      },
       {
         type: "callout",
-        text: "Approval gates feed the delivery pipeline \u2014 bind a `result.approved` signal to a destination to only ship approved rows to your downstream systems."
+        text: "Approval gates feed the delivery pipeline \u2014 bind a `result.approved` signal to a destination to only ship approved rows to your downstream systems. Combined with webhooks, this creates a fully automated flow from document upload through extraction, validation, approval, and delivery with zero manual steps for high-confidence results."
       }
     ],
     related: [
@@ -3984,9 +4484,26 @@ var sections9 = [
         type: "paragraph",
         text: "For best results, review flagged items first \u2014 these are records where at least one validation check failed, making them the most likely to contain errors. Most teams assign a daily review cadence and use confidence range filters to prioritize low-confidence items that need the most attention."
       },
+      {
+        type: "paragraph",
+        text: "The Approval Queue integrates with the broader delivery pipeline through event-driven signals. Every approve or reject action \u2014 whether manual or via batch operations \u2014 emits the corresponding signal immediately. This means downstream systems receive real-time notifications of review decisions. You can bind these signals to different destinations: approved records to a webhook that triggers an ERP import, rejected records to a Slack notification for the data operations team. The event-driven design decouples review decisions from downstream processing, making the system easy to extend."
+      },
+      {
+        type: "list",
+        items: [
+          "Navigate to Review &rarr; Approval Queue to see all pending items",
+          "Filter by status (pending, flagged), schema, or confidence range",
+          "Review detail view shows extracted values alongside the source document",
+          "Provenance trails trace each value back to its origin in the document text",
+          "Inline validation check results show which rules passed and which failed",
+          "Batch approve or reject multiple items at once",
+          "LLM auto-review proposes decisions for pending items with one-click accept or override",
+          "result.approved and result.rejected signals emitted for delivery pipeline integration"
+        ]
+      },
       {
         type: "callout",
-        text: "LLM auto-review is available to accelerate the approval process. When enabled, AI proposes approve or reject decisions for pending items, which you can accept or override with a single click."
+        text: "LLM auto-review is available to accelerate the approval process. When enabled, AI proposes approve or reject decisions for pending items, which you can accept or override with a single click. Auto-review is especially effective for high-volume workloads where most items are straightforward \u2014 it lets reviewers focus their attention on the genuinely ambiguous cases."
       }
     ],
     related: [
@@ -4030,11 +4547,11 @@ var sections10 = [
     content: [
       {
         type: "paragraph",
-        text: "Push extracted, resolved, and reviewed data to any downstream system. Delivery is a typed, at-least-once pipeline with idempotency keys on the wire, append-only history, and a dead-letter queue for terminal failures."
+        text: "Push extracted, resolved, and reviewed data to any downstream system. Delivery is a typed, at-least-once pipeline with idempotency keys on the wire, append-only history, and a dead-letter queue for terminal failures. The system is fully configurable without code changes \u2014 signals, deliverable resolvers, serializers, and connectors are four orthogonal registries that compose independently, so adding a new destination type never requires changes to the signal or serializer code."
       },
       {
         type: "paragraph",
-        text: "Every delivery flows through a five-stage pipeline:"
+        text: "Every delivery flows through a five-stage pipeline. Producers are stateless \u2014 they only publish typed events into an outbox and never interact with destinations or bindings directly. A background poller drains the outbox every 5 seconds (configurable via `delivery.poll_interval_ms`), claiming up to 50 rows per tick using `FOR UPDATE SKIP LOCKED` for safe multi-instance operation. When the BullMQ queue depth exceeds the backpressure threshold (default 10,000), the poller pauses until the queue drains, preventing memory exhaustion under burst load. Matched events are enqueued as delivery jobs processed by workers (default concurrency: 10):"
       },
       {
         type: "param-table",
@@ -4122,7 +4639,7 @@ var sections10 = [
     content: [
       {
         type: "paragraph",
-        text: "A destination is a connector + configuration + optional credentials. Slice-1 ships the webhook connector; S3, Google Sheets, Drive, SFTP, and Email arrive in later slices. Use **Delivery &rarr; Destinations** to manage them from the dashboard, or `POST /v1/delivery/destinations` via the API. Every destination supports a live-ping `POST /v1/delivery/destinations/:id/test` that exercises the full transport envelope with a tiny test payload."
+        text: "A destination is a connector + configuration + optional credentials. Seven connectors are live: webhook (HMAC-SHA256), SFTP, Amazon S3, Azure Blob Storage, Google Drive, OneDrive, and Google Sheets. Use **Delivery &rarr; Destinations** to manage them from the dashboard, or `POST /v1/delivery/destinations` via the API. Every destination supports a live-ping `POST /v1/delivery/destinations/:id/test` that exercises the full transport envelope with a tiny test payload. File-based destinations use lightweight probes (list directory, head bucket, get container properties) so the test never creates artifacts in your target storage."
       },
       {
         type: "param-table",
@@ -4168,6 +4685,10 @@ var sections10 = [
         type: "paragraph",
         text: "A single destination can back multiple bindings. For example, one S3 bucket destination can receive both `document.extracted` and `result.approved` events through separate bindings, each with its own serializer and field map. This keeps your destination inventory small while supporting diverse routing requirements."
       },
+      {
+        type: "paragraph",
+        text: 'For example, to set up a webhook destination via the API: `POST /v1/delivery/destinations` with a body containing `name`, `type: "webhook"`, `config: { url: "https://ops.example.com/talonic" }`, and optionally `auth_config`, `signing_secret`, and `payload_cap_bytes`. The response returns the destination ID, which you then reference when creating a binding. After creation, call `POST /v1/delivery/destinations/:id/test` to verify the connection end-to-end before routing live events to it.'
+      },
       {
         type: "paragraph",
         text: "For best results, always run a live-ping test after creating a destination. The test exercises the full transport envelope \u2014 SSRF validation, payload cap, and authentication \u2014 with a tiny test payload, so you catch configuration errors before real events start flowing. OAuth-based destinations (Google Drive, Google Sheets) require connecting your account first via the OAuth flow in the dashboard."
@@ -4215,15 +4736,15 @@ var sections10 = [
     content: [
       {
         type: "paragraph",
-        text: "A binding is the routing rule: it joins a **signal filter** (which events?) to a **deliverable type** (what payload shape?) to a **destination** (ship where?) via a **serializer** (encoded how?). On create, the backend validates all four pieces form a compatible triangle \u2014 the serializer must support the resolver's shape, and the connector must support the serializer format."
+        text: "A binding is the routing rule: it joins a **signal filter** (which events?) to a **deliverable type** (what payload shape?) to a **destination** (ship where?) via a **serializer** (encoded how?). On create, the backend validates all four pieces form a compatible triangle \u2014 the serializer must support the resolver's shape, and the connector must support the serializer format. This six-predicate validation ensures you never end up with a misconfigured binding that cannot deliver."
       },
       {
         type: "paragraph",
-        text: "Optional `field_map` (rename/drop/static rules) lets you reshape the payload without custom code. Optional `delivery_policy` overrides the default retry ladder (6 attempts at `5s, 30s, 2min, 10min, 1h`) and timeout."
+        text: "Optional `field_map` (rename/drop/static rules) lets you reshape the payload without custom code. The three operations compose in order: drop excluded fields first, then rename remaining fields, then inject static values. Optional `delivery_policy` overrides the default retry ladder (7 attempts over ~10 hours with exponential backoff: 0s, 30s, 2min, 8min, 30min, 2h, 8h) and maximum attempts."
       },
       {
         type: "paragraph",
-        text: "The compatibility triangle is enforced on every create and update. The backend checks that your chosen serializer supports the deliverable resolver's output shape, and that the connector accepts the serializer's format. If any predicate fails, the binding is rejected with a descriptive error \u2014 you never end up with a binding that cannot deliver."
+        text: "The compatibility triangle is enforced on every create and update via six predicates. The backend checks that: (1) the `signal_filter` is well-formed with a known event type and valid match values, (2) the `deliverable_type` resolves to a registered resolver, (3) the `serializer_format` resolves to a registered serializer, (4) the serializer supports the resolver's output shape, (5) the connector's supported serializer list includes the chosen format, and (6) the resolver's compatible signals include the signal filter's event type. If any predicate fails, the binding is rejected with a descriptive error \u2014 you never end up with a binding that cannot deliver."
       },
       {
         type: "paragraph",
@@ -4275,7 +4796,7 @@ var sections10 = [
     content: [
       {
         type: "paragraph",
-        text: "The catalog API (`/v1/delivery/catalog/*`) exposes the four registries that drive the binding picker. Use it to populate dropdowns rather than hardcoding lists \u2014 it always reflects the running registry contents."
+        text: "The catalog API (`/v1/delivery/catalog/*`) exposes the four registries that drive the binding picker: signals, deliverables, serializers, and connectors. Use it to populate dropdowns rather than hardcoding lists \u2014 it always reflects the running registry contents. When new signal types or deliverable resolvers are added to the platform, they appear automatically in the catalog without any configuration changes on your end."
       },
       {
         type: "param-table",
@@ -4340,7 +4861,7 @@ var sections10 = [
       },
       {
         type: "paragraph",
-        text: "Signals are typed events emitted by the platform when meaningful state changes occur. Document-level signals fire on extraction success or failure. Run-level signals fire when a job completes across dataspace, structuring, resolution, or extraction runs. Result-level signals fire when a reviewer approves, rejects, or flags a record."
+        text: "Signals are typed events emitted by the platform when meaningful state changes occur. They fall into four categories. **Document signals** (`document.extracted`, `document.extraction_failed`) fire on extraction success or failure for individual documents. **Run signals** (`run.dataspace.completed`, `run.structuring.completed`, `run.resolution.completed`, `run.extraction.completed`) fire when a job run completes across the four pipeline domains. **Result signals** (`result.approved`, `result.rejected`, `result.flagged`) fire when a reviewer takes action on a record. **Meta-signals** (`delivery.item.completed`, `delivery.item.failed`) fire when a delivery attempt itself succeeds or fails, enabling self-monitoring workflows."
       },
       {
         type: "paragraph",
@@ -4391,15 +4912,15 @@ var sections10 = [
     content: [
       {
         type: "paragraph",
-        text: "Every delivery attempt writes a row to `/v1/delivery/items` with its status, HTTP code, error code, and request/response bodies. Terminal failures (retry ladder exhausted or permanent 4xx) escalate to `/v1/delivery/dlq`. Both are fully replayable \u2014 replay enqueues a new attempt with a fresh idempotency key. Nothing in history is ever mutated; the log is strictly append-only."
+        text: "Every delivery attempt writes a row to `/v1/delivery/items` with its status, HTTP code, error code, and request/response bodies (truncated to 10 KB each). Terminal failures (retry ladder exhausted or permanent 4xx) escalate to `/v1/delivery/dlq`. Both are fully replayable \u2014 replay enqueues a new attempt while preserving the deterministic idempotency key, so receivers that deduplicate on the key will not process the same delivery twice even after multiple replays. Nothing in history is ever mutated; the log is strictly append-only."
       },
       {
         type: "paragraph",
-        text: "The delivery items log captures the full lifecycle of each attempt: in-flight, succeeded, or failed. Each row includes the attempt number, duration in milliseconds, and truncated request/response bodies (up to 10 KB each). Use the items endpoint with filters for `binding_id`, `destination_id`, or `status` to narrow results when debugging a specific integration."
+        text: "The delivery items log captures the full lifecycle of each attempt: in-flight, succeeded, or failed. Each row includes the attempt number, HTTP status code, error code, duration in milliseconds, and truncated request/response bodies (up to 10 KB each). Use the items endpoint with filters for `binding_id`, `destination_id`, or `status` to narrow results when debugging a specific integration. Item and DLQ IDs are UUIDs, while event IDs are sequential integers for efficient ordering."
       },
       {
         type: "paragraph",
-        text: "The dead letter queue (DLQ) is your safety net for terminal failures. When the retry ladder is exhausted or the destination returns a permanent error (e.g., 401 Unauthorized, 403 Forbidden), the failed delivery moves to the DLQ. From there you can inspect the error, fix the destination configuration, and replay the delivery with a single click or API call."
+        text: "The dead letter queue (DLQ) is your safety net for terminal failures. When the retry ladder is exhausted (default: 7 attempts over ~10 hours) or the destination returns a permanent error (e.g., 401 Unauthorized, 403 Forbidden), the failed delivery moves to the DLQ. From there you can inspect the error details, fix the destination configuration, and replay the delivery with a single click or API call. Destinations returning authentication errors are automatically disabled to prevent further failed attempts until the credentials are updated."
       },
       {
         type: "paragraph",
@@ -4418,15 +4939,15 @@ var sections10 = [
     faq: [
       {
         question: "How is delivery history tracked?",
-        answer: "Every delivery attempt writes a row to /v1/delivery/items with status, HTTP code, error code, and request/response bodies. The log is strictly append-only \u2014 nothing is ever mutated."
+        answer: "Every delivery attempt writes a row to /v1/delivery/items with status, HTTP code, error code, and request/response bodies (truncated to 10 KB each). The log is strictly append-only \u2014 nothing is ever mutated. You can filter items by binding_id, destination_id, or status to narrow results when debugging a specific integration."
       },
       {
         question: "What is the dead letter queue (DLQ)?",
-        answer: "Terminal failures (retry ladder exhausted or permanent 4xx) escalate to /v1/delivery/dlq. DLQ entries are fully replayable \u2014 replay enqueues a fresh attempt with a new idempotency key."
+        answer: "Terminal failures (retry ladder exhausted or permanent 4xx) escalate to /v1/delivery/dlq. DLQ entries are fully replayable \u2014 replay enqueues a fresh attempt while preserving the deterministic idempotency key, so receivers that deduplicate on the key will not process the same delivery twice. Destinations returning authentication errors are automatically disabled to prevent further failed attempts."
       },
       {
         question: "How long are request and response bodies retained?",
-        answer: "Request and response bodies are cleaned up after the configured retention period (default 30 days). Row metadata \u2014 status, HTTP code, error code, and duration \u2014 is retained indefinitely for audit purposes."
+        answer: "Request and response bodies are cleaned up after the configured retention period (default 30 days) by a daily cleanup job that runs at 03:00 server time. Row metadata \u2014 status, HTTP code, error code, and duration \u2014 is retained indefinitely for audit purposes. Configure the retention period via the delivery.item_body_retention_days setting in pipeline.yaml."
       }
     ],
     mentions: [
@@ -4499,7 +5020,7 @@ var sections11 = [
       },
       {
         question: "When should I use a shared dialect vs an inline dialect?",
-        answer: "Use shared dialects for workspace-wide defaults that apply to most schemas. Use inline dialects only when a specific schema needs different formatting \u2014 for example, a schema that outputs dates in a different format for a particular downstream system."
+        answer: "Use shared dialects for workspace-wide defaults that apply to most schemas. Use inline dialects only when a specific schema needs different formatting \u2014 for example, a schema that outputs dates in DD/MM/YYYY for a European ERP while the rest of your workspace uses YYYY-MM-DD. Inline overrides apply only to that one schema, so they do not affect any other output. If you find yourself overriding the same setting in multiple schemas, consider updating the shared dialect instead."
       },
       {
         question: "Do shared dialects affect the extraction process?",
@@ -4571,7 +5092,7 @@ var sections11 = [
       },
       {
         question: "How does the lookup cascade work?",
-        answer: "The platform tries three tiers: first, exact string normalization (whitespace and case normalization). If that fails, token-based fuzzy matching. If the fuzzy match is below the confidence threshold, a Haiku LLM call resolves the ambiguity."
+        answer: "The platform tries three tiers in sequence. First, exact string normalization strips whitespace and normalizes casing to find a direct match. If no exact match is found, token-based fuzzy matching compares individual tokens against all reference values and scores similarity. If the best fuzzy match falls below the confidence threshold, a Haiku LLM call evaluates the ambiguous value in context against the top candidates and selects the most likely match. This three-tier approach balances speed and accuracy \u2014 most lookups resolve in the first two tiers without any LLM cost."
       },
       {
         question: "What happens when I update a reference primitive?",
@@ -4616,7 +5137,10 @@ var sections11 = [
         items: [
           "**Schema changes** \u2014 field additions, removals, mapping updates, and format constraint modifications.",
           "**Shared dialect changes** \u2014 date format, number locale, delimiter, and encoding updates.",
-          "**Reference primitive changes** \u2014 new versions of lookup tables and key-value modifications."
+          "**Reference primitive changes** \u2014 new versions of lookup tables and key-value modifications.",
+          "**Delivery binding changes** \u2014 modifications to outbound delivery destinations, field maps, or signal filters.",
+          "**Routing rule changes** \u2014 additions or modifications to document routing rules that assign schemas automatically.",
+          "**Format constraint changes** \u2014 regex pattern updates or fallback behavior modifications on schema fields."
         ]
       },
       {
@@ -4697,7 +5221,9 @@ var sections12 = [
           "**Extracted values** \u2014 finds specific data points across all processed documents.",
           "**Field names** \u2014 searches the Field Registry for canonical field definitions.",
           "**Schema names** \u2014 locates generated and template schemas by title.",
-          "**Sources** \u2014 matches source connection names and configurations."
+          "**Sources** \u2014 matches source connection names and configurations.",
+          "**Matching configurations** \u2014 finds matching configs and reference datasets by name.",
+          "**Delivery bindings** \u2014 locates delivery pipeline bindings and destination configurations."
         ]
       }
     ],
@@ -4764,6 +5290,10 @@ var sections12 = [
       {
         type: "paragraph",
         text: 'For best results, save your most common filter combinations as presets. Most teams create presets for categories like "high-value invoices this quarter," "documents missing key fields," or "recently failed extractions." Presets appear as one-click buttons on the Documents page, eliminating the need to rebuild complex filter conditions from scratch each time.'
+      },
+      {
+        type: "paragraph",
+        text: 'For example, to find all invoices from a specific vendor with outstanding amounts, build a filter with `vendor_name eq "Acme Corp"` AND `document_type eq "Invoice"` AND `total_amount gt 5000`. The field autocomplete ensures you are filtering on valid extracted fields, and the materialized index returns results instantly even across thousands of documents. Save this as a preset called "Acme high-value invoices" for one-click access when you need to review that vendor\'s billing history.'
       }
     ],
     related: [
@@ -4826,10 +5356,25 @@ var sections13 = [
         type: "paragraph",
         text: "For best results, create separate API keys for each integration or service that connects to your Talonic workspace. This makes it easy to rotate or revoke a single key without disrupting other integrations. Most teams maintain one key for their ingestion pipeline, one for their BI dashboard, and one for webhook-based automations."
       },
+      {
+        type: "paragraph",
+        text: "API keys are SHA-256 hashed at rest, which means the platform never stores the plaintext key after creation. This is a deliberate security measure \u2014 even if the database were compromised, the hashed keys cannot be reversed to their original values. When your integration sends a request, the platform hashes the incoming key and compares it against the stored hash. This design follows the same pattern used by GitHub, Stripe, and other major API providers."
+      },
+      {
+        type: "list",
+        items: [
+          "Prefixed with tlnc_ for easy identification in logs and configuration files",
+          "Passed via the Authorization: Bearer header on every API request",
+          "SHA-256 hashed at rest \u2014 the full key is only shown once at creation",
+          "Three scopes: extract (ingestion), read (query), write (create/modify)",
+          "Create separate keys per integration for independent rotation and revocation",
+          "No limit on the number of keys per workspace"
+        ]
+      },
       {
         type: "callout",
         variant: "warning",
-        text: "Copy the full API key immediately after creation \u2014 it is only displayed once. If you lose the key, you must delete it and create a new one. Existing integrations using the old key will stop working until updated."
+        text: "Copy the full API key immediately after creation \u2014 it is only displayed once. If you lose the key, you must delete it and create a new one. Existing integrations using the old key will stop working until updated. Store API keys in a secrets manager, not in source code or environment files checked into version control."
       },
       {
         type: "param-table",
@@ -4870,6 +5415,10 @@ var sections13 = [
       {
         question: "Can I have multiple API keys?",
         answer: "Yes. You can create as many API keys as needed. Best practice is to create separate keys for each integration so you can rotate or revoke them independently without disrupting other services."
+      },
+      {
+        question: "What are best practices for API key management?",
+        answer: "Store keys in a secrets manager rather than source code or environment files checked into version control. Create one key per integration so each can be rotated independently. Use the narrowest scope possible \u2014 a read-only dashboard needs only the read scope, not extract or write. Rotate keys on a regular schedule and immediately revoke any key that may have been exposed. Monitor API usage per key to detect anomalies early."
       }
     ],
     mentions: ["API keys", "tlnc_", "SHA-256", "Bearer token", "scopes"]
@@ -4897,6 +5446,26 @@ var sections13 = [
         type: "paragraph",
         text: "For best results, start with the `/v1/extract` endpoint for document ingestion, then use `/v1/documents` and `/v1/extractions` to retrieve results. As your integration matures, explore delivery bindings, matching configurations, and batch processing to build a fully automated data pipeline."
       },
+      {
+        type: "paragraph",
+        text: "Long-running operations like matching runs, batch inference, and resolution runs follow an asynchronous pattern. You submit a request to start the operation and receive a run ID. Poll the status endpoint with that run ID to track progress \u2014 the response includes a percentage-complete indicator and a terminal status when the operation finishes. This pattern keeps HTTP connections short-lived while giving you full visibility into background processing."
+      },
+      {
+        type: "paragraph",
+        text: "Error responses follow a consistent structure across all namespaces. Every error includes a typed error code from the ErrorCode enum, a human-readable message, and the HTTP status code. Common error codes include ENTITY_NOT_FOUND (404), VALIDATION_ERROR (400), and RATE_LIMIT_EXCEEDED (429). Rate limiting is applied per API key with configurable thresholds \u2014 the response headers include X-RateLimit-Remaining and X-RateLimit-Reset so your integration can adapt proactively."
+      },
+      {
+        type: "list",
+        items: [
+          "20+ namespaces covering extraction, documents, schemas, jobs, delivery, linking, cases, quality, and more",
+          "JSON request and response bodies with cursor-based pagination for list operations",
+          "Authenticate with a tlnc_ API key via the Authorization: Bearer header",
+          "Asynchronous operations with polling endpoints for status and progress",
+          "Typed error codes with consistent response structure across all endpoints",
+          "Rate limiting with X-RateLimit-Remaining and X-RateLimit-Reset headers",
+          "Batch processing mode at 50% cost with 48-hour delivery SLA"
+        ]
+      },
       {
         type: "callout",
         variant: "info",
@@ -5045,7 +5614,7 @@ var sections13 = [
     content: [
       {
         type: "paragraph",
-        text: "Webhooks push real-time notifications when events occur. All payloads are HMAC-SHA256 signed. Failed deliveries retry with exponential backoff."
+        text: "Webhooks push real-time notifications when events occur in your Talonic workspace. All payloads are HMAC-SHA256 signed using the signing secret configured on your delivery destination, ensuring authenticity and tamper detection. Failed deliveries retry with exponential backoff \u2014 the platform makes progressively spaced attempts before routing terminal failures to the dead-letter queue (DLQ) for manual replay."
       },
       {
         type: "paragraph",
@@ -5059,6 +5628,27 @@ var sections13 = [
         type: "paragraph",
         text: "Use webhooks when your downstream system needs to react immediately to platform events \u2014 for example, triggering an ERP import when a document is extracted, or notifying a Slack channel when a reviewer rejects a record. For bulk or periodic data transfers, consider using the SFTP, S3, or cloud storage delivery connectors instead."
       },
+      {
+        type: "paragraph",
+        text: "To set up a webhook, create a delivery destination of type **webhook** with your endpoint URL and a signing secret. Then create a binding that maps one or more signal types to the destination. When an event fires, the platform constructs the payload, signs it, and delivers it to your endpoint. You can bind multiple signal types to the same destination or spread them across different destinations for different downstream systems."
+      },
+      {
+        type: "list",
+        items: [
+          "HMAC-SHA256 signed payloads for authenticity and tamper detection",
+          "Idempotency key in headers for safe deduplication on retries",
+          "Exponential backoff on delivery failure with configurable retry limits",
+          "Dead-letter queue (DLQ) for terminal failures with manual replay",
+          "Bind any signal type to a webhook destination via delivery bindings",
+          "11 signal types covering document, run, result, and delivery lifecycle events",
+          "Meta-signals (delivery.item.completed/failed) are not re-delivered to avoid loops"
+        ]
+      },
+      {
+        type: "callout",
+        variant: "warning",
+        text: "Your webhook endpoint must respond with a 2xx status code within 30 seconds. Non-2xx responses or timeouts trigger the retry schedule. Permanent client errors (4xx except 429) are treated as terminal failures and routed directly to the DLQ without further retries."
+      },
       {
         type: "param-table",
         title: "Delivery signal types (webhook-compatible)",
@@ -5161,11 +5751,11 @@ var sections14 = [
     content: [
       {
         type: "paragraph",
-        text: "Organizations support role-based access control:"
+        text: "Organizations support role-based access control that governs who can view, create, edit, and manage resources across your workspace. Access control is enforced at the API level, so permissions apply consistently whether users interact through the web interface, the AI agent, or the public API."
       },
       {
         type: "paragraph",
-        text: "Every user in your organization is assigned one of four roles that determine what they can see and do. Roles are hierarchical \u2014 each level includes all permissions of the levels below it. Choose the most restrictive role that still lets a team member do their job."
+        text: "Every user in your organization is assigned one of four roles that determine what they can see and do. Roles are hierarchical \u2014 each level includes all permissions of the levels below it. Choose the most restrictive role that still lets a team member do their job. For most team members working on data review and extraction, the **Member** role provides everything they need."
       },
       {
         type: "param-table",
@@ -5195,7 +5785,7 @@ var sections14 = [
       },
       {
         type: "paragraph",
-        text: "New members are added via domain matching: company email domains auto-match to your org with **pending** status requiring admin approval. Manage from the Team page."
+        text: "New members are added via domain matching: company email domains auto-match to your org with **pending** status requiring admin approval. This means anyone who signs up with an email from your company domain is automatically associated with your organization, but cannot access any data until an Admin or Owner explicitly approves them. Manage all team members and pending requests from the Team page in the sidebar."
       },
       {
         type: "paragraph",
@@ -5206,6 +5796,16 @@ var sections14 = [
         variant: "info",
         text: "Domain matching streamlines onboarding for larger teams. When a new user signs up with an email address matching your organization's domain (e.g., `@yourcompany.com`), they are automatically associated with your org in a **pending** state. An admin must approve them before they gain access."
       },
+      {
+        type: "list",
+        ordered: false,
+        items: [
+          "**Viewer** \u2014 read-only access to documents, extraction results, schemas, and reports. Cannot create, edit, or delete any resources.",
+          "**Member** \u2014 full CRUD access to documents, schemas, jobs, matching configurations, and delivery bindings. Cannot manage team members or workspace settings.",
+          "**Admin** \u2014 all Member permissions plus team management (approve/reject members, change roles), workspace settings (shared dialects, reference primitives, change review), and routing rules.",
+          "**Owner** \u2014 all Admin permissions plus billing management, API key generation and revocation, organization-level settings, and the ability to transfer ownership."
+        ]
+      },
       {
         type: "list",
         ordered: true,
@@ -5262,11 +5862,11 @@ var sections14 = [
     content: [
       {
         type: "paragraph",
-        text: "The Usage & Registry page replaces the legacy credits view with a comprehensive cost breakdown. It shows per-feature cost (extraction, OCR, batch, matching), a daily cost chart, and a full call log with model, tokens, and cost per request. The **Master view** (admin only) shows per-customer breakdowns and platform-wide statistics."
+        text: "The Usage & Registry page replaces the legacy credits view with a comprehensive cost breakdown. It shows per-feature cost (extraction, OCR, batch, matching), a daily cost chart, and a full call log with model, tokens, and cost per request. The **Master view** (admin only) shows per-customer breakdowns and platform-wide statistics. Navigate to **Usage** from the sidebar to access all views."
       },
       {
         type: "paragraph",
-        text: "Understanding your usage patterns helps optimize costs. For example, if extraction dominates your spend, consider using **batch mode** for non-urgent documents to cut that cost in half. The daily cost chart makes it easy to spot usage spikes and correlate them with specific ingestion events."
+        text: "Understanding your usage patterns helps optimize costs. For example, if extraction dominates your spend, consider using **batch mode** for non-urgent documents to cut that cost in half. If OCR is a significant portion, check whether you are processing image-heavy documents that could benefit from better source quality. The daily cost chart makes it easy to spot usage spikes and correlate them with specific ingestion events or batch completions."
       },
       {
         type: "paragraph",
@@ -5302,10 +5902,26 @@ var sections14 = [
           }
         ]
       },
+      {
+        type: "heading",
+        level: 3,
+        id: "cost-optimization",
+        text: "Cost Optimization Tips"
+      },
+      {
+        type: "list",
+        ordered: false,
+        items: [
+          "**Use batch mode** for non-urgent documents \u2014 extraction runs at 50% cost with a 48-hour delivery window.",
+          "**Build your field registry** \u2014 as more fields reach Tier 1 and Tier 2, extraction costs drop because values are resolved via lookup instead of AI calls.",
+          "**Review the per-feature breakdown** weekly to identify which operations dominate your spend.",
+          "**Leverage routing rules** to automatically assign schemas, reducing the number of manual job runs and re-extractions."
+        ]
+      },
       {
         type: "callout",
         variant: "info",
-        text: "The call log records every LLM and OCR call with full detail \u2014 model name, input/output token counts, latency, and cost. Use it to audit individual extractions or investigate unexpected cost increases."
+        text: "The call log records every LLM and OCR call with full detail \u2014 model name, input/output token counts, latency, and cost. Use it to audit individual extractions or investigate unexpected cost increases. Each entry links back to the specific document and job that triggered the call."
       }
     ],
     related: [
@@ -5324,7 +5940,7 @@ var sections14 = [
       },
       {
         question: "How can I reduce my usage costs?",
-        answer: "Use batch mode for non-urgent documents to cut extraction costs by 50%. Review the per-feature breakdown to identify your highest-cost operations, and use the daily cost chart to spot and investigate usage spikes."
+        answer: "Use batch mode for non-urgent documents to cut extraction costs by 50%. Review the per-feature breakdown to identify your highest-cost operations, and use the daily cost chart to spot and investigate usage spikes. Additionally, invest in building your Field Registry \u2014 as more fields reach Tier 1 and Tier 2, values are resolved via deterministic lookup instead of LLM calls, which reduces per-document extraction cost over time. Leverage routing rules to assign schemas automatically, which avoids manual re-extractions and wasted processing."
       }
     ],
     mentions: [
@@ -5353,7 +5969,7 @@ var sections14 = [
       },
       {
         type: "paragraph",
-        text: "The Admin Panel operates across tenant boundaries, giving administrators visibility into all organizations on the platform. The **usage statistics** view aggregates cost and volume data across all customers, making it straightforward to identify high-usage tenants, track platform growth, and forecast infrastructure needs."
+        text: "The Admin Panel operates across tenant boundaries, giving administrators visibility into all organizations on the platform. The **usage statistics** view aggregates cost and volume data across all customers, making it straightforward to identify high-usage tenants, track platform growth, and forecast infrastructure needs. Usage data includes per-feature breakdowns (extraction, OCR, batch, matching) and daily cost trends across all tenants."
       },
       {
         type: "paragraph",
@@ -5383,19 +5999,19 @@ var sections14 = [
     faq: [
       {
         question: "What features does the Admin Panel provide?",
-        answer: "Customer management, user management, usage statistics, data clear & rebuild, and cross-tenant master registry view. Accessible from the user menu for admins and superadmins."
+        answer: "Customer management (create, list, delete organizations), user management (cross-tenant user view with account removal), usage statistics (platform-wide cost and volume aggregates), data clear and rebuild (wipe and reprocess all data for a customer), and cross-tenant master registry view (audit field definitions and schemas across tenants)."
       },
       {
         question: "Who can access the Admin Panel?",
-        answer: "The Admin Panel is accessible only to users with admin or superadmin roles, via the user menu in the platform navigation."
+        answer: "The Admin Panel is accessible only to users with admin or superadmin roles, via the user menu in the platform navigation. Regular Members and Viewers do not see the Admin Panel option."
       },
       {
         question: "What does the data clear operation do?",
-        answer: "Data clear wipes all documents, extractions, jobs, results, and related data for a specific customer. It is irreversible and intended for full reprocessing scenarios during onboarding or after major schema changes."
+        answer: "Data clear wipes all documents, extractions, jobs, results, and related data for a specific customer. It is irreversible and intended for full reprocessing scenarios during onboarding or after major schema changes. Always confirm with the customer before executing this operation."
       },
       {
         question: "Can I view usage across all customers?",
-        answer: "Yes. The Admin Panel includes a master registry view that shows cross-tenant usage statistics, per-customer cost breakdowns, and platform-wide aggregates."
+        answer: "Yes. The Admin Panel includes a master registry view that shows cross-tenant usage statistics, per-customer cost breakdowns, and platform-wide aggregates. This is useful for identifying high-usage tenants, tracking platform growth, and forecasting infrastructure needs."
       }
     ],
     mentions: [
@@ -5416,11 +6032,11 @@ var sections14 = [
     content: [
       {
         type: "paragraph",
-        text: "Talonic provides global keyboard shortcuts that work from any page in the platform. These shortcuts let you access common actions without leaving your current context, significantly speeding up daily workflows."
+        text: "Talonic provides global keyboard shortcuts that work from any page in the platform. These shortcuts let you access common actions without leaving your current context, significantly speeding up daily workflows. Whether you are reviewing extraction results, configuring schemas, or browsing the field registry, the same shortcuts are always available."
       },
       {
         type: "paragraph",
-        text: "Shortcuts are registered at the application level, meaning they respond regardless of which page or panel is currently active. The platform intercepts the key combination before it reaches the browser, so these shortcuts take priority over default browser bindings when the Talonic window is focused."
+        text: "Shortcuts are registered at the application level, meaning they respond regardless of which page or panel is currently active. The platform intercepts the key combination before it reaches the browser, so these shortcuts take priority over default browser bindings when the Talonic window is focused. On macOS, shortcuts use the Command key (`Cmd`); on Windows and Linux, they use `Ctrl`."
       },
       {
         type: "paragraph",
@@ -5444,6 +6060,11 @@ var sections14 = [
             type: "global",
             description: "Quick extract \u2014 upload and process a document."
           },
+          {
+            name: "\u2318I / Ctrl+I",
+            type: "global",
+            description: "Open the AI Agent from any page."
+          },
           {
             name: "Escape",
             type: "global",
@@ -5451,10 +6072,14 @@ var sections14 = [
           }
         ]
       },
+      {
+        type: "paragraph",
+        text: "In addition to the global shortcuts, the **AI Agent** can be opened from any page using `Cmd+I` (`Ctrl+I` on Windows). The agent provides a conversational interface for inspecting data, building schemas, and analyzing extraction quality \u2014 all without navigating away from your current page. Combined with Omnisearch and quick extract, these three shortcuts cover the most common workflow interruptions."
+      },
       {
         type: "callout",
         variant: "info",
-        text: "The **quick extract** shortcut (`Cmd+J` / `Ctrl+J`) is the fastest way to upload a single document. It opens a streamlined upload interface that lets you drag a file and start processing immediately."
+        text: "The **quick extract** shortcut (`Cmd+J` / `Ctrl+J`) is the fastest way to upload a single document. It opens a streamlined upload interface that lets you drag a file and start processing immediately. Use it when you receive a document via email or chat and want instant extraction results."
       }
     ],
     related: [
@@ -5464,15 +6089,15 @@ var sections14 = [
     faq: [
       {
         question: "What keyboard shortcuts are available?",
-        answer: "Cmd+K / Ctrl+K for Omnisearch, Cmd+J / Ctrl+J for quick extract (upload and process), and Escape to close overlays, modals, and search."
+        answer: "Four global shortcuts: Cmd+K / Ctrl+K for Omnisearch, Cmd+J / Ctrl+J for quick extract (upload and process), Cmd+I / Ctrl+I to open the AI Agent, and Escape to close overlays, modals, and search. These work from any page in the platform."
       },
       {
         question: "What does the quick extract shortcut do?",
-        answer: "Cmd+J / Ctrl+J opens the quick extract interface, allowing you to upload and process a document directly from any page."
+        answer: "Cmd+J / Ctrl+J opens the quick extract interface, allowing you to upload and process a document directly from any page. It provides a streamlined drag-and-drop area that immediately processes the uploaded file and displays extraction results. This is the fastest path from receiving a document to seeing structured data \u2014 ideal for one-off documents that arrive via email or chat and need immediate attention without navigating to the upload page."
       },
       {
         question: "Do shortcuts work inside modals or overlays?",
-        answer: "The Escape shortcut works inside any modal or overlay to close it. Omnisearch (Cmd+K) works globally, even when other overlays are open. Quick extract (Cmd+J) is available from the main interface."
+        answer: "The Escape shortcut works inside any modal or overlay to close it. Omnisearch (Cmd+K) works globally, even when other overlays are open. The AI Agent shortcut (Cmd+I) also works from any context. Quick extract (Cmd+J) is available from the main interface."
       }
     ],
     mentions: ["keyboard shortcuts", "Cmd+K", "Cmd+J", "Escape", "quick extract"]
@@ -5490,7 +6115,7 @@ var sections15 = [
     content: [
       {
         type: "paragraph",
-        text: "Documents can be processed in **batch mode** at 50% cost with a 48-hour delivery window. Toggle batch mode on the upload screen or set it via the API. Batch processing is ideal for large backlog ingestion where real-time results are not required."
+        text: "Documents can be processed in **batch mode** at 50% cost with a 48-hour delivery window. Toggle batch mode on the upload screen or set `processing_mode=batch` via the API. Batch processing is ideal for large backlog ingestion where real-time results are not required. The cost reduction comes from the provider's native batch API, which schedules processing during off-peak capacity \u2014 there is no loss in extraction quality because the same Claude model and prompts are used as in real-time mode."
       },
       {
         type: "callout",
@@ -5554,7 +6179,7 @@ var sections15 = [
     content: [
       {
         type: "paragraph",
-        text: 'Set `processing_mode=batch` on upload (API) or toggle the "Batch" switch in the upload UI. Stage 1 (OCR + classification) runs immediately so documents appear in your library right away. Stage 2 (Claude extraction) is deferred to the provider\'s batch API for asynchronous processing.'
+        text: 'Set `processing_mode=batch` on upload (API) or toggle the "Batch" switch in the upload UI. Stage 1 (OCR + classification) runs immediately so documents appear in your library right away with their type classification and triage metadata. Stage 2 (Claude extraction) is deferred to the provider\'s batch API for asynchronous processing. While waiting for batch results, documents show a status of `batch_queued` in your library. The system requires a minimum of 100 items per batch \u2014 if fewer documents are uploaded in batch mode, the system falls back to real-time processing with a warning.'
       },
       {
         type: "paragraph",
@@ -5583,11 +6208,22 @@ var sections15 = [
       },
       {
         type: "paragraph",
-        text: "While waiting for batch results, documents show a status of `batch_queued`. Once the provider returns results, the platform applies them through the same post-processing pipeline as real-time extraction \u2014 including markdown pre-processing, field parsing, quality metrics, and extraction metadata computation."
+        text: "While waiting for batch results, documents show a status of `batch_queued` in your library. Once the provider returns results, the platform applies them through the same post-processing pipeline as real-time extraction \u2014 including markdown pre-processing, field parsing, quality metrics, and extraction metadata computation. If a batch extraction fails to parse, the affected document is retried through the real-time extraction path rather than as a new batch, ensuring the original 48-hour SLA is maintained."
       },
       {
         type: "paragraph",
         text: "You can also enable batch mode on a per-source basis. When a source connection has the batch processing toggle enabled, all documents ingested through that source are automatically routed to the batch queue. This is ideal for source connections that handle non-urgent, high-volume ingestion \u2014 such as a shared drive that collects documents overnight."
+      },
+      {
+        type: "list",
+        ordered: false,
+        items: [
+          "**Included in batch:** Stage 2 Claude extraction, markdown pre-processing, field parsing, quality metrics computation, extraction metadata, and all post-processing that does not require LLM calls.",
+          "**Excluded from batch:** LLM-based quality passes (field estimation, verification, cross-reference enrichment) are skipped to preserve cost savings.",
+          "**Excluded from batch:** Image-only documents (PNG, JPG) are automatically routed to real-time processing because the batch payload is text-only.",
+          "**Fallback behavior:** Parse failures in batch mode are retried through the real-time extraction path \u2014 never as a new batch \u2014 to maintain the 48-hour SLA.",
+          "**Minimum threshold:** Batches require at least 100 items (a provider requirement). Uploads below this threshold fall back to real-time processing with a warning."
+        ]
       }
     ],
     related: [
@@ -5631,16 +6267,20 @@ var sections15 = [
     content: [
       {
         type: "paragraph",
-        text: "The Batches page at `/sources/batches` shows the status of all batch jobs. Each batch progresses through three states: **accumulating** (items collecting), **submitted** (sent to provider), and **completed** (results applied). The page live-syncs with the provider for real-time status updates."
+        text: "The Batches page at `/sources/batches` shows the status of all batch jobs with real-time updates. Each batch progresses through three states: **accumulating** (items collecting in the queue), **submitted** (sent to the provider's batch API), and **completed** (results received and applied to the corresponding documents). The page live-syncs with the provider so you can monitor progress without manual refreshing. Click any batch to see the detail view with individual items, their processing state, and any errors."
       },
       {
         type: "paragraph",
-        text: "Batches are submitted automatically when the accumulation timer fires (every 15 minutes by default) or when the item count threshold is reached. Once submitted, the platform polls the provider hourly to check for completion. When results arrive, they are applied to the corresponding documents and the batch transitions to **completed** status."
+        text: "Batches are submitted automatically when the accumulation timer fires (every 15 minutes by default) or when the item count threshold is reached, whichever comes first. These intervals are configurable in the pipeline settings. Once submitted, the platform polls the provider hourly to check for completion. When results arrive, they are applied to the corresponding documents \u2014 including field resolution, linking, triage, and delivery events \u2014 and the batch transitions to **completed** status."
       },
       {
         type: "paragraph",
         text: "The batch detail view shows individual items within a batch, including which documents are included, their current processing state, and any errors that occurred. Use this view to verify that a specific document was included in the expected batch and to troubleshoot items that failed to parse."
       },
+      {
+        type: "paragraph",
+        text: "For example, after uploading 500 invoices in batch mode, navigate to `/sources/batches` to check progress. You will see a batch in **accumulating** status collecting items until the 15-minute timer fires. Once submitted, the status changes to **submitted** and the platform polls the provider hourly. Click the batch row to see each document's individual state \u2014 if 3 items show parse errors, those documents were automatically retried via the real-time path while the remaining 497 completed normally. When the batch transitions to **completed**, all results have been applied and documents are ready for review."
+      },
       {
         type: "paragraph",
         text: "The platform includes built-in crash recovery for batch processing. If the application restarts while a batch is in a transient `processing` state, the recovery logic automatically reverts it to `submitted` so the next polling cycle can retry. This means batch jobs are resilient to infrastructure disruptions without requiring manual intervention."
@@ -5718,11 +6358,11 @@ var sections16 = [
     content: [
       {
         type: "paragraph",
-        text: "Upload CSV or Excel files as lookup tables. These reference datasets are used by the matching engine and by reference strategies in schemas. Each reference dataset is versioned and can be shared across multiple schemas."
+        text: 'Upload CSV or Excel files as lookup tables for the matching engine and schema reference strategies. These reference datasets represent your "ground truth" \u2014 the known records you want to match extracted document data against. Each reference dataset is versioned independently and can be shared across multiple schemas and matching configurations without duplication.'
       },
       {
         type: "paragraph",
-        text: 'Reference data is the foundation of the matching system. It represents your "ground truth" \u2014 the known records you want to match extracted document data against. Common examples include customer lists, product catalogs, vendor registries, and contract databases.'
+        text: "Reference data is the foundation of the matching system. Common examples include customer lists, product catalogs, vendor registries, contract databases, and supplier directories. When you upload a reference dataset, the platform indexes all columns and rows for fast lookup during matching runs. You can also import reference data directly from a SQL database connection using `POST /matching/reference-data/from-sql`, which streams rows asynchronously in batches of 500 from your connected MSSQL or PostgreSQL database."
       },
       {
         type: "paragraph",
@@ -5760,7 +6400,7 @@ var sections16 = [
       },
       {
         question: "How is reference data used?",
-        answer: "Reference datasets are used by the matching engine for field-to-field comparisons and by reference strategies in schemas for code mapping and value resolution."
+        answer: "Reference datasets serve two purposes. First, the matching engine uses them for field-to-field comparisons \u2014 comparing extracted document values against reference rows using weighted strategies (exact, fuzzy, date_range, numeric_range). Second, reference strategies in schemas use them for code mapping and value resolution, translating labels found in documents into canonical codes defined in the reference dataset."
       },
       {
         question: "Can I import reference data from a database?",
@@ -5789,7 +6429,7 @@ var sections16 = [
     content: [
       {
         type: "paragraph",
-        text: "Define field-to-field comparisons between extracted data and reference datasets. Each comparison uses a weighted strategy to score matches:"
+        text: "Define field-to-field comparisons between extracted data and reference datasets. Each comparison uses a weighted strategy to score matches. A matching configuration specifies which fields to compare, which strategy to use for each comparison, and the relative weight that determines how much each field contributes to the overall confidence score:"
       },
       {
         type: "param-table",
@@ -5833,6 +6473,16 @@ var sections16 = [
         type: "callout",
         variant: "info",
         text: "Use **AI strategy generation** when setting up matching for the first time. The platform analyzes your schema fields and reference data columns, then suggests which fields to compare and which strategy to use for each. You can review and adjust the suggestions before saving."
+      },
+      {
+        type: "list",
+        ordered: false,
+        items: [
+          "**exact** \u2014 case-insensitive string comparison. Best for unique identifiers like PO numbers, invoice IDs, and reference codes where values should match verbatim.",
+          "**fuzzy** \u2014 token-based similarity with a configurable threshold (0-100%). Handles misspellings, abbreviations, and word reordering. Ideal for company names, addresses, and descriptions.",
+          "**date_range** \u2014 matches dates within a configurable tolerance window (e.g., +/- 7 days). Useful when documents report dates with slight offsets, such as invoice date vs. received date.",
+          "**numeric_range** \u2014 matches numbers within a percentage or absolute tolerance. Handles rounding differences in amounts, quantities, and prices across systems."
+        ]
       }
     ],
     related: [
@@ -5877,15 +6527,15 @@ var sections16 = [
     content: [
       {
         type: "paragraph",
-        text: "Execute a matching run against a reference dataset. Matching runs are processed asynchronously via BullMQ. You can monitor progress from the matching page and cancel running jobs if needed."
+        text: "Execute a matching run against a reference dataset. Matching runs are processed asynchronously via a dedicated job queue, so they do not block your workflow. You can monitor progress from the matching page with real-time updates showing the number of documents processed and estimated time remaining, and cancel running jobs if needed \u2014 partial results from documents already processed are preserved."
       },
       {
         type: "paragraph",
-        text: "There are two types of runs: **manual runs** use only the deterministic matching strategies (exact, fuzzy, date_range, numeric_range) and complete quickly. **Smart runs** add an AI resolution pass \u2014 after the initial matching, an embedding-based search with a Haiku LLM resolver attempts to improve low-confidence results."
+        text: "There are two types of runs: **manual runs** use only the deterministic matching strategies (exact, fuzzy, date_range, numeric_range) and complete quickly. **Smart runs** add an AI resolution pass \u2014 after the initial matching, an embedding-based similarity search identifies promising candidates for each low-confidence document, and a Haiku LLM resolver evaluates each candidate in context to improve match quality."
       },
       {
         type: "paragraph",
-        text: "Matching runs are processed asynchronously via a dedicated job queue, so they do not block your workflow. You can continue working in the platform while a run executes in the background. The matching page shows real-time progress with the number of documents processed and estimated time remaining."
+        text: "Matching runs are processed asynchronously via a dedicated BullMQ job queue, so they do not block your workflow. You can continue working in the platform while a run executes in the background. The matching page shows real-time progress with the number of documents processed and estimated time remaining. You can also trigger an AI resolution pass on a completed run using the `POST /matching/runs/:id/ai-resolve` endpoint to upgrade specific low-confidence results without re-running the entire job."
       },
       {
         type: "paragraph",
@@ -5942,7 +6592,7 @@ var sections16 = [
     content: [
       {
         type: "paragraph",
-        text: "Results are presented per document with the top 5 match candidates. Each candidate includes a confidence score and field-level evidence showing which comparisons contributed to the match and how each field scored."
+        text: "Results are presented per document with the top 5 match candidates ranked by weighted confidence score. Each candidate includes a confidence score (0-100%) and field-level evidence showing which comparisons contributed to the match, the strategy used for each field (exact, fuzzy, date_range, or numeric_range), the individual field score, and the actual values that were compared on both sides. This transparency makes it straightforward to verify correct matches and investigate false positives."
       },
       {
         type: "paragraph",
@@ -5981,6 +6631,10 @@ var sections16 = [
         type: "callout",
         variant: "info",
         text: "You can **approve or reject** individual match results. Approved matches can be used downstream in delivery pipelines. Rejected matches are excluded from future consideration for that document."
+      },
+      {
+        type: "paragraph",
+        text: 'Consider a practical example: you receive an invoice from "Acme Corp" with a total of $12,450 dated 2025-03-15. The matching engine returns the top candidate as "ACME Corporation" in your reference data with a confidence score of 87%. The evidence view shows the vendor name scored 92% via fuzzy match (handling "Corp" vs "Corporation"), the amount scored 100% via exact match, and the date scored 78% via date_range because the reference shows a PO date of 2025-03-10 \u2014 within the 7-day tolerance. You can quickly verify the match is correct and approve it, sending the linked record downstream.'
       }
     ],
     related: [