@talonic/docs 0.20.15 → 0.20.16

package/dist/content.js

@@ -457,6 +457,38 @@ var sections = [
         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. Document AI (Mistral) handles OCR by default, with automatic fallback to the Talonic API for unsupported formats."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "quick-api-example",
+        text: "Quick API Example"
+      },
+      {
+        type: "paragraph",
+        text: "Talonic exposes a full REST API so you can integrate document extraction into any workflow programmatically. The simplest way to get started is to upload a document via the `/v1/sources/:sourceId/documents` endpoint. The platform automatically runs OCR, classification, and extraction \u2014 you poll for results or receive a webhook notification when processing completes."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Upload a document via API",
+        code: 'curl -X POST https://api.talonic.com/v1/sources/src_abc123/documents \\\n  -H "Authorization: Bearer $TALONIC_API_KEY" \\\n  -F "file=@invoice.pdf" \\\n  -F "processing_mode=sync"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "id": "doc_7f3a1b2c",\n  "status": "completed",\n  "document_type": "Invoice",\n  "fields_extracted": 24,\n  "confidence_avg": 0.94,\n  "created_at": "2026-05-07T10:30:00Z"\n}'
+      },
+      {
+        type: "paragraph",
+        text: "Once a document is processed, you can retrieve its extracted fields using the extractions endpoint. Each field includes the extracted value, a confidence score between 0 and 1, and the source text from the original document that the value was derived from. This makes every extraction result fully auditable and traceable back to its origin in the source document."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Retrieve extraction results",
+        code: 'curl https://api.talonic.com/v1/extractions/doc_7f3a1b2c \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
       }
     ],
     related: [
@@ -480,6 +512,10 @@ var sections = [
       {
         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. As your knowledge graph grows from processing more documents, the percentage of free graph matches increases, further reducing per-job costs."
+      },
+      {
+        question: "Can I use Talonic via API without the web interface?",
+        answer: "Yes. Talonic exposes a full REST API at api.talonic.com/v1 with 20+ namespaces covering extraction, documents, schemas, jobs, delivery, and more. You can upload documents, retrieve extraction results, create schemas, run jobs, and configure delivery bindings entirely through API calls. Authenticate with a tlnc_ prefixed API key via the Authorization: Bearer header."
       }
     ],
     mentions: [
@@ -560,10 +596,46 @@ var sections = [
         type: "paragraph",
         text: "The **Schema** layer sits on top of the registry and defines what output you need. You can use auto-generated schemas that the platform creates for each document type, or build custom template schemas by selecting specific fields from the registry. When a schema is applied to documents in a **Job**, the 4-phase pipeline fills every cell \u2014 starting with free graph lookups and falling back to AI agents for the remainder. The result is a structured grid where each row is a document and each column is a field."
       },
+      {
+        type: "paragraph",
+        text: "**Cases** add another dimension to document intelligence. When two or more documents share entities \u2014 like a common vendor name, reference number, or project code \u2014 the platform automatically connects them into a case. Cases provide a cross-document view that reveals relationships invisible at the individual document level. For example, a purchase order and its corresponding invoice might share a PO number, linking them into a case that lets you verify consistency across the two documents. The linking engine builds a bipartite graph of document-entity relationships and uses connected components to identify cases automatically."
+      },
       {
         type: "callout",
         variant: "info",
         text: "The **Field Registry** is the heart of the platform. As you process more documents, the registry grows \u2014 fields are clustered semantically, promoted through tiers, and enriched with master extraction instructions. This accumulated knowledge makes every subsequent extraction faster and more accurate."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "exploring-concepts-via-api",
+        text: "Exploring Concepts via API"
+      },
+      {
+        type: "paragraph",
+        text: "Every core concept in the platform has a corresponding API namespace. You can list documents, browse the field registry, inspect schemas, retrieve job results, and explore cases programmatically. For example, to see all fields discovered across your documents, query the field registry endpoint. The response includes each field's canonical name, tier, occurrence count, and data type \u2014 giving you a complete picture of your knowledge graph."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List fields in the registry",
+        code: 'curl https://api.talonic.com/v1/schemas \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "data": [\n    {\n      "id": "sch_inv_001",\n      "name": "Invoice",\n      "fields_count": 18,\n      "document_type": "Invoice",\n      "version": 3\n    }\n  ],\n  "meta": { "total": 12, "cursor": "eyJpZCI6MTJ9" }\n}'
+      },
+      {
+        type: "paragraph",
+        text: "The relationship between concepts is visible through the API as well. When you retrieve a job result, each cell includes provenance metadata that tells you which pipeline phase filled it, the confidence score, and the reasoning trace. This end-to-end traceability from source document through the field registry to structured output is what makes Talonic auditable at every step of the pipeline."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Retrieve job results with provenance",
+        code: 'curl https://api.talonic.com/v1/jobs/job_abc123 \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
       }
     ],
     related: [
@@ -587,6 +659,10 @@ var sections = [
       {
         question: "What is the difference between a Generated Schema and a Template Schema?",
         answer: "Generated Schemas are created automatically by the platform based on the document types it discovers. Template Schemas are user-defined for specific output needs \u2014 you choose which fields to include and how they map to the Field Registry."
+      },
+      {
+        question: "Can I explore all core concepts through the API?",
+        answer: "Yes. Every core concept has a corresponding API namespace. Documents are at /v1/documents, schemas at /v1/schemas, jobs at /v1/jobs, cases at /v1/cases, and the field registry at /v1/schemas/fields. You can list, inspect, and manage each concept programmatically with the same data available in the web interface."
       }
     ],
     mentions: [
@@ -643,10 +719,46 @@ var sections = [
         type: "paragraph",
         text: "After results are delivered, the feedback loop closes automatically. Corrections you make during the **Review** stage feed back into the Field Registry, improving future extractions. The platform tracks telemetry across runs \u2014 strategy distribution, capture hit rate, and resolve rate \u2014 so you can monitor how extraction quality improves over time as the knowledge graph accumulates more data."
       },
+      {
+        type: "paragraph",
+        text: "Each stage of the pipeline is observable through both the web interface and the API. The Dashboard provides a visual overview of pipeline progress across all five stages, while the telemetry API exposes the same metrics programmatically. For production deployments, teams often integrate these telemetry endpoints with external monitoring tools like Grafana or Datadog to maintain continuous visibility into pipeline health, extraction quality trends, and processing throughput."
+      },
       {
         type: "callout",
         variant: "info",
         text: "The **Dashboard** provides a real-time view of your pipeline progress with telemetry on strategy distribution, tier funnel, capture hit rate, and per-field state distribution. Use it to understand how well the knowledge graph is performing."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "automating-the-flow",
+        text: "Automating the Flow via API"
+      },
+      {
+        type: "paragraph",
+        text: "The entire platform flow can be automated through the REST API. Upload documents to a source, wait for extraction to complete (or receive a webhook notification), then create a job run against a schema. The API follows the same seven-stage pipeline as the web interface \u2014 the only difference is that each step is triggered programmatically instead of through the UI. This makes it straightforward to embed Talonic into existing data pipelines or orchestration tools."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Create a job run via API",
+        code: `curl -X POST https://api.talonic.com/v1/jobs \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "schema_id": "sch_inv_001",
+    "document_ids": ["doc_7f3a1b2c", "doc_9e4d5f6a"]
+  }'`
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "id": "job_x8k2m9",\n  "status": "running",\n  "schema_id": "sch_inv_001",\n  "documents_count": 2,\n  "phase": 1,\n  "created_at": "2026-05-07T14:22:00Z"\n}'
+      },
+      {
+        type: "paragraph",
+        text: "For production deployments, combine source connectors with routing rules and delivery bindings to create a fully hands-off pipeline. Documents arrive from Google Drive or S3, routing rules assign the correct schema and trigger extraction, and delivery bindings push approved results to your webhook endpoint or cloud storage. The platform handles retries, deduplication, and error escalation automatically, so you only need to intervene when the dead-letter queue flags a terminal failure."
       }
     ],
     related: [
@@ -670,6 +782,14 @@ var sections = [
       {
         question: "What delivery destinations are supported?",
         answer: "Six live connectors: webhook (with HMAC-SHA256 signing), SFTP, Amazon S3, Azure Blob Storage, Google Drive, and OneDrive. Additional integrations for Sheets, SharePoint, Gmail, Outlook, and HubSpot are planned."
+      },
+      {
+        question: "Can I automate the entire platform flow end-to-end?",
+        answer: "Yes. Combine source connectors (to ingest documents automatically), routing rules (to assign schemas and trigger jobs), and delivery bindings (to push results downstream). This creates a fully automated pipeline where documents flow from ingestion through extraction and delivery with zero manual intervention. You can monitor the pipeline health from the Dashboard or via the telemetry API."
+      },
+      {
+        question: "How do I create a job run via the API?",
+        answer: "POST to /v1/jobs with a schema_id and an array of document_ids. The response includes a job ID that you can poll for status and results. Jobs run asynchronously through the 4-phase pipeline, and you can retrieve partial results while later phases are still running. Configure a webhook with the run.dataspace.completed signal to receive a notification when the full job finishes."
       }
     ],
     mentions: [
@@ -713,6 +833,10 @@ var sections = [
         type: "paragraph",
         text: "The platform includes powerful keyboard shortcuts for fast navigation. Press `Cmd+K` (or `Ctrl+K` on Windows) to open **Omnisearch**, which lets you find documents, schemas, jobs, and fields from anywhere. Press `Cmd+I` to open the **AI Agent** for natural language queries about your workspace. The sidebar can be collapsed to give more screen real estate when reviewing extraction results."
       },
+      {
+        type: "paragraph",
+        text: "If you plan to integrate Talonic into an existing data pipeline, start by creating an API key from **Settings → API Keys**. The REST API mirrors every action available in the web interface, so you can upload documents, retrieve extraction results, create schemas, and configure delivery bindings programmatically. Many teams begin with the UI for initial exploration and then transition to API-driven workflows as their integration matures."
+      },
       {
         type: "callout",
         text: "The fastest path to results: upload documents in **Sources**, then go to **Structuring → Runs → New** to create your first extraction job."
@@ -727,6 +851,38 @@ var sections = [
           "Create a new **Run** by selecting a schema and the documents to process.",
           "Review results in the run view \u2014 each cell shows confidence, provenance, and reasoning."
         ]
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "getting-started-api",
+        text: "Getting Started with the API"
+      },
+      {
+        type: "paragraph",
+        text: "If you prefer to integrate programmatically, the REST API lets you upload documents, retrieve results, and manage schemas without the web interface. Start by creating an API key from Settings, then use the extract endpoint to submit your first document. The response includes extraction status that you can poll until processing completes, or configure a webhook to receive a notification automatically when results are ready."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Submit a document for extraction",
+        code: 'curl -X POST https://api.talonic.com/v1/sources/src_abc123/documents \\\n  -H "Authorization: Bearer $TALONIC_API_KEY" \\\n  -F "file=@contract.pdf"'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Check document processing status",
+        code: 'curl https://api.talonic.com/v1/documents/doc_7f3a1b2c \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "id": "doc_7f3a1b2c",\n  "status": "completed",\n  "document_type": "Employment Contract",\n  "source_id": "src_abc123",\n  "fields_extracted": 31,\n  "created_at": "2026-05-07T10:30:00Z"\n}'
+      },
+      {
+        type: "paragraph",
+        text: "Once you are comfortable with single-document extraction, explore batch processing for high-volume workloads. Set `processing_mode=batch` when uploading to defer AI extraction and run at 50% cost with a 48-hour delivery window. This is ideal for historical backlogs where immediate results are not required. You can monitor batch progress from the Sources page or poll the batch status endpoint via the API."
       }
     ],
     related: [
@@ -750,6 +906,14 @@ var sections = [
       {
         question: "What source connections are available?",
         answer: "Ten source connectors: Google Drive, Gmail, SharePoint, OneDrive, Outlook, Teams, Notion, SQL databases (MSSQL/PostgreSQL), Amazon S3, and Azure Blob Storage. You can also upload files manually or ingest via the REST API."
+      },
+      {
+        question: "How do I upload my first document via the API?",
+        answer: "Create an API key from Settings, then POST a file to /v1/sources/:sourceId/documents with your key in the Authorization: Bearer header. The platform processes the document automatically through OCR, classification, and extraction. Poll the document status endpoint or configure a webhook to know when results are ready. Most documents complete processing within one to two minutes."
+      },
+      {
+        question: "What is the recommended approach for teams processing documents at scale?",
+        answer: "Start with a small representative sample of 5-10 documents of the same type. Let the platform extract and classify them, then review the auto-generated schema. This validates the output structure before committing to a large batch. Once the schema is confirmed, upload your full document set. As the knowledge graph matures, an increasing share of cells resolve via free graph lookups rather than AI extraction, reducing cost over time."
       }
     ],
     mentions: ["sidebar", "sources", "structuring", "outputs", "navigation", "Cmd+K", "source connectors"]
@@ -781,6 +945,10 @@ 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 (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: "paragraph",
+        text: 'The agent is particularly effective for onboarding new team members. Instead of reading documentation about each platform feature, new users can ask the agent questions like "How many document types do we have?", "What schemas are available?", or "Show me our most common fields." The agent provides instant, contextual answers that help users build a mental model of their workspace. This reduces time-to-productivity for new team members from days to hours.'
+      },
       { type: "heading", level: 3, id: "agent-capabilities", text: "What the Agent Can Do" },
       {
         type: "paragraph",
@@ -831,6 +999,36 @@ var sections2 = [
             description: "Check delivery status and preview binding output."
           }
         ]
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "agent-example-prompts",
+        text: "Example Agent Interactions"
+      },
+      {
+        type: "paragraph",
+        text: "The agent excels at cross-cutting queries that would otherwise require navigating multiple pages. For example, you can ask it to summarize extraction quality across your latest job runs, identify which document types have the lowest confidence scores, or compare field coverage between two schemas. The agent queries the underlying data in real time and streams results, so complex analyses that would take several minutes of manual navigation are answered in seconds."
+      },
+      {
+        type: "paragraph",
+        text: 'Schema creation through the agent is particularly powerful. Describe the fields you need in plain language \u2014 for example, "Create a schema for purchase orders with vendor name, PO number, line items, unit price, and total amount" \u2014 and the agent maps each field to the registry, identifies the best match for each, and creates a draft schema ready for your review. This is faster than manually searching the registry and adding fields one by one through the schema editor.'
+      },
+      {
+        type: "paragraph",
+        text: 'Behind the scenes, the agent uses the same internal APIs as the web interface. When you ask "Show me all invoices processed this week", the agent queries the documents endpoint with date filters and the Invoice document type. When you ask "What is my capture rate?", it reads the telemetry data from the dashboard service. This means the agent always shows the same data you would see in the UI \u2014 there is no separate data layer or cache that could show stale results.'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Query documents via API (equivalent to agent search)",
+        code: 'curl "https://api.talonic.com/v1/documents?type=Invoice&created_after=2026-05-01" \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "data": [\n    {\n      "id": "doc_7f3a1b2c",\n      "filename": "invoice_2026_0472.pdf",\n      "document_type": "Invoice",\n      "status": "completed",\n      "fields_extracted": 24\n    }\n  ],\n  "meta": { "total": 156, "cursor": "eyJpZCI6MTU2fQ" }\n}'
       }
     ],
     related: [
@@ -857,6 +1055,10 @@ var sections2 = [
       {
         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.'
+      },
+      {
+        question: "How does the agent help with onboarding new team members?",
+        answer: 'New team members can ask the agent questions about the workspace to quickly build a mental model of available data \u2014 "How many document types do we have?", "What schemas are available?", or "Show me our most common fields." The agent provides instant, contextual answers that reduce onboarding time from days to hours. It also helps new users discover platform features by suggesting relevant follow-up questions.'
       }
     ],
     mentions: [
@@ -936,9 +1138,39 @@ var sections2 = [
         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: "paragraph",
+        text: "When the agent classifies a message as a command rather than a question, it evaluates the impact level before executing. The classification happens transparently \u2014 you see which impact level was assigned and what action the agent intends to take before any confirmation is requested. This transparency lets you understand exactly what will happen and make an informed decision about whether to proceed. If the agent misclassifies a question as a command, you can simply decline the confirmation and rephrase your request."
+      },
       {
         type: "callout",
         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."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "impact-api-context",
+        text: "Impact Levels and API Operations"
+      },
+      {
+        type: "paragraph",
+        text: "The impact level system mirrors the permission model of the REST API. Read-level agent actions correspond to GET requests, draft mutations correspond to POST/PATCH operations on draft resources, and live mutations correspond to POST operations that affect published schemas or trigger job runs. When building automations that combine the agent with API calls, keep this mapping in mind \u2014 the same permission boundaries apply regardless of the interface you use."
+      },
+      {
+        type: "paragraph",
+        text: "For example, when the agent creates a schema draft, it internally calls the same endpoint as the API. You can subsequently retrieve or modify that draft through the API if you prefer. This interoperability means you can start exploring in the agent, then switch to the API for scripted workflows without losing any work. Draft schemas created by the agent appear in the same list as drafts created through the UI or API."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List schema drafts (includes agent-created drafts)",
+        code: 'curl "https://api.talonic.com/v1/schemas?status=draft" \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "data": [\n    {\n      "id": "sch_draft_001",\n      "name": "Purchase Order - Draft",\n      "status": "draft",\n      "fields_count": 8,\n      "created_by": "agent",\n      "created_at": "2026-05-07T09:15:00Z"\n    }\n  ],\n  "meta": { "total": 3 }\n}'
       }
     ],
     related: [
@@ -957,6 +1189,14 @@ var sections2 = [
       {
         question: "What happens when I ask the agent to delete something?",
         answer: 'Deletion is classified as an irreversible action. The agent will ask you to type a confirmation keyword (e.g., "DELETE") before proceeding. This prevents accidental data loss from casual or ambiguous requests.'
+      },
+      {
+        question: "Can I retrieve agent-created drafts through the API?",
+        answer: "Yes. Schema drafts created by the agent are standard draft resources. You can list, inspect, modify, and publish them through the REST API at /v1/schemas just like drafts created through the web interface. The created_by field indicates whether a draft was created by the agent, the UI, or the API."
+      },
+      {
+        question: "What happens if the agent misclassifies my question as a command?",
+        answer: 'If the agent classifies a question as a command, you see the assigned impact level and intended action before any confirmation is requested. You can simply decline the confirmation and rephrase your request as a question. For example, instead of "Delete the test schema", try "What schemas do I have that contain the word test?" The agent adapts to your phrasing and routes accordingly.'
       }
     ],
     mentions: ["impact levels", "draft mutation", "live mutation", "workshop-first"]
@@ -998,6 +1238,42 @@ var sections2 = [
         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.'
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "dashboard-api-metrics",
+        text: "Dashboard Metrics via API"
+      },
+      {
+        type: "paragraph",
+        text: "The same metrics visible on the dashboard are available programmatically through the telemetry API. This lets you build custom dashboards, feed metrics into monitoring tools like Grafana or Datadog, or set up automated alerts when key metrics drop below thresholds. For example, you can track your resolve rate over time and alert your team when it drops, which might indicate that a new document type is introducing unfamiliar fields that need registry attention."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Retrieve telemetry metrics",
+        code: 'curl https://api.talonic.com/v1/telemetry \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "capture_rate": 0.87,\n  "resolve_rate": 0.62,\n  "synthesize_rate": 0.74,\n  "documents_processed": 1247,\n  "fields_in_registry": 342,\n  "period": "last_30_days"\n}'
+      },
+      {
+        type: "paragraph",
+        text: "The dashboard also integrates with the credit and usage tracking system. You can see at a glance how many credits have been consumed, what percentage came from extraction versus OCR, and how batch processing has reduced your overall costs. This financial visibility is essential for teams managing extraction budgets across multiple departments or clients, as it helps you allocate costs accurately and identify opportunities for optimization."
+      },
+      {
+        type: "paragraph",
+        text: "The suggested prompts system is context-sensitive and adapts to your workspace lifecycle. When you first start using the platform with few documents, the prompts focus on getting started \u2014 uploading documents and creating your first schema. As your workspace matures with hundreds of documents and established schemas, the prompts shift toward quality analysis, extraction optimization, and delivery configuration. This progressive guidance helps teams at every stage of adoption without overwhelming new users with advanced features."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Get workspace overview (similar to dashboard view)",
+        code: 'curl https://api.talonic.com/v1/credits \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
       }
     ],
     related: [
@@ -1016,6 +1292,18 @@ var sections2 = [
       {
         question: "Can I revisit previous conversations with the agent?",
         answer: "Yes. Every conversation is preserved in your session history, accessible from the dashboard. You can revisit previous questions, recall how you configured a schema, or pick up where you left off in a previous analysis."
+      },
+      {
+        question: "Can I access dashboard metrics through the API?",
+        answer: "Yes. The telemetry API exposes the same capture rate, resolve rate, and synthesize rate metrics visible on the dashboard. Use GET /v1/telemetry with your API key to retrieve current metrics programmatically. This is useful for building custom dashboards, feeding data into monitoring tools, or setting up automated alerts when metrics drop below acceptable thresholds."
+      },
+      {
+        question: "How often are dashboard metrics refreshed?",
+        answer: "Dashboard metrics are cached with a 30-second refresh interval. This means the data you see is at most 30 seconds old. The telemetry API follows the same caching behavior, so polling more frequently than every 30 seconds will return identical results."
+      },
+      {
+        question: "Can I build a custom dashboard using the API?",
+        answer: "Yes. The telemetry API at /v1/telemetry exposes capture rate, resolve rate, synthesize rate, and other metrics programmatically. The credits API at /v1/credits provides usage and cost data. Combine these endpoints with your preferred visualization tool \u2014 Grafana, Datadog, or a custom BI dashboard \u2014 to build monitoring views tailored to your team's specific needs and alert thresholds."
       }
     ],
     mentions: ["dashboard", "suggested prompts", "workspace state", "agent input"]
@@ -1078,6 +1366,42 @@ var sections3 = [
         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."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "upload-via-api",
+        text: "Uploading via API"
+      },
+      {
+        type: "paragraph",
+        text: "For automated ingestion pipelines, you can upload documents programmatically through the REST API. The upload endpoint accepts multipart form data with the file and optional metadata. Each uploaded document flows through the same processing pipeline as manual uploads \u2014 OCR, classification, and extraction run automatically. You can optionally set `processing_mode=batch` to defer extraction at 50% cost for non-urgent documents."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Upload a document via API",
+        code: 'curl -X POST https://api.talonic.com/v1/sources/src_abc123/documents \\\n  -H "Authorization: Bearer $TALONIC_API_KEY" \\\n  -F "file=@invoice.pdf" \\\n  -F "processing_mode=sync"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "id": "doc_7f3a1b2c",\n  "filename": "invoice.pdf",\n  "status": "processing",\n  "source_id": "src_abc123",\n  "created_at": "2026-05-07T10:30:00Z"\n}'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List documents in a source",
+        code: 'curl https://api.talonic.com/v1/documents?source_id=src_abc123 \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "paragraph",
+        text: "When integrating with external systems, a common pattern is to upload documents via the API and then configure a webhook to receive notifications when extraction completes. This avoids the need to poll for status updates and lets your downstream system react immediately when structured data is available. The `document.extracted` webhook signal fires as soon as all fields have been captured and the document status transitions to `completed`."
+      },
+      {
+        type: "paragraph",
+        text: "For batch ingestion scenarios, set `processing_mode=batch` when uploading to defer AI extraction and process at 50% cost. Batch mode runs OCR and classification immediately but queues the extraction step for deferred processing with a 48-hour delivery window. This is ideal for historical document backlogs where immediate results are not required. You can mix batch and realtime uploads within the same source \u2014 each document's processing mode is independent."
       }
     ],
     related: [
@@ -1101,6 +1425,10 @@ var sections3 = [
       {
         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."
+      },
+      {
+        question: "Can I upload documents programmatically via the API?",
+        answer: "Yes. POST a multipart form request to /v1/sources/:sourceId/documents with the file and optional processing_mode parameter. Set processing_mode=batch for 50% cost deferral with 48-hour delivery, or omit it for immediate processing. The API follows the same pipeline as the UI \u2014 documents flow through OCR, classification, and extraction automatically after upload."
       }
     ],
     mentions: [
@@ -1169,6 +1497,42 @@ var sections3 = [
         type: "callout",
         variant: "info",
         text: "The processing path is selected automatically based on the file extension \u2014 you do not need to configure anything. If a file type is not recognized, the platform will attempt OCR as a fallback before marking it as unsupported."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "format-detection-api",
+        text: "Format Detection in the API"
+      },
+      {
+        type: "paragraph",
+        text: "When uploading files through the REST API, the platform detects the file format from the file extension and routes it to the appropriate processing path automatically. You do not need to specify the file type in the request \u2014 simply upload the file and the platform handles format detection, OCR engine selection, and extraction pipeline routing. The document detail response includes a `processing_pipeline` field that indicates which path was used, so you can verify how each document was processed."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Upload a spreadsheet for processing",
+        code: 'curl -X POST https://api.talonic.com/v1/sources/src_abc123/documents \\\n  -H "Authorization: Bearer $TALONIC_API_KEY" \\\n  -F "file=@financials.xlsx"'
+      },
+      {
+        type: "paragraph",
+        text: "For bulk ingestion scenarios, consider the performance characteristics of each processing path. Text fast-path files (CSV, JSON, TXT) process almost instantly since they require no external API calls. OCR files (PDF, DOCX, XLSX) take longer because they pass through Document AI, but large PDFs are automatically chunked and processed in parallel to maintain throughput. Image files go through AI Vision which is the most computationally intensive path but produces excellent results for receipts, handwritten notes, and diagrams."
+      },
+      {
+        type: "paragraph",
+        text: "When choosing between file formats for the same content, prefer native digital formats over scanned images whenever possible. A native PDF with embedded text processes faster and more accurately than a scanned PDF image, because the native version can use the text fast-path or lighter OCR processing. Similarly, providing data in CSV or JSON format when available eliminates OCR cost entirely and produces the highest confidence extraction results. For spreadsheets, both XLSX and XLS formats are fully supported, along with the macro-enabled XLSM variant."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Check document processing path",
+        code: 'curl https://api.talonic.com/v1/documents/doc_7f3a1b2c \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "id": "doc_7f3a1b2c",\n  "filename": "financials.xlsx",\n  "processing_pipeline": "document_ai",\n  "status": "completed",\n  "document_type": "Financial Statement",\n  "fields_extracted": 42\n}'
       }
     ],
     related: [
@@ -1187,6 +1551,10 @@ var sections3 = [
       {
         question: "How does Talonic handle large PDF files?",
         answer: "PDF files that exceed the configured chunk size (default 25 pages) are automatically split into page chunks, processed in parallel, and merged. This ensures even large documents are handled efficiently without timeouts."
+      },
+      {
+        question: "Can I check which processing path was used for a document?",
+        answer: "Yes. The document detail response includes a processing_pipeline field that indicates which path was used \u2014 document_ai for OCR files, vision for images, or direct for text fast-path files. You can retrieve this via the API at GET /v1/documents/:id or view it in the Processing Log tab of the document detail page in the web interface."
       }
     ],
     mentions: ["OCR", "AI vision", "text fast-path", "file formats", "PDF", "DOCX", "ZIP"]
@@ -1262,20 +1630,56 @@ var sections3 = [
       {
         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 field resolution, which runs separately and enriches the registry in the background."
-      }
-    ],
-    related: [
-      { label: "Document Types", slug: "document-types" },
-      { label: "Document Detail", slug: "document-detail" },
-      { label: "Field Registry", slug: "field-registry" }
-    ],
-    faq: [
-      {
-        question: "How does document processing work in Talonic?",
-        answer: "Documents go through three stages: Document AI OCR (converts to Markdown with annotations), Classification (verifies against 529-type ontology), and AI Data Field Capture (extracts every data point)."
       },
       {
-        question: "When is a document ready to use in jobs?",
+        type: "heading",
+        level: 3,
+        id: "processing-api",
+        text: "Monitoring Processing via API"
+      },
+      {
+        type: "paragraph",
+        text: "You can monitor document processing programmatically by polling the document detail endpoint. The response includes the current status (processing, completed, extraction_failed, or ocr_failed), the document type assigned during classification, and the number of fields extracted. For high-volume pipelines, configure a webhook with the `document.extracted` signal to receive push notifications instead of polling, which reduces API calls and provides faster response times."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Check document processing status",
+        code: 'curl https://api.talonic.com/v1/documents/doc_7f3a1b2c \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "id": "doc_7f3a1b2c",\n  "status": "completed",\n  "document_type": "Invoice",\n  "fields_extracted": 24,\n  "processing_pipeline": "document_ai",\n  "extraction_attempts": 1,\n  "created_at": "2026-05-07T10:30:00Z"\n}'
+      },
+      {
+        type: "paragraph",
+        text: "For documents that fail processing, the API response includes diagnostic information about what went wrong. The `extraction_attempts` field shows how many retries were attempted, and the `status` field distinguishes between OCR failures (`ocr_failed`) and extraction failures (`extraction_failed`). This information helps you decide whether to resubmit the document, try a different file format, or investigate the source document for quality issues like low-resolution scans or corrupted files."
+      },
+      {
+        type: "paragraph",
+        text: "The processing pipeline also supports `include_markdown=true` on extraction requests, which returns the OCR-generated markdown alongside the extraction results. This is useful for debugging and quality assurance workflows where you need to verify what the AI model saw before extracting fields. You can also retrieve the markdown separately at any time using the dedicated markdown endpoint, which returns the full structured markdown representation of the document including preserved tables, headings, and layout information."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Retrieve the OCR markdown for a document",
+        code: 'curl https://api.talonic.com/v1/documents/doc_7f3a1b2c/markdown \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      }
+    ],
+    related: [
+      { label: "Document Types", slug: "document-types" },
+      { label: "Document Detail", slug: "document-detail" },
+      { label: "Field Registry", slug: "field-registry" }
+    ],
+    faq: [
+      {
+        question: "How does document processing work in Talonic?",
+        answer: "Documents go through three stages: Document AI OCR (converts to Markdown with annotations), Classification (verifies against 529-type ontology), and AI Data Field Capture (extracts every data point)."
+      },
+      {
+        question: "When is a document ready to use in jobs?",
         answer: "Documents are marked complete after AI extraction finishes. You can start using them in jobs immediately without waiting for further processing."
       },
       {
@@ -1337,6 +1741,36 @@ var sections3 = [
         type: "callout",
         variant: "info",
         text: "You never need to create document types manually. The ontology is built into the platform and types are assigned automatically during classification. If you disagree with a classification, the AI agent can help you understand why a type was chosen and how the content signals were interpreted."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "document-types-api",
+        text: "Working with Document Types via API"
+      },
+      {
+        type: "paragraph",
+        text: "The REST API lets you filter documents by type, which is useful for building type-specific processing pipelines. For example, you might retrieve all invoices for a financial reconciliation workflow, or all employment contracts for an HR onboarding integration. The document type is assigned automatically during classification and included in every document response, so you can route processing logic based on the type without any manual tagging."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List documents by type",
+        code: 'curl "https://api.talonic.com/v1/documents?type=Invoice" \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "data": [\n    {\n      "id": "doc_7f3a1b2c",\n      "filename": "invoice_0472.pdf",\n      "document_type": "Invoice",\n      "status": "completed",\n      "fields_extracted": 24\n    },\n    {\n      "id": "doc_9e4d5f6a",\n      "filename": "inv_march_2026.pdf",\n      "document_type": "Invoice",\n      "status": "completed",\n      "fields_extracted": 19\n    }\n  ],\n  "meta": { "total": 89, "cursor": "eyJpZCI6ODl9" }\n}'
+      },
+      {
+        type: "paragraph",
+        text: "The classification system works particularly well with mixed-document uploads. When you upload a ZIP archive or folder containing invoices, contracts, and receipts, each document is classified independently. You can then use type-based filtering to process each category through its own schema and job pipeline, even though they were uploaded together. This makes it practical to ingest heterogeneous document batches without pre-sorting."
+      },
+      {
+        type: "paragraph",
+        text: 'Behind the scenes, classification uses a two-step verification process. First, Document AI OCR produces a free-text type label during the initial processing pass. Then, a type resolution step verifies that label against the actual document content by checking it against the full 529-type ontology. If the label and content signals disagree \u2014 which commonly happens with multilingual documents or ambiguous formats \u2014 the system trusts the content and resolves to the correct canonical type. For example, a German Arbeitsvertrag might initially be labelled as "Service Agreement" by the OCR engine, but the content-based resolution correctly identifies it as "Employment Contract" based on the actual text.'
       }
     ],
     related: [
@@ -1356,6 +1790,14 @@ var sections3 = [
       {
         question: "What happens if a document cannot be classified?",
         answer: 'Unresolvable documents are assigned the "Unclassified Document" type. They can still be processed and extracted \u2014 the platform simply cannot map them to a specific canonical type in the 529-type ontology.'
+      },
+      {
+        question: "Can I filter documents by type through the API?",
+        answer: "Yes. The /v1/documents endpoint accepts a type query parameter to filter by document type. For example, GET /v1/documents?type=Invoice returns only documents classified as invoices. This is useful for building type-specific processing pipelines or generating reports by document category."
+      },
+      {
+        question: "How does classification handle multilingual documents?",
+        answer: "The classifier works across all languages by analyzing content signals rather than relying solely on the OCR-produced label. During type resolution, the system checks the first 500 characters of actual document content against the full 529-type ontology using AI. This content-based approach ensures correct classification regardless of the document language \u2014 a German Arbeitsvertrag, a French Contrat de Travail, and an English Employment Contract all map to the same canonical type."
       }
     ],
     mentions: [
@@ -1422,6 +1864,36 @@ var sections3 = [
         type: "callout",
         variant: "info",
         text: "You can open the **AI Agent** (`Cmd+I`) from any document detail page. The agent automatically has the current document in scope and can answer questions about its fields, classification, or processing status without you needing to specify which document you mean."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "document-detail-api",
+        text: "Accessing Document Details via API"
+      },
+      {
+        type: "paragraph",
+        text: "The document detail information visible in the UI is fully accessible through the REST API. You can retrieve a document's extraction results, download the OCR markdown, and inspect the processing metadata programmatically. This is particularly useful for building quality assurance workflows where you need to verify extraction results across hundreds of documents without clicking through each one manually."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Get extraction results for a document",
+        code: 'curl https://api.talonic.com/v1/extractions/doc_7f3a1b2c \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "document_id": "doc_7f3a1b2c",\n  "fields": [\n    {\n      "name": "invoice_number",\n      "value": "INV-2026-0472",\n      "confidence": 0.98,\n      "source_text": "Invoice Number: INV-2026-0472",\n      "tier": 1\n    },\n    {\n      "name": "total_amount",\n      "value": "4,250.00",\n      "confidence": 0.95,\n      "source_text": "Total Due: $4,250.00",\n      "tier": 1\n    }\n  ]\n}'
+      },
+      {
+        type: "paragraph",
+        text: "The extraction response includes every field the AI discovered, along with its confidence score and the exact source text from the document. Fields with confidence below 0.70 typically warrant manual review, while fields above 0.90 are highly reliable. You can use this data to build automated validation rules \u2014 for example, flagging documents where critical fields like invoice_number or total_amount have low confidence scores and routing them to a human reviewer."
+      },
+      {
+        type: "paragraph",
+        text: "The document detail page also provides access to the OCR-generated markdown through both the UI and the API. This markdown representation preserves the document's structure \u2014 headings, tables, lists, and paragraphs \u2014 in a machine-readable format. Comparing the markdown against the extracted fields is a useful debugging technique: if a field is missing from the extraction, check whether the value appears in the markdown. If it does, the extraction model may need a master instruction to guide it to the right location. If it does not, the OCR stage may have missed the content, which can happen with low-resolution scans or complex layouts."
       }
     ],
     related: [
@@ -1441,6 +1913,14 @@ var sections3 = [
       {
         question: "What do the tier badges on fields mean?",
         answer: "Tier badges indicate how well-established a field is across your document corpus. Tier 1 (green) are universal core fields, Tier 2 (amber) are established promoted fields, and Tier 3 (gray) are newly discovered emerging fields."
+      },
+      {
+        question: "Can I retrieve extraction results via the API?",
+        answer: "Yes. Use GET /v1/extractions/:documentId to retrieve all extracted fields for a document, including values, confidence scores, source text, and tier information. You can also use GET /v1/documents/:id/markdown to retrieve the OCR-generated markdown of the original document for comparison."
+      },
+      {
+        question: "How do I debug a missing field in extraction results?",
+        answer: "Start by comparing the Raw Extraction tab against the Original File tab to confirm the field exists in the source document. Then check the OCR markdown (available via the Processing Log or the /v1/documents/:id/markdown API endpoint) to verify the OCR stage captured the relevant text. If the text is present in the markdown but the field is missing from extraction, a master instruction may be needed to guide the AI to the correct location. If the text is absent from the markdown, the OCR stage missed it \u2014 try re-uploading a higher-resolution version of the document."
       }
     ],
     mentions: [
@@ -1493,6 +1973,36 @@ var sections3 = [
         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. Review the execution history regularly to ensure documents are being routed as expected."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "routing-worked-example",
+        text: "Worked Example: Automated Invoice Pipeline"
+      },
+      {
+        type: "paragraph",
+        text: 'Consider a common scenario: your accounting team receives hundreds of invoices weekly via email and cloud storage. Without routing rules, someone must manually navigate to each new document, assign a schema, and trigger extraction. With routing, this entire workflow is automated. First, connect your Gmail or Google Drive source to ingest documents continuously. Then create a routing rule that matches the "Invoice" document type, assigns your Invoice schema, and triggers a job run. Every new invoice that arrives is now automatically processed end-to-end without any manual steps.'
+      },
+      {
+        type: "paragraph",
+        text: "To complete the automation, add a delivery binding that pushes approved results to your ERP system via webhook. The result is a fully hands-off pipeline: invoices arrive from email, the platform classifies them, extracts structured data using your schema, and delivers the results to your downstream system. You only need to intervene when the review queue flags a low-confidence extraction or when a new document type appears that does not match any existing routing rule."
+      },
+      {
+        type: "paragraph",
+        text: 'Rules are evaluated in priority order, which allows you to layer general and specific rules effectively. For example, you might set a priority-10 general rule that routes all "Invoice" documents to a standard invoice schema, then add a priority-1 specific rule that routes invoices from a particular source to a specialized vendor-specific schema. The higher-priority (lower number) rule wins when both match, giving you fine-grained control over routing behavior without duplicating configuration.'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List routing rules via API",
+        code: 'curl https://api.talonic.com/v1/routing-rules \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "data": [\n    {\n      "id": "rule_001",\n      "document_type": "Invoice",\n      "priority": 1,\n      "actions": ["assign_schema", "trigger_job"],\n      "schema_id": "sch_inv_001",\n      "enabled": true\n    }\n  ],\n  "meta": { "total": 4 }\n}'
       }
     ],
     related: [
@@ -1512,6 +2022,14 @@ 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. 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."
+      },
+      {
+        question: "Can I manage routing rules through the API?",
+        answer: "Yes. Routing rules can be listed and managed through the /v1/routing-rules endpoint. This allows you to programmatically create, update, or disable rules as part of your infrastructure automation. Each rule includes its document type trigger, priority, associated schema, and enabled status."
+      },
+      {
+        question: "How does routing rule priority work?",
+        answer: "Rules are evaluated in priority order \u2014 the lowest priority number wins when multiple rules match. This lets you layer general rules (e.g., priority 10 for all invoices) with specific overrides (e.g., priority 1 for invoices from a particular source). If multiple rules match the same document type, only the highest-priority rule executes. This design prevents duplicate processing while giving you fine-grained control over routing behavior for every document type."
       }
     ],
     mentions: ["routing rules", "auto-assign", "schema assignment", "document workflows"]
@@ -1620,6 +2138,32 @@ var sections3 = [
       {
         type: "callout",
         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`."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "connectors-api",
+        text: "Managing Sources via API"
+      },
+      {
+        type: "paragraph",
+        text: "Sources can be created, listed, and managed through the REST API. This is useful for automated provisioning scenarios where you need to set up sources programmatically \u2014 for example, creating a new source for each client or department as part of an onboarding workflow. The API also lets you trigger imports from connected sources, which is how you can build scheduled sync pipelines using external orchestration tools like cron jobs or workflow engines."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List all sources",
+        code: 'curl https://api.talonic.com/v1/sources \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "data": [\n    {\n      "id": "src_abc123",\n      "name": "Invoices - Google Drive",\n      "type": "google_drive",\n      "documents_count": 234,\n      "status": "connected",\n      "batch_processing": false\n    },\n    {\n      "id": "src_def456",\n      "name": "Contracts - Manual Upload",\n      "type": "upload",\n      "documents_count": 47,\n      "status": "active",\n      "batch_processing": true\n    }\n  ],\n  "meta": { "total": 5 }\n}'
+      },
+      {
+        type: "paragraph",
+        text: "For S3 and Azure Blob connectors, you can also use the API to create connections with encrypted credentials. The platform encrypts all credentials at rest using AES-256-GCM, so sensitive access keys and connection strings are never stored in plaintext. When listing sources through the API, credential values are redacted \u2014 only the connection status and metadata are returned to prevent accidental exposure of secrets in logs or dashboards."
       }
     ],
     related: [
@@ -1700,6 +2244,48 @@ var sections4 = [
       {
         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."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "field-registry-api",
+        text: "Browsing the Registry via API"
+      },
+      {
+        type: "paragraph",
+        text: "The Field Registry is fully accessible through the REST API, allowing you to build custom dashboards, export field data for analysis, or integrate registry information into external tools. You can list all fields with filtering by tier, type, and search terms, retrieve individual field details including all occurrences, and check resolution status. This programmatic access is particularly valuable for teams that need to audit their field registry or build automated monitoring around field quality."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Search the field registry",
+        code: 'curl "https://api.talonic.com/v1/schemas/fields?search=vendor&tier=1" \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "data": [\n    {\n      "id": "fld_001",\n      "canonical_name": "vendor_name",\n      "tier": 1,\n      "data_type": "string",\n      "occurrence_count": 312,\n      "synonyms": ["supplier_name", "company_name"],\n      "has_master_instruction": true\n    }\n  ],\n  "meta": { "total": 3 }\n}'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Get field detail with occurrences",
+        code: 'curl https://api.talonic.com/v1/schemas/fields/fld_001 \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "paragraph",
+        text: "You can also trigger batch resolution and promotion evaluation through the API. The resolution endpoint starts a batch run that resolves all unresolved field occurrences against the registry, while the promotion endpoint evaluates whether any Tier 3 fields qualify for promotion to Tier 2. These operations run asynchronously and you can poll their status to know when they complete. Running resolution and promotion regularly ensures your registry stays current as new documents are processed."
+      },
+      {
+        type: "paragraph",
+        text: "The registry also tracks aggregate statistics that help you understand the overall health and maturity of your knowledge graph. The stats endpoint returns total field count, breakdown by tier, instruction coverage percentage, and the number of unresolved occurrences. Teams use these metrics to set quality targets \u2014 for example, aiming for 80% instruction coverage and less than 5% unresolved occurrences before transitioning from pilot to production usage."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Get registry aggregate stats",
+        code: 'curl https://api.talonic.com/v1/schemas/stats \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
       }
     ],
     related: [
@@ -1719,6 +2305,14 @@ var sections4 = [
       {
         question: "How does the Field Registry reduce extraction cost?",
         answer: "The registry enables lookup-based resolution during job runs. When a field already exists in the registry with sufficient data, its value can be resolved via graph lookup instead of an AI call. Approximately 30% of cells are filled this way \u2014 instantly and at no cost."
+      },
+      {
+        question: "Can I search the field registry via the API?",
+        answer: "Yes. Use GET /v1/schemas/fields with search, tier, and type query parameters to filter registry entries. The response includes each field's canonical name, tier, occurrence count, synonyms, and whether it has a master instruction. This is useful for building custom dashboards or auditing field coverage across your document corpus."
+      },
+      {
+        question: "How do I check the overall health of my field registry?",
+        answer: "Use the GET /v1/schemas/stats endpoint to retrieve aggregate statistics including total field count, tier distribution, instruction coverage percentage, and unresolved occurrence count. Teams typically aim for 80% instruction coverage and less than 5% unresolved occurrences before transitioning from pilot to production. The dashboard telemetry metrics (capture rate, resolve rate, synthesize rate) also reflect registry maturity."
       }
     ],
     mentions: [
@@ -1785,6 +2379,53 @@ var sections4 = [
       {
         type: "callout",
         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."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "tier-api",
+        text: "Managing Tiers via API"
+      },
+      {
+        type: "paragraph",
+        text: "You can query fields by tier through the registry API to understand the maturity of your knowledge graph. Filtering by tier lets you identify which fields are well-established versus newly emerging, which helps prioritize registry curation efforts. For example, reviewing Tier 3 fields regularly helps you catch misclassifications early before they propagate into job results. You can also manually adjust a field's tier through the API when you have domain knowledge that justifies an early promotion or demotion."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List Tier 3 (emerging) fields",
+        code: 'curl "https://api.talonic.com/v1/schemas/fields?tier=3" \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Manually promote a field",
+        code: `curl -X PATCH https://api.talonic.com/v1/schemas/fields/fld_001/tier \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{ "tier": 2 }'`
+      },
+      {
+        type: "paragraph",
+        text: "The promotion evaluation can also be triggered programmatically. After a large document ingestion, you may want to run promotion immediately rather than waiting for the next automatic evaluation. The promotion endpoint scans all Tier 3 fields, checks them against the frequency thresholds (5 occurrences or 10% occurrence rate), and promotes qualifying fields to Tier 2. Promoted fields automatically receive synthesized master instructions and become eligible for lookup-based resolution in subsequent job runs."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Trigger promotion evaluation",
+        code: 'curl -X POST https://api.talonic.com/v1/schemas/promotion/run \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "View promotion candidates",
+        code: 'curl https://api.talonic.com/v1/schemas/emergence \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "candidates": [\n    {\n      "field_id": "fld_042",\n      "canonical_name": "payment_terms",\n      "current_tier": 3,\n      "occurrence_count": 7,\n      "occurrence_rate": 0.12,\n      "qualifies": true\n    }\n  ],\n  "total_candidates": 3\n}'
       }
     ],
     related: [
@@ -1798,11 +2439,15 @@ var sections4 = [
       },
       {
         question: "How are fields promoted between tiers?",
-        answer: "Fields are promoted automatically based on frequency thresholds. As more documents are processed and a field appears consistently, it moves from Tier 3 to Tier 2 and eventually to Tier 1."
+        answer: "Fields are promoted automatically based on frequency thresholds \u2014 5 occurrences or a 10% occurrence rate qualifies a Tier 3 field for promotion to Tier 2. As more documents are processed and a field appears consistently, it progresses through the tiers. Promotion is evaluated automatically after every batch resolution run, so fields graduate without manual intervention as your document corpus grows."
       },
       {
         question: "Can I manually change a field's tier?",
-        answer: "Yes. You can manually adjust a field's tier from the registry detail page. This is useful when you know a field is stable enough to promote early, or when you want to demote a field that was promoted prematurely."
+        answer: "Yes. You can manually adjust a field's tier from the registry detail page or via the API at PATCH /v1/schemas/fields/:id/tier. This is useful when you know a field is stable enough to promote early, or when you want to demote a field that was promoted prematurely. Manual tier changes take effect immediately and trigger the same downstream effects as automatic promotion \u2014 instruction synthesis and schema regeneration."
+      },
+      {
+        question: "What is the difference between Tier 1 and Tier 2 fields in practice?",
+        answer: "Both Tier 1 and Tier 2 fields have master instructions and are eligible for lookup-based resolution during job runs. The key difference is coverage and reliability. Tier 1 fields appear universally across most document types and have the highest occurrence counts, making their lookup matches extremely reliable. Tier 2 fields are well-established within specific document types but may not appear across all types. In job runs, both tiers benefit from free graph lookups, but Tier 1 fields consistently achieve a higher match rate because of their broader occurrence base across the entire document corpus."
       }
     ],
     mentions: ["tier system", "Tier 1", "Tier 2", "Tier 3", "field promotion", "quality signal"]
@@ -1849,6 +2494,48 @@ var sections4 = [
         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. Conversely, merging clusters that should be together improves resolution accuracy across your entire corpus."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "clusters-api",
+        text: "Working with Clusters via API"
+      },
+      {
+        type: "paragraph",
+        text: "Semantic clusters can be listed, merged, and split through the REST API. This is particularly useful for teams that need to perform bulk cluster curation or automate cluster management as part of their onboarding pipeline. For example, when setting up a new workspace, you might programmatically merge known field synonyms before processing your first batch of documents, ensuring the registry starts with clean, accurate clusters from day one."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List semantic clusters",
+        code: 'curl https://api.talonic.com/v1/schemas/clusters \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Merge two clusters",
+        code: `curl -X POST https://api.talonic.com/v1/schemas/clusters/merge \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "source_cluster_id": "cls_ship_to",
+    "target_cluster_id": "cls_delivery_addr"
+  }'`
+      },
+      {
+        type: "paragraph",
+        text: 'A well-curated cluster set has a direct impact on extraction cost and accuracy. When clusters accurately represent field synonyms, the resolution engine can transfer values between related fields without triggering an AI call. For instance, if "Ship To Address" and "Delivery Address" are correctly clustered together, a document containing "Ship To Address" will automatically resolve when your schema expects "Delivery Address". Without the cluster link, this would require an AI extraction call, increasing both cost and latency.'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Cluster detail response",
+        code: '{\n  "cluster_id": "cls_vendor",\n  "canonical_name": "vendor_name",\n  "members": [\n    { "field_id": "fld_001", "name": "vendor_name", "occurrence_count": 312 },\n    { "field_id": "fld_047", "name": "supplier_name", "occurrence_count": 89 },\n    { "field_id": "fld_103", "name": "company_name", "occurrence_count": 45 }\n  ],\n  "similarity_threshold": 0.82\n}'
+      },
+      {
+        type: "paragraph",
+        text: 'Cluster quality is especially important during the early stages of platform adoption. When your registry is still growing, incorrect clusters can cause value transfers between unrelated fields, leading to extraction errors that are difficult to trace. Take time during the first few weeks to review the Field Map view and split any clusters where the platform has grouped fields that look similar in name but have different semantic meanings. For example, "Order Date" and "Order Number" might score above the 0.80 similarity threshold due to the shared "Order" prefix, but they represent fundamentally different data types and should be separate clusters.'
       }
     ],
     related: [
@@ -1868,6 +2555,14 @@ var sections4 = [
       {
         question: "How do semantic clusters reduce extraction cost?",
         answer: 'When a job runs, the resolution engine uses clusters to transfer values between fields that belong to the same cluster. If a document has "Supplier Name" and your schema expects "Vendor Name", the cluster linkage allows the value to transfer automatically without an AI call.'
+      },
+      {
+        question: "Can I merge or split clusters via the API?",
+        answer: "Yes. Use POST /v1/schemas/clusters/merge to combine two clusters and POST /v1/schemas/clusters/split to remove a field from a cluster. These operations are permanent and immediately affect resolution behavior for all future documents and job runs."
+      },
+      {
+        question: "What is the similarity threshold for automatic clustering?",
+        answer: "Fields with semantic similarity >= 0.80 are automatically grouped into the same cluster. Fields in the 0.50-0.79 range are flagged as potential candidates for manual confirmation. Fields below 0.50 are kept separate. The thresholds are designed to prevent false merges while still surfacing useful grouping suggestions that you can review from the Field Map view."
       }
     ],
     mentions: [
@@ -1930,6 +2625,46 @@ var sections4 = [
       {
         type: "callout",
         text: "Pending confirmations from the confirm band appear in **Resolution → Pending Confirmations**. Accept to merge into an existing cluster, or reject to create a new field."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "resolution-api",
+        text: "Running Resolution via API"
+      },
+      {
+        type: "paragraph",
+        text: "Batch resolution can be triggered programmatically through the REST API. This is useful for teams that want to run resolution on a schedule or immediately after a large document ingestion. The resolution endpoint starts an asynchronous run that processes all unresolved field occurrences against the registry. You can check the resolution status endpoint to monitor how many fields remain unresolved and track progress over time."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Trigger batch resolution",
+        code: 'curl -X POST https://api.talonic.com/v1/schemas/resolution/run \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Check resolution status",
+        code: 'curl https://api.talonic.com/v1/schemas/resolution/status \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "unresolved_count": 14,\n  "total_occurrences": 1847,\n  "pending_confirmations": 6,\n  "last_run_at": "2026-05-07T09:00:00Z"\n}'
+      },
+      {
+        type: "paragraph",
+        text: "For best results, process pending confirmations promptly after each resolution run. Unconfirmed fields in the confirm band (0.50-0.79 similarity) remain in a pending state that can affect downstream extraction accuracy. Confirming correct matches strengthens the cluster and improves future resolution, while rejecting incorrect matches prevents bad data from propagating through the knowledge graph. Teams that review confirmations weekly typically see their auto-band match rate increase steadily over the first few months of platform usage."
+      },
+      {
+        type: "paragraph",
+        text: "The resolution system operates concurrently across documents with strict isolation guarantees. Each document's fields are resolved in an independent transaction, and occurrence counts are updated atomically using SQL upserts with a 3-attempt deadlock retry mechanism. This design means resolution can run on hundreds of documents simultaneously without lock contention or data inconsistency. The system is eventually consistent \u2014 all occurrence counts converge to the correct values even under high concurrent load."
+      },
+      {
+        type: "paragraph",
+        text: "After each resolution batch, a fixed chain of operations runs automatically: first tier promotion evaluation, then affected schema regeneration, and finally cross-schema view updates. This chain ensures that newly promoted fields immediately appear in auto-generated schemas and that the cross-schema harmonization view stays current. The chain is never interrupted \u2014 if promotion detects new Tier 2 fields, the downstream regeneration and view update steps run as part of the same workflow."
       }
     ],
     related: [
@@ -2006,6 +2741,48 @@ var sections4 = [
       {
         type: "callout",
         text: 'Click **"Synthesize All"** in the Field Registry to generate instructions for all qualifying fields. This runs the combined pipeline: embed → resolve → synthesize. The operation processes all fields that meet the synthesis criteria in a single batch.'
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "instructions-api",
+        text: "Managing Instructions via API"
+      },
+      {
+        type: "paragraph",
+        text: "Master instruction synthesis can be triggered and monitored through the REST API. The synthesis status endpoint shows how many fields have instructions versus how many qualify, giving you a clear picture of your registry's instruction coverage. You can trigger synthesis for all qualifying fields at once or for a single field. This is useful for automated workflows where you want to ensure instruction coverage stays above a threshold after each batch ingestion."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Check instruction synthesis status",
+        code: 'curl https://api.talonic.com/v1/schemas/instructions/status \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "total_fields": 342,\n  "with_instruction": 256,\n  "qualifying_without_instruction": 18,\n  "synthesize_rate": 0.74\n}'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Trigger synthesis for all qualifying fields",
+        code: 'curl -X POST https://api.talonic.com/v1/schemas/instructions/synthesize \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "paragraph",
+        text: "The quality of master instructions directly correlates with extraction accuracy. Fields with well-crafted instructions consistently produce higher confidence scores during job runs because the AI model receives specific guidance about where to find the value, what format to expect, and how to disambiguate similar fields. Teams that invest in reviewing and refining master instructions \u2014 either manually or through the synthesis pipeline \u2014 typically see a 10-15% improvement in extraction confidence for Tier 2 fields compared to extraction without instructions."
+      },
+      {
+        type: "paragraph",
+        text: 'A well-written master instruction typically includes three components: where to find the field in the document (e.g., "Look in the header area near the document date"), what format to expect (e.g., "Format as ISO 8601 date: YYYY-MM-DD"), and how to disambiguate from similar fields (e.g., "Prefer the issue date over the due date or payment date"). The AI synthesis process automatically generates instructions following this pattern by analyzing successful extractions, but you can always refine them manually when your domain expertise suggests a better approach.'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Synthesize instructions for a single field",
+        code: 'curl -X POST https://api.talonic.com/v1/schemas/instructions/synthesize/fld_001 \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
       }
     ],
     related: [
@@ -2025,6 +2802,14 @@ var sections4 = [
       {
         question: "Can I manually edit a master instruction?",
         answer: "Yes. You can view and edit master instructions from the field detail page in the registry. Editing overrides the AI-synthesized version, which is useful when you have domain expertise the AI has not captured."
+      },
+      {
+        question: "How can I check instruction coverage via the API?",
+        answer: "Use GET /v1/schemas/instructions/status to see how many fields have instructions, how many qualify but lack them, and the overall synthesize rate. You can trigger synthesis for all qualifying fields via POST /v1/schemas/instructions/synthesize, or for a single field via POST /v1/schemas/instructions/synthesize/:fieldId."
+      },
+      {
+        question: "What makes a good master instruction?",
+        answer: 'A well-written master instruction includes three components: where to find the field in the document (e.g., "Look in the header area near the document date"), what format to expect (e.g., "Format as ISO 8601 date: YYYY-MM-DD"), and how to disambiguate from similar fields (e.g., "Prefer the issue date over the due date"). The AI synthesis process generates instructions following this pattern automatically, but manual refinement based on domain expertise can further improve accuracy.'
       }
     ],
     mentions: [
@@ -2065,6 +2850,53 @@ var sections5 = [
         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: "code",
+        language: "bash",
+        title: "List generated schemas via API",
+        code: `curl -s https://api.talonic.com/v1/schemas \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "schemas": [
+#     {
+#       "id": "sch_abc123",
+#       "document_type": "Invoice",
+#       "version": 3,
+#       "field_count": 24,
+#       "created_at": "2025-04-12T10:30:00Z"
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Get a generated schema with fields",
+        code: `curl -s https://api.talonic.com/v1/schemas/sch_abc123 \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "id": "sch_abc123",
+#   "document_type": "Invoice",
+#   "version": 3,
+#   "fields": [
+#     {
+#       "name": "invoice_number",
+#       "data_type": "string",
+#       "tier": 1,
+#       "occurrence_count": 342,
+#       "master_instruction": "Extract the unique invoice identifier..."
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "When working with generated schemas programmatically, use the list endpoint to discover which document types have been identified, then fetch individual schemas to inspect their fields. The diff between any two versions can be computed by comparing field lists \u2014 added fields appear only in the newer version, removed fields only in the older, and modified fields show differences in data type, tier, or instruction text. This is the same logic the UI uses to render the visual diff view."
+      },
       {
         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. Generated schemas serve as a discovery tool to understand what the platform has found in your documents."
@@ -2087,6 +2919,10 @@ var sections5 = [
       {
         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. 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."
+      },
+      {
+        question: "How do I trigger schema regeneration for a specific document type?",
+        answer: "Use the POST /v1/schemas/generate/{typeId} endpoint to regenerate the schema for a single document type, or POST /v1/schemas/generate-all to regenerate all schemas. Regeneration scans the Field Registry for Tier 1 and Tier 2 fields, assembles the schema, and creates a new version. The process is idempotent \u2014 running it multiple times without registry changes produces no new versions."
       }
     ],
     mentions: ["generated schemas", "AI-generated", "versioning", "schema diff"]
@@ -2125,6 +2961,58 @@ var sections5 = [
         type: "paragraph",
         text: "For best results, keep templates focused on a single document type or closely related group of types. A template with 10-20 well-defined fields will produce higher accuracy than one with 50+ fields spanning unrelated domains. If you need different field sets for different document types, create separate templates and run targeted jobs for each."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Create a user template via API",
+        code: `curl -X POST https://api.talonic.com/v1/schemas \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "Invoice Extraction",
+    "description": "Standard invoice fields for AP processing",
+    "fields": [
+      { "display_name": "Invoice Number", "data_type": "string" },
+      { "display_name": "Invoice Date", "data_type": "date" },
+      { "display_name": "Total Amount", "data_type": "number" },
+      { "display_name": "Vendor Name", "data_type": "string" }
+    ]
+  }'
+
+# Response:
+# {
+#   "id": "us_def456",
+#   "name": "Invoice Extraction",
+#   "status": "draft",
+#   "field_count": 4,
+#   "created_at": "2025-04-15T08:00:00Z"
+# }`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Import a template from a CSV file",
+        code: `curl -X POST https://api.talonic.com/v1/schemas/from-file \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -F "file=@invoice_template.csv"
+
+# Response:
+# {
+#   "id": "us_ghi789",
+#   "name": "invoice_template",
+#   "status": "draft",
+#   "field_count": 12,
+#   "inferred_types": {
+#     "invoice_number": "string",
+#     "total_amount": "number",
+#     "invoice_date": "date"
+#   }
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "After creating a template via the API, you can add fields incrementally using the `POST /v1/schemas/{id}/fields` endpoint, trigger automatic registry matching with `POST /v1/schemas/{id}/rematch`, and publish an immutable version when ready. The API workflow mirrors the UI experience \u2014 create, configure, match, publish \u2014 but enables automation for teams that manage schemas programmatically or need to synchronize template definitions across environments."
+      },
       {
         type: "callout",
         text: "You can import templates from Excel, CSV, or JSON files using the **Import from file** option. Column headers become field names, and data types are inferred automatically. This is the fastest way to bootstrap a template from an existing spreadsheet."
@@ -2147,6 +3035,10 @@ var sections5 = [
       {
         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. This append-only versioning ensures that historical job results always reference the exact schema that produced them."
+      },
+      {
+        question: "How do I add fields to a template programmatically?",
+        answer: "Use POST /v1/schemas/{id}/fields with a JSON body specifying the display_name, data_type, and optionally a manual_instruction. After adding fields, call POST /v1/schemas/{id}/rematch to trigger automatic registry matching. Fields with exact name matches are linked instantly; semantic matches appear as suggestions for confirmation."
       }
     ],
     mentions: ["user templates", "schema creation", "field mapping", "reference tables", "publish"]
@@ -2234,6 +3126,49 @@ var sections5 = [
         type: "paragraph",
         text: 'For best results, use **manual instructions** sparingly and only for fields that the registry cannot match. A well-written instruction should describe the field in plain language, specify where in the document to look, and note any formatting expectations. Avoid vague instructions like "extract the value" \u2014 instead, write something like "Extract the net payment amount from the invoice summary section, excluding VAT."'
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Add a field with format constraint and reference table",
+        code: `curl -X POST https://api.talonic.com/v1/schemas/us_def456/fields \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "display_name": "Purchase Order Number",
+    "data_type": "string",
+    "manual_instruction": "Extract the PO number from the order reference section",
+    "constraints": {
+      "format": {
+        "type": "regex",
+        "pattern": "PO-\\\\d{6}",
+        "on_format_mismatch": "flag"
+      }
+    },
+    "modifiers": {
+      "max_length": 20
+    },
+    "output_name": "po_number"
+  }'`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Configure a bypass strategy (constant value)",
+        code: `curl -X PATCH https://api.talonic.com/v1/schemas/us_def456/fields/fld_xyz \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "strategy": "constant",
+    "constant_value": "USD"
+  }'
+
+# The field will always resolve to "USD" without any LLM call.
+# Bypass strategies execute during Phase 1, before AI extraction.`
+      },
+      {
+        type: "paragraph",
+        text: 'Schema features can be combined to build sophisticated field definitions. For example, a "Vendor Code" field might use a reference table for code mapping, a format constraint to validate the output format (`^V\\d{5}$`), an alias modifier to normalize legacy codes, and an output name remap for the downstream ERP system. Each feature operates at a different stage of the pipeline \u2014 bypass strategies in Phase 1, extraction instructions in Phase 2, reference table lookups in Phases 1 and 3, and modifiers plus format constraints in Phase 4 \u2014 so they compose without conflicts.'
+      },
       {
         type: "callout",
         text: "For the complete JSON Schema specification with all features, see the [Full Schema Reference](/docs/platform/schema-features) in the Platform Guide."
@@ -2256,6 +3191,10 @@ var sections5 = [
       {
         question: "In what order are modifiers applied to extracted values?",
         answer: "Modifiers run in a fixed order: format (date/number conversion) first, then alias (value mapping), then max_length (truncation). Constraints are evaluated after all modifiers complete."
+      },
+      {
+        question: "How do I configure a field to skip LLM extraction entirely?",
+        answer: 'Use a bypass strategy on the field. Set strategy to "constant" for a fixed value, "generator" for deterministic IDs, or "reference" for lookup-based resolution. Bypass strategies execute during Phase 1 at zero AI cost. If the bypass fails to produce a value, the field falls through to LLM extraction as a safety net.'
       }
     ],
     mentions: [
@@ -2317,6 +3256,61 @@ var sections5 = [
         type: "paragraph",
         text: "You can trigger a **Rematch** on all fields at any time from the template editor. This is useful after the registry has grown \u2014 fields that were previously unmapped may now find matches as new extractions contribute to the registry. For best results, use descriptive field names that reflect the actual data (e.g., `contract_start_date` rather than `field_1`)."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Trigger a rematch on all fields in a template",
+        code: `curl -X POST https://api.talonic.com/v1/schemas/us_def456/rematch \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "rematched": 12,
+#   "exact_matches": 8,
+#   "semantic_matches": 2,
+#   "unmapped": 2,
+#   "fields": [
+#     {
+#       "display_name": "Invoice Number",
+#       "match_status": "exact",
+#       "match_confidence": 1.0,
+#       "registry_field": "invoice_number"
+#     },
+#     {
+#       "display_name": "Billing Contact",
+#       "match_status": "semantic",
+#       "match_confidence": 0.72,
+#       "registry_field": "contact_name"
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List fields in the Field Registry",
+        code: `curl -s "https://api.talonic.com/v1/fields?tier=1&limit=20" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "fields": [
+#     {
+#       "id": "fr_abc",
+#       "canonical_name": "invoice_number",
+#       "tier": 1,
+#       "occurrence_count": 342,
+#       "synonyms": ["inv_no", "invoice_id", "bill_number"],
+#       "master_instruction": "Extract the unique invoice identifier..."
+#     }
+#   ],
+#   "total": 156
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "The rematch endpoint is particularly useful after bulk document ingestion. When a large batch of new documents introduces previously unseen fields into the registry, running a rematch on your templates can upgrade unmapped fields to exact or semantic matches without any manual configuration. The response includes a summary of how many fields changed status, so you can quickly assess whether the rematch had a meaningful impact on your template coverage."
+      },
       {
         type: "callout",
         text: "Field matching is read-only against the registry \u2014 it never creates new registry entries. If no match exists, the field stays unmapped until you provide a manual instruction or new documents introduce the field into the registry."
@@ -2339,6 +3333,10 @@ var sections5 = [
       {
         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 through processing additional documents. For best results, use descriptive field names that reflect the actual data rather than generic labels."
+      },
+      {
+        question: "What confidence threshold determines automatic vs manual matching?",
+        answer: "Matches above 0.8 confidence are auto-accepted \u2014 these are near-certain semantic equivalents. Matches between 0.5 and 0.8 appear as suggestions requiring your confirmation before they are applied. Matches below 0.5 are rejected and the field is classified as unmapped. You can adjust individual match decisions from the template editor at any time."
       }
     ],
     mentions: ["field matching", "exact match", "semantic match", "composite", "unmapped"]
@@ -2391,6 +3389,40 @@ var sections5 = [
         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: "code",
+        language: "bash",
+        title: "Example reference table CSV format",
+        code: `# reference_table_contract_types.csv
+# key,value
+# std_master,Master Agreement
+# std_master,Frame Agreement
+# std_service,Service Agreement
+# std_service,Service Contract
+# std_nda,Non-Disclosure Agreement
+# std_nda,NDA
+# std_nda,Confidentiality Agreement
+
+# Upload as part of a schema field:
+curl -X PATCH https://api.talonic.com/v1/schemas/us_def456/fields/fld_contract_type \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "reference_table": {
+      "entries": [
+        { "key": "std_master", "value": "Master Agreement" },
+        { "key": "std_master", "value": "Frame Agreement" },
+        { "key": "std_service", "value": "Service Agreement" },
+        { "key": "std_nda", "value": "Non-Disclosure Agreement" },
+        { "key": "std_nda", "value": "NDA" }
+      ]
+    }
+  }'`
+      },
+      {
+        type: "paragraph",
+        text: "Reference tables support multi-hop resolution chains for complex lookup scenarios. A resolution chain specifies a sequence of reference tables to consult in order \u2014 if the first table does not contain a match, the system tries the next table in the chain. This is useful when your data needs to traverse multiple mapping layers, such as resolving a local product code to a regional code and then to a global SKU. Each hop in the chain applies the same 3-tier lookup cascade independently, so you get the full normalization, fuzzy, and AI fallback at every step."
+      },
       {
         type: "callout",
         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."
@@ -2413,6 +3445,10 @@ var sections5 = [
       {
         question: "How should I format my reference table CSV?",
         answer: "Use two columns: the first column is the key (output code) and the second is the value (human-readable label). Include common variations and abbreviations as separate rows pointing to the same key for maximum Tier 1 hit rate."
+      },
+      {
+        question: "Can I use multiple reference tables in a resolution chain?",
+        answer: "Yes. Resolution chains allow multi-hop lookups where the output of one reference table becomes the input for the next. This is useful for complex mapping scenarios \u2014 for example, resolving a local product code to a regional code and then to a global SKU. Each hop applies the full 3-tier lookup cascade independently."
       }
     ],
     mentions: [
@@ -2432,19 +3468,47 @@ var sections5 = [
     content: [
       {
         type: "paragraph",
-        text: "Templates support a workshop system: **Live** (current published version, read-only), **Workshop** (mutable draft for editing), and **Version History** (timeline with diff summaries). When promoting a draft, the system detects breaking changes (field removals, type changes) and warns you."
+        text: "Templates support a workshop system: **Live** (current published version, read-only), **Workshop** (mutable draft for editing), and **Version History** (timeline with diff summaries). When promoting a draft, the system detects breaking changes (field removals, type changes) and warns you."
+      },
+      {
+        type: "paragraph",
+        text: "Start by editing fields in the **Workshop** draft, then use **Test Extraction** to compare draft results against the live version before publishing. The **Version History** timeline lets you review diff summaries between any two versions, making it easy to trace when a field was added, renamed, or removed and understand the impact on downstream jobs."
+      },
+      {
+        type: "paragraph",
+        text: "The versioning system is append-only \u2014 every time you publish a draft, it creates a new immutable version and the previous version is preserved in the timeline. This means you can always go back and review the exact schema that was used for any historical job. The diff view highlights added fields, removed fields, type changes, and updated instructions, giving you a clear picture of how your schema evolved."
+      },
+      {
+        type: "paragraph",
+        text: "Use the workshop system to iterate safely on your schema without disrupting production jobs. A common workflow is to add a new field in the Workshop, run a **Test Extraction** on a few documents to verify it produces correct values, then publish when satisfied. If a downstream integration depends on a specific field, the breaking change detection will warn you before you accidentally remove or rename it."
       },
       {
-        type: "paragraph",
-        text: "Start by editing fields in the **Workshop** draft, then use **Test Extraction** to compare draft results against the live version before publishing. The **Version History** timeline lets you review diff summaries between any two versions, making it easy to trace when a field was added, renamed, or removed and understand the impact on downstream jobs."
+        type: "code",
+        language: "bash",
+        title: "Get schema version history",
+        code: `curl -s "https://api.talonic.com/v1/schemas/us_def456" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response includes version history:
+# {
+#   "id": "us_def456",
+#   "name": "Invoice Extraction",
+#   "live_version": 3,
+#   "draft_status": "editing",
+#   "versions": [
+#     { "version": 3, "published_at": "2025-04-20T14:00:00Z", "field_count": 14 },
+#     { "version": 2, "published_at": "2025-04-10T09:00:00Z", "field_count": 12 },
+#     { "version": 1, "published_at": "2025-03-28T16:00:00Z", "field_count": 10 }
+#   ]
+# }`
       },
       {
         type: "paragraph",
-        text: "The versioning system is append-only \u2014 every time you publish a draft, it creates a new immutable version and the previous version is preserved in the timeline. This means you can always go back and review the exact schema that was used for any historical job. The diff view highlights added fields, removed fields, type changes, and updated instructions, giving you a clear picture of how your schema evolved."
+        text: "The version history is a complete audit trail of your schema evolution. Each version snapshot captures the full field set, data types, instructions, reference tables, format constraints, and modifiers as they existed at publish time. When investigating a historical job result, you can always reconstruct the exact schema configuration that produced it by looking up the version number referenced in the job run metadata. This traceability is critical for compliance workflows and data governance requirements where you need to prove exactly what extraction rules were in effect at any point in time."
       },
       {
         type: "paragraph",
-        text: "Use the workshop system to iterate safely on your schema without disrupting production jobs. A common workflow is to add a new field in the Workshop, run a **Test Extraction** on a few documents to verify it produces correct values, then publish when satisfied. If a downstream integration depends on a specific field, the breaking change detection will warn you before you accidentally remove or rename it."
+        text: "A common pattern for teams with strict governance requirements is to pair schema versioning with the Change Review feature. When Change Review is enabled, publishing a new schema version requires approval from a designated reviewer before it takes effect. This adds an extra safety layer on top of the breaking change detection, ensuring that both the technical impact and the business impact of schema changes are assessed before they reach production."
       },
       {
         type: "callout",
@@ -2468,6 +3532,10 @@ var sections5 = [
       {
         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. 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."
+      },
+      {
+        question: "How do I compare two schema versions programmatically?",
+        answer: "Fetch the full schema detail for each version using GET /v1/schemas/{id}. The response includes the complete field list with data types, instructions, and constraints for each version. Compare the field arrays to identify additions, removals, and modifications. The UI diff view performs this same comparison and highlights changes visually."
       }
     ],
     mentions: ["versioning", "drafts", "workshop", "live version", "breaking changes"]
@@ -2499,6 +3567,33 @@ var sections5 = [
         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: "code",
+        language: "bash",
+        title: "Run a test extraction via the Structure slide-over",
+        code: `# Test extractions use the simplified single-call mode.
+# From the API, create a job with extraction_type "simple":
+curl -X POST https://api.talonic.com/v1/jobs \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "schema_id": "us_def456",
+    "document_ids": ["doc_001", "doc_002", "doc_003"],
+    "extraction_type": "simple"
+  }'
+
+# Response:
+# {
+#   "run_id": "run_test_abc",
+#   "status": "processing",
+#   "extraction_type": "simple",
+#   "document_count": 3
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Test extraction results include a cell-by-cell comparison between the draft and live schema outputs. Each cell is classified as improved (the draft produces a better value), regressed (the draft produces a worse value), or unchanged. The comparison accounts for both the extracted value and its confidence score, so you can detect cases where the value is correct but the confidence dropped \u2014 which might indicate a fragile extraction instruction that should be refined before publishing."
+      },
       {
         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. Results are temporary and do not appear in your job history."
@@ -2521,6 +3616,10 @@ var sections5 = [
       {
         question: "How many documents should I use for a test extraction?",
         answer: "Select 3-5 representative documents that cover the variety in your corpus. Include documents with different layouts, data completeness levels, and edge cases to get a reliable preview of how your schema changes perform."
+      },
+      {
+        question: "Does test extraction apply all schema features like format constraints and modifiers?",
+        answer: "Yes. Test extractions run through the same pipeline as production jobs, including reference table lookups, format constraints, modifiers, and bypass strategies. The only difference is the simplified single-call extraction mode, which is faster but still applies all schema features during the transform and validate phase."
       }
     ],
     mentions: ["test extraction", "draft comparison", "side-by-side", "preview"]
@@ -2588,6 +3687,49 @@ var sections5 = [
         type: "paragraph",
         text: 'For best results, create a shared dialect for each downstream system or regional office you deliver to, and name it descriptively (e.g., "SAP Europe" or "US Accounting"). Avoid defining dialects inline on individual schemas unless you have a one-off formatting requirement. Shared dialects reduce maintenance burden and ensure consistency when you add new schemas later.'
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Create a shared dialect via API",
+        code: `curl -X POST https://api.talonic.com/v1/dialects \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "EU Accounting",
+    "date_format": "DD.MM.YYYY",
+    "number_locale": "de-DE",
+    "delimiter": ";",
+    "null_representation": "",
+    "boolean_format": "yes/no",
+    "encoding": "UTF-8-BOM"
+  }'
+
+# Response:
+# {
+#   "id": "dial_eu_001",
+#   "name": "EU Accounting",
+#   "created_at": "2025-04-18T12:00:00Z"
+# }`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List all dialects in the workspace",
+        code: `curl -s https://api.talonic.com/v1/dialects \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "dialects": [
+#     { "id": "dial_eu_001", "name": "EU Accounting", "date_format": "DD.MM.YYYY" },
+#     { "id": "dial_us_002", "name": "US Standard", "date_format": "MM/DD/YYYY" }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Dialects can be managed programmatically through the full CRUD API: create with POST, retrieve with GET, update with PUT, and delete with DELETE on the /v1/dialects endpoints. This is useful for teams that manage multiple workspaces and want to synchronize formatting conventions across environments. You can export a dialect configuration from one workspace and import it into another by replicating the JSON body, ensuring consistent output formatting across your entire organization."
+      },
       {
         type: "callout",
         text: "If your CSV files show garbled special characters (accents, umlauts, CJK text), switch the encoding to **UTF-8-BOM**. The BOM (byte order mark) tells Excel to interpret the file as UTF-8 instead of the system default encoding."
@@ -2610,6 +3752,10 @@ var sections5 = [
       {
         question: "Do I need to re-run extractions when I change a dialect?",
         answer: "No. Dialects only affect output serialization (exports and deliveries), not how values are stored internally. Changing a dialect takes effect immediately on future exports without re-processing."
+      },
+      {
+        question: "How do I apply a shared dialect to a specific schema?",
+        answer: "Navigate to the schema editor, open the Delivery tab, and select the shared dialect from the dropdown. Alternatively, use the PATCH /v1/schemas/{id} endpoint with a dialect_id field to link the dialect programmatically. The dialect applies to all future exports and deliveries for that schema without re-running extractions."
       }
     ],
     mentions: [
@@ -2681,6 +3827,44 @@ var sections5 = [
         type: "paragraph",
         text: "For best results, audit your schema for fields that never vary across documents \u2014 these are prime candidates for the **constant** strategy. Fields like currency, data source, or processing batch can be set once and never require AI extraction. This reduces per-document processing cost and improves job completion time, especially on large runs with hundreds of documents."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Configure a generator bypass (deterministic ID)",
+        code: `curl -X PATCH https://api.talonic.com/v1/schemas/us_def456/fields/fld_row_id \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "strategy": "generator",
+    "generator_type": "deterministic-id",
+    "generator_config": {
+      "prefix": "INV"
+    }
+  }'
+
+# Each row will receive a unique, reproducible ID like "INV-a7b3c9d2"
+# based on a hash of the document and entity attributes.`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Configure a reference bypass (lookup from reference table)",
+        code: `curl -X PATCH https://api.talonic.com/v1/schemas/us_def456/fields/fld_vendor_code \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "strategy": "reference",
+    "key_expression": "vendor_name",
+    "reference_table_id": "ref_vendor_codes"
+  }'
+
+# The field value is resolved by looking up the vendor_name field
+# against the vendor_codes reference table \u2014 no LLM call needed.`
+      },
+      {
+        type: "paragraph",
+        text: "Bypass strategies are evaluated in Phase 1 of the pipeline, before any AI calls are made. This means bypass fields are resolved in milliseconds at zero credit cost, and their values are immediately available as context for Phase 2 AI extraction of other fields. For schemas with many static or derivable fields, bypass strategies can reduce the number of fields sent to the LLM by 30-50%, which translates directly to faster job completion and lower per-document cost. Audit your schema periodically for new bypass candidates as your understanding of the data matures."
+      },
       {
         type: "callout",
         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."
@@ -2703,6 +3887,10 @@ var sections5 = [
       {
         question: "Do bypass strategies reduce extraction costs?",
         answer: "Yes. Fields with bypass strategies skip the AI extraction phase entirely, which reduces both processing time and credit usage. Use constant or reference strategies for fields that do not require document reading."
+      },
+      {
+        question: "What is the difference between a reference table on a field and a reference bypass strategy?",
+        answer: "A reference table on a field normalizes AI-extracted values to canonical codes after extraction (Phases 1 and 3). A reference bypass strategy skips AI extraction entirely and resolves the value by looking up another field in a reference table during Phase 1. Use reference tables when the AI needs to read the document first; use reference bypass when the value can be derived from an already-extracted field without reading the document."
       }
     ],
     mentions: [
@@ -2757,6 +3945,52 @@ var sections5 = [
         type: "paragraph",
         text: 'Choose the mismatch behavior based on your data quality requirements. Use **empty** (the default) when you prefer no data over bad data \u2014 the downstream system will see a blank cell. Use **flag** when you want to review mismatches manually before deciding \u2014 flagged cells appear with an amber dot in the results grid. Use **constant** when your downstream system needs a specific sentinel value like `"N/A"` or `"INVALID"` to trigger its own error handling.'
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Add a format constraint to a schema field",
+        code: `curl -X PATCH https://api.talonic.com/v1/schemas/us_def456/fields/fld_po_number \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "constraints": {
+      "format": {
+        "type": "regex",
+        "pattern": "^PO-\\\\d{6}$",
+        "on_format_mismatch": "flag"
+      }
+    }
+  }'
+
+# Values matching PO-123456 pass through unchanged.
+# Values like "PO 123456" or "123456" are flagged with an amber dot.
+# Original values are always preserved in original_extractions for audit.`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Date format constraint with case-insensitive flag",
+        code: `# Validate ISO date format with optional time component:
+curl -X PATCH https://api.talonic.com/v1/schemas/us_def456/fields/fld_date \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "constraints": {
+      "format": {
+        "type": "regex",
+        "pattern": "^\\\\d{4}-\\\\d{2}-\\\\d{2}(T\\\\d{2}:\\\\d{2}:\\\\d{2})?$",
+        "on_format_mismatch": "empty"
+      }
+    }
+  }'
+
+# Values like "2025-03-15" or "2025-03-15T14:30:00" pass.
+# Values like "March 15, 2025" are cleared (on_format_mismatch: "empty").`
+      },
+      {
+        type: "paragraph",
+        text: 'Format constraints are one of the most effective tools for ensuring downstream system compatibility. Many ERP and accounting systems reject records with malformed identifiers, dates outside their expected format, or amounts with unexpected characters. By catching these issues at extraction time with format constraints, you prevent bad data from reaching downstream systems entirely. The three mismatch behaviors give you control over the trade-off: use "empty" when no data is better than bad data, "flag" when you want human review before deciding, and "constant" when your downstream system needs a specific sentinel value to trigger error handling.'
+      },
       {
         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. Format constraints support standard JavaScript regex syntax, so you can use character classes, alternation, and lookahead assertions for complex validation patterns."
@@ -2779,6 +4013,10 @@ var sections5 = [
       {
         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 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."
+      },
+      {
+        question: "What happens if my regex pattern causes performance issues?",
+        answer: "The evaluator includes built-in ReDoS (Regular Expression Denial of Service) protection. Patterns with nested quantifiers like (a+)+ are automatically rejected at save time. Additionally, input values are capped at 1,000 characters, preventing pathological backtracking on unexpectedly long strings. These safeguards run transparently \u2014 you do not need to optimize your patterns manually for performance."
       }
     ],
     mentions: [
@@ -2820,6 +4058,59 @@ var sections6 = [
         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: "code",
+        language: "bash",
+        title: "Create an extraction job via API",
+        code: `curl -X POST https://api.talonic.com/v1/jobs \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "schema_id": "us_def456",
+    "document_ids": ["doc_001", "doc_002", "doc_003"],
+    "extraction_type": "pipeline"
+  }'
+
+# Response:
+# {
+#   "run_id": "run_abc123",
+#   "status": "processing",
+#   "extraction_type": "pipeline",
+#   "document_count": 3,
+#   "current_phase": 1,
+#   "created_at": "2025-04-20T10:00:00Z"
+# }`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Check job status and results",
+        code: `curl -s https://api.talonic.com/v1/jobs/runs/run_abc123 \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "run_id": "run_abc123",
+#   "status": "completed",
+#   "current_phase": 4,
+#   "grid_stats": {
+#     "total_cells": 36,
+#     "filled_cells": 33,
+#     "fill_rate": 0.917,
+#     "strategy_yield": {
+#       "registry_transfer": 0.44,
+#       "llm_extract": 0.33,
+#       "lookup_cascade": 0.11,
+#       "deterministic_compute": 0.06,
+#       "empty": 0.06
+#     }
+#   }
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "The strategy yield breakdown in the job response is a powerful diagnostic tool. It shows exactly how each cell was filled \u2014 registry transfers from Phase 1, LLM extractions from Phase 2, lookup cascade matches from Phase 3, and deterministic computations. A high registry_transfer percentage indicates mature field coverage, while a high llm_extract percentage suggests the registry needs more training data. Track strategy yield across jobs to measure how your pipeline efficiency improves over time as the Field Registry grows."
+      },
       {
         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. The phase timeline on the job detail page shows which phase is active and the cumulative fill rate at each stage."
@@ -2842,6 +4133,10 @@ var sections6 = [
       {
         question: "How many documents can I include in a single job?",
         answer: "Phase 2 supports up to 2,000 documents per job, and Phase 4 supports up to 1,000. For best results, start with smaller batches to validate your schema before scaling up."
+      },
+      {
+        question: "What extraction modes are available?",
+        answer: "Three modes: pipeline (full 4-phase extraction, the default and most thorough), simple (single AI call, faster but less thorough \u2014 used for test extractions), and field_registry (no AI, deterministic strategies only \u2014 useful for benchmarking registry coverage). Choose pipeline for production jobs, simple for quick previews, and field_registry for measuring how much the registry can resolve without AI."
       }
     ],
     mentions: ["extraction job", "structured grid", "progressive results", "template selection"]
@@ -2875,6 +4170,34 @@ var sections6 = [
         title: "Job Detail \u2014 Phase Timeline",
         caption: "The phase timeline shows progress through the pipeline. Each dot represents a stage, highlighted when active."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Monitor pipeline phase progress",
+        code: `# Poll the job detail endpoint to track phase progress:
+curl -s https://api.talonic.com/v1/jobs/runs/run_abc123 \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# During execution:
+# {
+#   "run_id": "run_abc123",
+#   "status": "processing",
+#   "current_phase": 2,
+#   "phase_timings": {
+#     "phase_1": { "started_at": "...", "completed_at": "...", "duration_ms": 1240 },
+#     "phase_2": { "started_at": "...", "completed_at": null }
+#   },
+#   "grid_stats": {
+#     "fill_rate": 0.42,
+#     "filled_cells": 15,
+#     "total_cells": 36
+#   }
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "The phase timings in the job response let you identify bottlenecks in your extraction pipeline. Phase 1 typically completes in seconds regardless of document count because it uses pre-computed indexes. Phase 2 is the most time-consuming because it involves AI calls \u2014 the duration scales linearly with the number of empty cells and document length. Phase 3 adds minimal overhead with deterministic lookups. Phase 4 duration depends on how many cells remain empty after Phase 2. If Phase 2 consistently takes longer than expected, consider improving your Field Registry coverage to shift more work to Phase 1, or use batch inference for non-urgent jobs at 50% cost."
+      },
       {
         type: "callout",
         text: "Phase order is fixed: Phase 1 → 2 → 3 → 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."
@@ -2897,6 +4220,10 @@ var sections6 = [
       {
         question: "Why does the pipeline use multiple phases instead of a single AI call?",
         answer: "The cascading design minimizes cost and latency. Phase 1 fills cells with deterministic lookups at zero AI cost. Only remaining gaps go to the AI agent in Phase 2, and Phase 4 targets specific empty cells with full context. This is significantly cheaper and faster than sending everything to AI."
+      },
+      {
+        question: "How does the confidence gate protect values across phases?",
+        answer: "The confidence gate is enforced on every grid write. Once a cell is filled with a confidence score of 0.7 or higher, no later phase can overwrite it with a lower-confidence value. This prevents high-quality Phase 1 lookup results (0.95 confidence) from being replaced by lower-confidence Phase 2 AI extractions (0.65 confidence). The gate is the single most important pipeline invariant."
       }
     ],
     mentions: ["4-phase pipeline", "fill rate", "progressive rendering", "phase timeline"]
@@ -2959,6 +4286,48 @@ var sections6 = [
         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: "code",
+        language: "bash",
+        title: "Check Field Registry stats to predict Phase 1 coverage",
+        code: `curl -s https://api.talonic.com/v1/fields/stats \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "total_fields": 342,
+#   "tier_1": 89,
+#   "tier_2": 156,
+#   "tier_3": 97,
+#   "total_occurrences": 14280,
+#   "avg_occurrence_count": 41.8
+# }
+
+# Higher tier_1 + tier_2 counts mean more Phase 1 coverage.
+# Tier 1 fields resolve at 0.85+ confidence via direct transfer.`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "View strategy yield after a completed job",
+        code: `curl -s https://api.talonic.com/v1/jobs/runs/run_abc123 \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  | jq '.grid_stats.strategy_yield'
+
+# {
+#   "registry_transfer": 0.44,
+#   "raw_extraction_mapping": 0.08,
+#   "lookup_cascade": 0.11,
+#   "deterministic_compute": 0.06,
+#   "llm_extract": 0.25,
+#   "phase3_lookup": 0.03,
+#   "empty": 0.03
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Understanding Phase 1 resolution strategies helps you optimize your pipeline. Registry transfer is the highest-quality strategy \u2014 it maps extracted field occurrences from the Field Registry directly to schema fields. Raw extraction mapping handles cases where the extracted field name does not exactly match the registry but can be inferred from the document raw extraction data. The lookup cascade (normalization, fuzzy, AI fallback) resolves reference table fields. Deterministic compute handles formula-based fields like totals and differences. By monitoring the strategy yield across jobs, you can identify which strategies are carrying the most weight and where to invest in improving coverage."
+      },
       {
         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."
@@ -2981,6 +4350,10 @@ var sections6 = [
       {
         question: "Does Phase 1 performance improve over time?",
         answer: "Yes. As your Field Registry grows from processing more documents, Phase 1 can resolve a higher percentage of cells through graph matches. Mature registries often see Phase 1 fill rates of 60-80%."
+      },
+      {
+        question: "How can I improve my Phase 1 fill rate?",
+        answer: "Three approaches: process more documents to grow the Field Registry (more Tier 1 and Tier 2 fields mean more direct transfers), add comprehensive reference tables with common value variations (improves lookup cascade hits), and use descriptive field names in your schemas that match the canonical registry names (improves exact match rates). Check the strategy_yield in job results to identify which resolution methods are underperforming."
       }
     ],
     mentions: [
@@ -3047,6 +4420,36 @@ var sections6 = [
         type: "paragraph",
         text: "For fields backed by a **reference table**, Phase 2 includes the table's codes and labels directly in the extraction prompt so the AI picks canonical codes rather than free-text labels. This tight integration between reference tables and AI extraction produces cleaner output that requires fewer corrections. Fields with fewer than 50 reference entries get the full table in the prompt; larger tables are handled by the Phase 3 lookup cascade instead."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "View the agent strategy audit trail for a job",
+        code: `curl -s https://api.talonic.com/v1/jobs/runs/run_abc123/strategy \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "strategies": [
+#     {
+#       "document_id": "doc_001",
+#       "field": "total_amount",
+#       "action": "compute",
+#       "expression": "unit_price * quantity",
+#       "confidence": 0.95
+#     },
+#     {
+#       "document_id": "doc_001",
+#       "field": "payment_terms",
+#       "action": "extract",
+#       "reasoning": "No existing value or computable relationship found"
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Phase 2 uses prompt caching to reduce costs on multi-group extraction calls. For each document, the first group call writes the document content to the Anthropic cache, and subsequent group calls read from it. This primer-then-parallel dispatch pattern reduces per-document costs by 60-80% compared to uncached extraction. The caching is transparent \u2014 you do not need to configure anything. Cache entries persist for 5 minutes on the Anthropic side, so iterating on the same documents within that window benefits from warm cache hits at even lower cost."
+      },
       {
         type: "callout",
         variant: "warning",
@@ -3070,6 +4473,10 @@ var sections6 = [
       {
         question: "How many fields does the agent process per AI call?",
         answer: "Schema fields are grouped into batches of up to 10 fields per extraction call. This balances extraction quality with throughput \u2014 smaller groups help the AI focus on each field without losing recall."
+      },
+      {
+        question: "How does Phase 2 handle reference table fields?",
+        answer: "For fields backed by a reference table with fewer than 50 entries, Phase 2 includes the full table of codes and labels in the AI prompt so the model picks canonical codes rather than free-text labels. Larger tables are handled by the Phase 3 lookup cascade instead, keeping the prompt size bounded and cost predictable."
       }
     ],
     mentions: [
@@ -3139,6 +4546,40 @@ var sections6 = [
         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: "code",
+        language: "bash",
+        title: "Retrieve validation flags for a completed job",
+        code: `curl -s "https://api.talonic.com/v1/jobs/runs/run_abc123?include=validation_flags" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response includes per-document validation flags:
+# {
+#   "results": [
+#     {
+#       "document_id": "doc_001",
+#       "validation_flags": [
+#         {
+#           "type": "date_sanity",
+#           "severity": "error",
+#           "fields": ["contract_start_date", "contract_end_date"],
+#           "message": "End date (2024-01-15) precedes start date (2025-03-01)"
+#         },
+#         {
+#           "type": "low_confidence_outlier",
+#           "severity": "warning",
+#           "fields": ["payment_terms"],
+#           "message": "Confidence 0.28 in row with average 0.82"
+#         }
+#       ]
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: 'Phase 3 is particularly valuable for catching systematic errors before they reach downstream systems. For example, if your schema includes both a "start date" and "end date" field, the date_sanity check catches temporal inversions that would be difficult to spot in a large grid. Similarly, the amount_mismatch check catches arithmetic inconsistencies between related financial fields \u2014 a total that does not align with its components within a 20% tolerance is flagged for review. These cross-field checks operate on relationships between fields rather than individual values, catching errors that single-field validation cannot detect.'
+      },
       {
         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."
@@ -3161,6 +4602,10 @@ var sections6 = [
       {
         question: "Does Phase 3 modify any cell values?",
         answer: "Phase 3 re-runs the reference table lookup cascade to normalize AI-extracted labels to canonical codes. The validation flags themselves are purely informational and do not modify values."
+      },
+      {
+        question: "How does the lookup_failed flag help improve my reference tables?",
+        answer: 'The lookup_failed flag identifies values that the AI extracted but could not map to any code in your reference table. These are direct candidates for adding new entries. Review the flagged values after each job \u2014 if "Frame Agreement" consistently fails lookup against a contract type table, add it as a synonym pointing to the canonical code. Future runs will resolve it at Tier 1 confidence (0.95) without AI fallback.'
       }
     ],
     mentions: [
@@ -3194,6 +4639,26 @@ var sections6 = [
         type: "paragraph",
         text: "Expect Phase 4 to fill 5-15% of remaining empty cells, depending on document complexity and schema coverage. The phase is most effective for fields that require cross-referencing multiple sections of a document or interpreting values in the context of other extracted data. It is less effective for fields that are genuinely absent from the source document \u2014 those will remain empty with an `unresolved` provenance type."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Resume a failed or stuck job",
+        code: `# If a job fails mid-pipeline, resume from the last completed phase:
+curl -X POST https://api.talonic.com/v1/jobs/runs/run_abc123/resume \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "run_id": "run_abc123",
+#   "status": "processing",
+#   "resumed_from_phase": 3,
+#   "message": "Resumed from phase 3 after previous failure"
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Phase 4 is where the modifier pipeline and format constraint evaluation happen. The modifier pipeline runs in a strict order \u2014 format transforms first (converting dates and numbers to your target format), then alias mapping (replacing values using a lookup table), and finally max_length truncation. After all modifiers have been applied, format constraints evaluate the final transformed value against the regex pattern. If the value fails, the configured mismatch behavior kicks in. This ordering is important because it means constraints validate the output your downstream system will actually receive, not the raw AI extraction. Original values are always preserved in the original_extractions table, giving you a complete audit trail from raw extraction through every transformation step."
+      },
       {
         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. Original values are always preserved in the `original_extractions` table for audit, regardless of whether format constraints clear, flag, or replace them."
@@ -3216,6 +4681,10 @@ var sections6 = [
       {
         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 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."
+      },
+      {
+        question: "Can I resume a job that failed during Phase 4?",
+        answer: "Yes. Use the POST /v1/jobs/runs/{id}/resume endpoint. The pipeline detects which phase completed last and resumes from the next phase. Results from completed phases are preserved in the grid \u2014 you never lose work from earlier phases when resuming a failed job."
       }
     ],
     mentions: ["Phase 4", "re-read", "gap filling", "confidence gate", "targeted extraction"]
@@ -3249,6 +4718,42 @@ var sections6 = [
         type: "paragraph",
         text: "For large jobs with hundreds of documents, use a systematic review workflow: first address all **Flagged** rows, then spot-check a random sample of **Clean** rows to build confidence in the overall quality. If you find recurring errors in a specific field, consider updating the schema field's instruction or reference table, then run a new job \u2014 corrections you apply also feed back as training signals for future runs."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "List job results with per-cell provenance",
+        code: `curl -s "https://api.talonic.com/v1/jobs/runs/run_abc123?include=results" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "results": [
+#     {
+#       "document_id": "doc_001",
+#       "document_name": "Invoice_ACME_2025.pdf",
+#       "fields": {
+#         "invoice_number": {
+#           "value": "INV-2025-0042",
+#           "confidence": 0.95,
+#           "resolution_type": "graph_match",
+#           "phase": 1
+#         },
+#         "total_amount": {
+#           "value": "12450.00",
+#           "confidence": 0.88,
+#           "resolution_type": "agent_derived",
+#           "phase": 2,
+#           "reasoning": "Extracted from invoice summary table, row 'Total Due'"
+#         }
+#       }
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "The strategy yield breakdown on the job detail page gives you an at-a-glance view of pipeline efficiency. A high percentage of registry_transfer and deterministic_compute cells means your Field Registry is mature and Phase 1 is doing most of the work at zero AI cost. A high percentage of llm_extract cells suggests opportunities to improve \u2014 add more documents to grow the registry, refine reference tables for better lookup coverage, or add bypass strategies for fields with predictable values. Tracking strategy yield across multiple jobs over time is the best way to measure whether your pipeline is becoming more efficient."
+      },
       {
         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. The clean export omits metadata and includes only the extracted values, ready for direct import into downstream systems."
@@ -3271,6 +4776,10 @@ var sections6 = [
       {
         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. 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."
+      },
+      {
+        question: "How do I delete a job run I no longer need?",
+        answer: "Use DELETE /v1/jobs/runs/{id} to remove a completed run and its results. This frees storage but the deletion is permanent \u2014 the run and its results cannot be recovered. Consider exporting results via CSV before deleting if you need the data for historical reference or compliance."
       }
     ],
     mentions: [
@@ -3346,6 +4855,27 @@ var sections6 = [
         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."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Export results with full provenance metadata",
+        code: `# The full CSV export includes metadata columns for each field:
+# field_name, field_name__confidence, field_name__resolution_type,
+# field_name__phase, field_name__reasoning
+
+curl -s "https://api.talonic.com/v1/jobs/runs/run_abc123?include=results" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Accept: text/csv"
+
+# CSV output:
+# document_name,invoice_number,invoice_number__confidence,invoice_number__resolution_type,...
+# Invoice_ACME.pdf,INV-2025-0042,0.95,graph_match,...
+# Contract_Beta.pdf,CTR-2025-001,0.72,agent_derived,...`
+      },
+      {
+        type: "paragraph",
+        text: 'Provenance metadata enables powerful downstream analytics. By exporting results with full metadata, you can build dashboards that track extraction confidence by field, document type, or time period. For example, if you notice that the "payment_terms" field consistently scores below 0.6 confidence, this is a signal to refine its extraction instruction or add reference table entries. Teams that track provenance metrics across jobs can quantify the ROI of schema improvements \u2014 each instruction refinement or reference table update shows up as a measurable confidence increase in subsequent runs.'
+      },
       {
         type: "callout",
         variant: "warning",
@@ -3369,6 +4899,10 @@ var sections6 = [
       {
         question: "What confidence threshold should I use for manual review?",
         answer: "Cells above 0.8 are generally reliable. Cells between 0.5 and 0.8 warrant a quick check. Cells below 0.5 should always be reviewed manually. Use the CSV export to filter by confidence for efficient batch review."
+      },
+      {
+        question: "How can I use provenance data to improve extraction quality?",
+        answer: "Track confidence scores by field across multiple jobs. Fields that consistently score below 0.6 are candidates for improvement \u2014 refine the extraction instruction, add reference table entries, or provide more example documents. The resolution_type breakdown shows whether the system is relying on registry transfers (ideal) or AI extraction (expensive). Shifting more cells from agent_derived to graph_match reduces cost and improves reliability."
       }
     ],
     mentions: [
@@ -3402,6 +4936,43 @@ var sections6 = [
         type: "paragraph",
         text: "For best results, correct the root cause rather than individual symptoms. If a field consistently produces wrong values, update the schema field's **manual instruction** or **reference table** rather than correcting cells one by one. If a reference table code is missing, add it to the table \u2014 future runs will pick it up automatically at Tier 1 confidence (0.95). Corrections are most valuable as a feedback mechanism when they inform schema improvements."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "View job results with correction audit trail",
+        code: `curl -s "https://api.talonic.com/v1/jobs/runs/run_abc123?include=results,corrections" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response includes correction history per cell:
+# {
+#   "results": [
+#     {
+#       "document_id": "doc_001",
+#       "fields": {
+#         "vendor_name": {
+#           "value": "ACME Corporation",
+#           "confidence": 1.0,
+#           "resolution_type": "manual_correction",
+#           "corrections": [
+#             {
+#               "original_value": "Acme Corp.",
+#               "corrected_value": "ACME Corporation",
+#               "corrected_by": "user@example.com",
+#               "corrected_at": "2025-04-21T14:30:00Z",
+#               "propagation": "all_similar",
+#               "affected_count": 8
+#             }
+#           ]
+#         }
+#       }
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Corrections are most powerful when they inform structural improvements to your schema. If you find yourself correcting the same field repeatedly across multiple jobs, this is a strong signal that the underlying schema configuration needs attention. Common fixes include: adding missing synonyms to a reference table (so Tier 1 lookup resolves the value automatically), refining the manual extraction instruction (so the AI extracts the correct value in the first place), or adjusting a format constraint pattern (so valid values are not incorrectly flagged). Each of these root-cause fixes eliminates the need for future corrections on that field, compounding time savings across every subsequent job."
+      },
       {
         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. For recurring field-level errors, consider updating the schema instruction or reference table rather than correcting cells individually across multiple runs."
@@ -3424,6 +4995,10 @@ var sections6 = [
       {
         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 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."
+      },
+      {
+        question: "What is the difference between this_document_only and all_similar propagation?",
+        answer: "this_document_only corrects a single cell in one document. all_similar finds every cell in the run where the same field was resolved using the same method and source, and applies the same correction to all of them. Use all_similar for systematic errors \u2014 for example, when a reference table consistently maps a vendor name to the wrong code. The system previews the count of affected cells before applying, so you can verify the scope before confirming."
       }
     ],
     mentions: [
@@ -3502,6 +5077,49 @@ var sections7 = [
           "Manual overrides available in the Field Registry"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "List fields with their link key classifications",
+        code: `curl -s "https://api.talonic.com/v1/fields?link_key=true" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "fields": [
+#     {
+#       "id": "fr_vendor",
+#       "canonical_name": "vendor_name",
+#       "link_key_category": "identity",
+#       "tier": 1,
+#       "occurrence_count": 289
+#     },
+#     {
+#       "id": "fr_po",
+#       "canonical_name": "purchase_order_number",
+#       "link_key_category": "transaction",
+#       "tier": 1,
+#       "occurrence_count": 415
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Update a field link key classification",
+        code: `curl -X PATCH https://api.talonic.com/v1/fields/fr_project_code \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{ "link_key_category": "reference" }'
+
+# Manual overrides take precedence over automatic classification
+# and persist across all future linking runs.`
+      },
+      {
+        type: "paragraph",
+        text: "Link key classification is the foundation of the entire linking and case formation system. Getting the classification right is critical for producing meaningful cases. If too many fields are classified as link keys, cases become over-connected with hundreds of documents grouped together. If too few fields are classified, documents that should be related end up as isolated singletons. Review your link key assignments after the first batch of documents to ensure the automatic classifications make sense for your domain, and use manual overrides to correct any misclassifications."
+      },
       {
         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. Manual overrides in the Field Registry take precedence over automatic classifications and persist across future jobs."
@@ -3524,6 +5142,10 @@ var sections7 = [
       {
         question: "Can I manually classify a field as a link key?",
         answer: "Yes. Navigate to the Field Registry and change any field's link key category. Manual classifications take precedence over automatic ones and persist across future jobs."
+      },
+      {
+        question: "How do I check which fields are currently classified as link keys?",
+        answer: "Use GET /v1/fields?link_key=true to list all fields with a link key classification. The response includes the category (identity, transaction, or reference), tier, and occurrence count for each field. You can also view link key classifications in the Field Registry page of the dashboard."
       }
     ],
     mentions: [
@@ -3572,6 +5194,37 @@ var sections7 = [
           "Handles minor naming variations automatically; wildly inconsistent names may need manual tuning"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "List linking results for a document",
+        code: `curl -s "https://api.talonic.com/v1/linking?document_id=doc_001" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "links": [
+#     {
+#       "entity_value": "acme corporation",
+#       "original_value": "ACME Corp.",
+#       "link_key_field": "vendor_name",
+#       "category": "identity",
+#       "connected_documents": ["doc_001", "doc_005", "doc_012"]
+#     },
+#     {
+#       "entity_value": "po-2025-0042",
+#       "original_value": "PO-2025-0042",
+#       "link_key_field": "purchase_order_number",
+#       "category": "transaction",
+#       "connected_documents": ["doc_001", "doc_003"]
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: 'The normalization engine handles a comprehensive set of corporate suffixes across multiple languages: Ltd, Inc, Corp, GmbH, AG, SA, SAS, BV, NV, Pty, and many more. It also collapses multiple whitespace characters, strips leading and trailing punctuation, and lowercases all values before comparison. This means "ACME Corp.", "Acme Corporation", "acme corp", and "ACME CORP" all resolve to the same canonical entity. For edge cases where the automatic normalization is insufficient \u2014 such as when a company uses entirely different trading names \u2014 you can manually link documents through the case management interface.'
+      },
       {
         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. This means your cases stay up-to-date without manual intervention as new documents flow into the workspace."
@@ -3594,6 +5247,10 @@ var sections7 = [
       {
         question: "What normalization does entity linking apply?",
         answer: "Values are lowercased, common suffixes (Ltd, Inc, Corp, etc.) are stripped, and whitespace is normalized. This ensures minor naming variations resolve to the same entity."
+      },
+      {
+        question: "What happens when new documents are added to an existing workspace?",
+        answer: "Entity linking is incremental. New documents extend the existing bipartite graph rather than triggering a rebuild. If a new document shares entity values with existing documents, it is connected to the relevant entity nodes and may be added to existing cases. This happens automatically without manual intervention."
       }
     ],
     mentions: [
@@ -3666,6 +5323,56 @@ var sections7 = [
           "Export Evidence and Timeline to MD, CSV, or JSON"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "List cases with anomaly counts",
+        code: `curl -s "https://api.talonic.com/v1/cases?limit=10" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "cases": [
+#     {
+#       "id": "case_abc",
+#       "label": "ACME Corp Invoice #4521 \u2192 PO #8890",
+#       "document_count": 3,
+#       "anomaly_count": 1,
+#       "lifecycle": "discovered",
+#       "created_at": "2025-04-18T10:00:00Z"
+#     }
+#   ],
+#   "total": 42
+# }`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Get case detail with documents and entities",
+        code: `curl -s https://api.talonic.com/v1/cases/case_abc \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "id": "case_abc",
+#   "label": "ACME Corp Invoice #4521 \u2192 PO #8890",
+#   "documents": [
+#     { "id": "doc_001", "name": "Invoice_4521.pdf", "type": "Invoice" },
+#     { "id": "doc_003", "name": "PO_8890.pdf", "type": "Purchase Order" },
+#     { "id": "doc_005", "name": "Contract_ACME.pdf", "type": "Contract" }
+#   ],
+#   "entities": [
+#     { "value": "acme corporation", "category": "identity", "document_count": 3 },
+#     { "value": "po-2025-8890", "category": "transaction", "document_count": 2 }
+#   ],
+#   "anomaly_count": 1,
+#   "lifecycle": "discovered"
+# }`
+      },
+      {
+        type: "paragraph",
+        text: 'Cases are the primary unit of holistic document review. Rather than reviewing documents in isolation, cases let you see all related documents together \u2014 an invoice alongside its purchase order and contract. The AI-generated case label gives you immediate context: "ACME Corp Invoice #4521 → PO #8890" tells you at a glance what the case is about. The anomaly count badge in the header lets you prioritize cases that need attention, and the lifecycle tracking ensures nothing falls through the cracks as your team processes the queue.'
+      },
       {
         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."
@@ -3690,6 +5397,10 @@ var sections7 = [
       {
         question: "Can I merge or split cases?",
         answer: "Yes. Merge multiple cases into one from the cases list, or split a case into separate groups from the case detail page. You can also pin or remove individual documents and confirm or reject linking edges."
+      },
+      {
+        question: "How do I track case lifecycle status via the API?",
+        answer: "The case lifecycle field is included in both list and detail responses. Cases progress through four stages: discovered (linking engine first identified the cluster), confirmed (reviewer validated the grouping), active (ongoing work), and resolved (all documents reviewed and processed). Filter the case list by lifecycle to focus on cases that need attention."
       }
     ],
     mentions: ["cases", "entity groups", "evidence chain", "AI narration", "document connections", "case label", "merge", "split"]
@@ -3732,6 +5443,31 @@ var sections7 = [
           "Missing document type anomalies raised when a case does not match its template"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Trigger case template discovery via API",
+        code: `curl -X POST https://api.talonic.com/v1/cases/templates/discover \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "templates": [
+#     {
+#       "id": "tpl_001",
+#       "pattern": ["Invoice", "Purchase Order", "Contract"],
+#       "case_count": 12,
+#       "match_threshold": 0.75,
+#       "discovered_at": "2025-04-20T09:00:00Z"
+#     }
+#   ],
+#   "discovered": 1
+# }`
+      },
+      {
+        type: "paragraph",
+        text: 'Case templates serve as completeness monitors. Once a template is established \u2014 for example, "Invoice + Purchase Order + Contract" \u2014 the Missing Document Type anomaly detector (D4) checks every new case against it. If a case matches the template pattern but is missing one of the expected document types, an anomaly is raised. This is particularly valuable in procurement workflows where a complete audit trail requires specific document types to be present. Templates evolve organically as your workspace grows \u2014 the system proposes new templates whenever it detects recurring patterns across 3 or more cases.'
+      },
       {
         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. You can also trigger template discovery manually from the API via POST /cases/templates/discover."
@@ -3753,6 +5489,10 @@ var sections7 = [
       {
         question: "Can I switch between graph and list views?",
         answer: "Yes. Toggle between the visual D3-force graph and a traditional list view from the Cases page. Both views show the same underlying data \u2014 choose whichever suits your workflow."
+      },
+      {
+        question: "How do case templates trigger anomaly detection?",
+        answer: "Once a template is established (e.g., Invoice + Purchase Order + Contract), the Missing Document Type detector (D4) checks every new case against it. If a case matches the template but is missing an expected document type, a D4 anomaly is raised. This helps you catch incomplete transaction bundles before they reach downstream systems."
       }
     ],
     mentions: ["document graph", "D3-force layout", "bipartite graph", "case templates"]
@@ -3825,6 +5565,33 @@ var sections7 = [
           "D5 \u2014 Value Reuse: identical values across unrelated fields, suggesting copy-paste or extraction errors"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "List anomalies for a specific case",
+        code: `curl -s "https://api.talonic.com/v1/cases/case_abc/anomalies" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "anomalies": [
+#     {
+#       "id": "anom_001",
+#       "detector": "D2",
+#       "type": "field_conflict",
+#       "severity": "high",
+#       "fields": ["total_amount"],
+#       "description": "total_amount is 12,450 in Invoice_4521.pdf but 12,500 in PO_8890.pdf",
+#       "dismissed": false,
+#       "detected_at": "2025-04-18T10:05:00Z"
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Anomaly detection is designed for high-throughput triage. In a workspace processing hundreds of cases per week, the anomaly count badges on the cases list page give you an instant heat map of where problems are concentrated. A case with zero anomalies typically needs only a quick spot-check, while a case with multiple D2 (field conflict) or D3 (duplicate key divergence) anomalies warrants detailed investigation. This severity-based prioritization lets your team focus review effort where it has the highest impact, rather than reviewing every case with equal depth."
+      },
       {
         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. Toggle Advanced mode from the sidebar to access the full anomaly workflow."
@@ -3847,6 +5614,10 @@ var sections7 = [
       {
         question: "Can I dismiss anomalies?",
         answer: "Yes. Each anomaly card includes a dismiss button. Dismissed anomalies are hidden by default but can be revealed using the show dismissed toggle on the Anomalies tab."
+      },
+      {
+        question: "What is the difference between anomaly detection and validation checks?",
+        answer: "Validation checks (Phase 3) operate on individual documents \u2014 they flag issues within a single record like date inconsistencies or format mismatches. Anomaly detection operates at the case level \u2014 it compares values across multiple documents within a case to find conflicts, divergences, and missing patterns. Both are complementary: validation catches per-document issues while anomaly detection catches cross-document issues."
       }
     ],
     mentions: ["anomaly detection", "validation cluster", "field conflict", "duplicate key divergence", "value reuse"]
@@ -3904,6 +5675,40 @@ var sections7 = [
           "Domain packs: industry-specific rules (e.g., freight: DOT numbers, MC numbers)"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "View evidence validation results for a case",
+        code: `curl -s "https://api.talonic.com/v1/cases/case_abc/evidence" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "evidence": [
+#     {
+#       "document_id": "doc_001",
+#       "field_key": "credit_card_number",
+#       "validator": "S7",
+#       "algorithm": "luhn",
+#       "status": "fail",
+#       "message": "Luhn checksum failed for value 4111-1111-1111-1112",
+#       "severity": "error"
+#     },
+#     {
+#       "document_id": "doc_001",
+#       "field_key": "total_amount",
+#       "validator": "S5",
+#       "status": "fail",
+#       "message": "Alphabetic characters found in numeric field: '$12,450.00'",
+#       "severity": "warning"
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "The evidence validation engine is extensible through domain packs, which add industry-specific rules without modifying the core validators. Each domain pack is a self-contained module that registers its validators during application startup. The freight domain pack, for example, validates DOT numbers against state-issued format rules and verifies MC (Motor Carrier) numbers. Additional packs for financial services, healthcare, and legal domains can be added by creating a new module in the domain-packs directory with validator implementations that follow the standard interface. This plug-in architecture means the validation engine grows with your industry needs without accumulating complexity in the core rule set."
+      },
       {
         type: "callout",
         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."
@@ -3926,6 +5731,10 @@ var sections7 = [
       {
         question: "How are evidence validation results displayed?",
         answer: "Results appear as colored badges in the Evidence tab of the case detail page. Green indicates pass, red indicates fail, and amber indicates a warning. Use the filter bar to narrow results by status, document, or category."
+      },
+      {
+        question: "Can I re-run evidence validation without re-extracting documents?",
+        answer: "Yes. Evidence validation results are stored separately from extraction data, keyed by (document_id, entity_id, field_key). You can re-run validation independently at any time \u2014 for example, after adding a new domain pack or updating validator rules. The results replace the previous validation run without affecting extracted values or linking data."
       }
     ],
     mentions: ["evidence validation", "structural validators", "checksum", "Luhn", "IBAN", "domain packs", "freight"]
@@ -3976,6 +5785,32 @@ var sections8 = [
           "One template per downstream consumer is the recommended pattern"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "List data products and their statuses",
+        code: `curl -s https://api.talonic.com/v1/data-products \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "data_products": [
+#     {
+#       "id": "dp_001",
+#       "name": "Q1 2025 Invoice Extract",
+#       "schema_name": "Invoice Extraction",
+#       "document_count": 245,
+#       "status": "completed",
+#       "created_at": "2025-04-01T08:00:00Z"
+#     }
+#   ],
+#   "total": 8
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Dataset templates are the bridge between schemas and production-ready data products. While a schema defines what fields to extract, a template defines how those fields appear in the final output \u2014 column order, renamed headers, excluded fields, and default transforms. This separation means you can create multiple templates from the same schema for different downstream consumers. For example, your finance team might need all 20 invoice fields in EUR format, while your operations team needs only 8 fields in USD format. Two templates, one schema, consistent extraction."
+      },
       {
         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. Version your templates alongside schema changes to maintain backward compatibility with existing integrations and downstream consumers."
@@ -3998,6 +5833,10 @@ var sections8 = [
       {
         question: "Can I version dataset templates?",
         answer: "Yes. Each template is versioned independently from the schema it references. This lets you evolve your output format over time without affecting existing data products built from earlier versions."
+      },
+      {
+        question: "Can I create multiple templates from the same schema?",
+        answer: "Yes. This is the recommended pattern for serving different downstream consumers. Each template can include a different subset of schema fields, apply different column mappings and transforms, and be versioned independently. The underlying extraction is identical \u2014 only the output shape differs."
       }
     ],
     mentions: [
@@ -4046,6 +5885,23 @@ var sections8 = [
           "Export the assembled dataset as CSV with leading zero preservation"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Export an assembled dataset as CSV",
+        code: `# Download the assembled dataset with leading zero preservation:
+curl -s "https://api.talonic.com/v1/data-products/dp_001/export?format=csv" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -o "q1_invoices.csv"
+
+# CSV values are never coerced to numbers \u2014 leading zeros
+# on codes like ZIP codes and account numbers are preserved.
+# Fields like "00123" remain "00123", not 123.`
+      },
+      {
+        type: "paragraph",
+        text: "Assemblies support incremental workflows that align with real-world business cadences. A common pattern is to create a weekly assembly that pulls all newly arrived documents from connected sources, applies the template transforms, and produces a fresh output. Because previous assembly versions are retained, you can compare this week's output against last week's to identify changes \u2014 new records added, values updated, or documents removed. This diff capability is particularly valuable for reconciliation workflows where you need to track what changed between reporting periods."
+      },
       {
         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. If your workflow requires repeatable, auditable deliverables, assemblies eliminate the need for manual export configuration on every run."
@@ -4068,6 +5924,10 @@ var sections8 = [
       {
         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. 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."
+      },
+      {
+        question: "How do I regenerate an assembly with updated documents?",
+        answer: "Navigate to the assembly detail page and click Regenerate, or trigger it via the API. The system re-applies the template, pulls the updated document set from all configured sources, and produces a fresh output. The previous assembly version is retained for comparison. No reconfiguration of columns or transforms is needed \u2014 the template handles everything."
       }
     ],
     mentions: [
@@ -4137,6 +5997,32 @@ var sections8 = [
         type: "paragraph",
         text: 'For best results, choose source fields with high uniqueness \u2014 contract numbers or invoice IDs work well, while generic fields like "status" do not. When your documents contain multiple candidate identifiers, configure a fallback chain so the dispenser always has a value to work with. Most teams use the primary reference number as the source field and the document name as the first fallback.'
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Configure ID dispenser rules for a data product",
+        code: `curl -X POST "https://api.talonic.com/v1/data-products/dp_001/id-rules" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "source_field": "invoice_number",
+    "prefix": "INV",
+    "fallback_chain": ["document_name", "upload_date"],
+    "resolution_map": {
+      "ACME Corp": "ACME",
+      "ACME Corporation": "ACME",
+      "Acme": "ACME"
+    }
+  }'
+
+# Then apply:
+# POST /v1/data-products/dp_001/generate-ids
+# Each row receives an ID like "INV-INV2025042" based on the source field.`
+      },
+      {
+        type: "paragraph",
+        text: "ID dispensers solve a common challenge in document processing: generating stable, meaningful identifiers for output rows that can be used as primary keys in downstream databases. Unlike random UUIDs, dispenser-generated IDs are derived from your actual data \u2014 an invoice number, contract reference, or vendor name \u2014 making them human-readable and traceable. The deterministic nature of the generation means the same document always receives the same ID regardless of when or how many times you regenerate, which is critical for maintaining referential integrity with downstream systems that store these IDs as foreign keys."
+      },
       {
         type: "callout",
         text: "ID generation is deterministic \u2014 running **Regenerate IDs** with the same rules and data always produces the same output. This makes ID dispensers safe to re-run without breaking downstream references."
@@ -4159,6 +6045,10 @@ var sections8 = [
       {
         question: "Can I regenerate IDs without losing data?",
         answer: "Yes. Regenerating IDs only updates the ID column \u2014 all other data product values remain unchanged. The operation is deterministic, so the same rules and data always produce the same IDs."
+      },
+      {
+        question: "What makes a good source field for ID generation?",
+        answer: "Choose fields with high cardinality \u2014 values that are unique or nearly unique per document. Invoice numbers, contract references, and purchase order IDs work well. Avoid generic fields like status or document type, which produce collisions. Configure a fallback chain with 1-2 alternative fields so the dispenser always has a value to work with."
       }
     ],
     mentions: ["ID dispenser", "unique identifiers", "fallback chain", "resolution map"]
@@ -4217,6 +6107,27 @@ var sections8 = [
           "Share tokens are revocable and scoped to a single data product"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Generate a share token for a data product",
+        code: `curl -X POST "https://api.talonic.com/v1/data-products/dp_001/share" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "share_token": "stk_a7b3c9d2e4f6",
+#   "public_url": "https://app.talonic.com/share/stk_a7b3c9d2e4f6",
+#   "created_at": "2025-04-22T10:00:00Z"
+# }
+
+# Revoke access at any time:
+# DELETE /v1/data-products/dp_001/share/stk_a7b3c9d2e4f6`
+      },
+      {
+        type: "paragraph",
+        text: "The delivery website behind each share token provides a complete, self-contained view of the data product without requiring Talonic authentication. Recipients can switch between the three views \u2014 Structured Data (raw extraction), Resolved (post-normalization), and Data Product (final assembled output) \u2014 to inspect the data at different pipeline stages. The per-run selector lets viewers compare outputs across pipeline runs or time periods, which is particularly useful for auditors who need to verify how the data changed between reporting cycles. CSV downloads from the delivery website preserve exact cell values including leading zeros, ensuring recipients can import the data into Excel or database tools without data loss."
+      },
       {
         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."
@@ -4240,6 +6151,10 @@ var sections8 = [
       {
         question: "What is auto-resolve singles?",
         answer: "Auto-resolve singles automatically accepts fields that have only one candidate value, removing them from the manual review queue. Combined with auto-review, this significantly reduces the volume of items requiring human attention."
+      },
+      {
+        question: "How do I revoke a share token?",
+        answer: "Delete the share token from the data product detail page or via DELETE /v1/data-products/{id}/share/{token}. The public URL stops working immediately. The data product itself is unaffected \u2014 only the public access link is removed. You can generate a new share token at any time if you need to re-share."
       }
     ],
     mentions: ["share token", "delivery website", "CSV export", "auto-review", "auto-resolve"]
@@ -4290,6 +6205,49 @@ var sections9 = [
           "Non-blocking: validation failures flag records for review but do not prevent extraction"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Run a quality benchmark against golden samples",
+        code: `curl -X POST https://api.talonic.com/v1/quality/benchmark \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "schema_id": "us_def456",
+    "dataset_ids": ["gs_001", "gs_002", "gs_003"]
+  }'
+
+# Response:
+# {
+#   "benchmark_id": "bench_abc",
+#   "status": "processing",
+#   "sample_count": 3,
+#   "created_at": "2025-04-22T14:00:00Z"
+# }`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Get benchmark results with per-field accuracy",
+        code: `curl -s https://api.talonic.com/v1/quality/benchmark/bench_abc \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "benchmark_id": "bench_abc",
+#   "status": "completed",
+#   "overall_accuracy": 0.91,
+#   "field_scores": {
+#     "invoice_number": { "accuracy": 1.0, "verdict": "pass" },
+#     "total_amount": { "accuracy": 0.95, "verdict": "pass" },
+#     "payment_terms": { "accuracy": 0.67, "verdict": "fail" }
+#   }
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Validation checks form the first line of defense in your data quality strategy. They catch issues during extraction before data reaches downstream systems. The key to effective validation is starting simple and expanding incrementally. Begin with field format checks for your most critical identifiers \u2014 invoice numbers, dates, and monetary amounts \u2014 where format violations have the highest business impact. Then add cross-field consistency rules as you learn your data patterns. AI-proposed coherence rules can accelerate this process by analyzing patterns in completed job results and suggesting candidate rules that you review before activation."
+      },
       {
         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. Start with a few high-confidence rules and expand as you learn your data patterns."
@@ -4312,6 +6270,10 @@ var sections9 = [
       {
         question: "Do validation failures block extraction?",
         answer: "No. Validation checks flag records for review but do not prevent extraction from completing. Failed records appear in the Approval Queue for manual inspection."
+      },
+      {
+        question: "How do I measure extraction quality over time?",
+        answer: "Create golden samples (5-10 per schema) and run benchmarks after schema changes or model upgrades. The benchmark compares extraction results field-by-field against your known-correct values, producing per-field accuracy scores with AI judge verdicts. Track these scores over time to measure the impact of schema improvements, instruction refinements, and reference table updates."
       }
     ],
     mentions: [
@@ -4360,6 +6322,31 @@ var sections9 = [
           "Benchmark results are stored historically for tracking quality trends over time"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "List ground truth datasets",
+        code: `curl -s https://api.talonic.com/v1/quality/datasets \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "datasets": [
+#     {
+#       "id": "gs_001",
+#       "document_name": "Invoice_ACME_sample.pdf",
+#       "schema_id": "us_def456",
+#       "field_count": 14,
+#       "created_at": "2025-03-15T09:00:00Z"
+#     }
+#   ],
+#   "total": 8
+# }`
+      },
+      {
+        type: "paragraph",
+        text: 'Golden samples are most valuable when they represent the diversity of your document corpus. Include at least one "clean" document with all fields present and correctly formatted, one document with unusual formatting or missing fields, and one document from each major variation you encounter. This coverage ensures that benchmarks test the full range of extraction challenges rather than just the easy cases. Re-run benchmarks after every significant schema change \u2014 new field instructions, updated reference tables, or model upgrades \u2014 to measure whether the change improved or regressed extraction quality.'
+      },
       {
         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. This separation ensures that ground truth data remains a pure measurement tool without introducing bias into the extraction pipeline."
@@ -4382,6 +6369,10 @@ var sections9 = [
       {
         question: "How many golden samples should I create?",
         answer: "Most teams maintain 5-10 golden samples per schema, covering a representative mix of document types and complexity levels. Re-run benchmarks after schema changes or model upgrades to track quality trends."
+      },
+      {
+        question: "Does the AI judge handle semantic equivalence in benchmark scoring?",
+        answer: 'Yes. The AI judge accounts for semantic equivalence when comparing extracted values against golden sample ground truth. For example, "United States" and "US" may be scored as a match depending on the field type and context. This prevents false negatives where the extraction is correct but uses a different surface form than the golden sample.'
       }
     ],
     mentions: ["golden samples", "ground truth", "benchmark runs", "accuracy scoring", "AI judge"]
@@ -4425,6 +6416,40 @@ var sections9 = [
           "Start conservative (high thresholds) and loosen as pipeline trust builds"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Create a delivery binding for auto-approved results",
+        code: `# Step 1: Create a webhook destination
+curl -X POST https://api.talonic.com/v1/delivery/destinations \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "ERP Import Webhook",
+    "type": "webhook",
+    "config": { "url": "https://erp.example.com/api/import" },
+    "signing_secret": "whsec_your_secret_here"
+  }'
+
+# Step 2: Bind the result.approved signal to it
+curl -X POST https://api.talonic.com/v1/delivery/bindings \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "Ship approved invoices to ERP",
+    "signal_filter": { "event_type": "result.approved" },
+    "deliverable_type": "record.approved",
+    "destination_id": "<destination_id>",
+    "serializer_format": "json"
+  }'
+
+# Now, when approval gates auto-approve a result, the approved
+# record is delivered to your ERP automatically \u2014 zero manual steps.`
+      },
+      {
+        type: "paragraph",
+        text: "The combination of approval gates and delivery bindings creates a fully automated pipeline from document upload to downstream system import. High-confidence results that clear all three gates (confidence, validation pass rate, and field coverage) are auto-approved and delivered immediately. Lower-confidence results are routed to the Approval Queue for human review, and once a reviewer approves them, the same delivery binding fires. This two-track approach ensures that your fastest-moving data flows through without delay while borderline cases still get human oversight before reaching production systems."
+      },
       {
         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. 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."
@@ -4447,6 +6472,10 @@ var sections9 = [
       {
         question: "What thresholds should I start with?",
         answer: "Most teams start with 90% confidence, 95% validation pass rate, and 80% field coverage. Adjust based on the volume of false positives in the approval queue \u2014 loosen thresholds as you gain trust in your pipeline."
+      },
+      {
+        question: "Can I have different approval gates for different schemas?",
+        answer: "Yes. Approval gates are configured per schema, so you can set strict thresholds for high-stakes document types (e.g., financial statements) and looser thresholds for lower-risk types (e.g., internal memos). Each schema operates its own independent gate with its own confidence, pass rate, and coverage criteria."
       }
     ],
     mentions: [
@@ -4501,6 +6530,49 @@ var sections9 = [
           "result.approved and result.rejected signals emitted for delivery pipeline integration"
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "List pending items in the Approval Queue via API",
+        code: `curl -s "https://api.talonic.com/v1/review?status=pending&limit=10" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "items": [
+#     {
+#       "id": "rev_001",
+#       "document_name": "Invoice_Beta_Corp.pdf",
+#       "schema_name": "Invoice Extraction",
+#       "confidence": 0.78,
+#       "validation_pass_rate": 0.90,
+#       "field_coverage": 0.85,
+#       "flags": ["low_confidence_outlier"],
+#       "status": "pending"
+#     }
+#   ],
+#   "total": 24
+# }`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Approve or reject a review item",
+        code: `# Approve a single item:
+curl -X POST https://api.talonic.com/v1/review/rev_001/approve \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Reject a single item:
+curl -X POST https://api.talonic.com/v1/review/rev_001/reject \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Each action emits the corresponding delivery signal
+# (result.approved or result.rejected) immediately.`
+      },
+      {
+        type: "paragraph",
+        text: "The Approval Queue is the human checkpoint in your data pipeline. It ensures that results below your confidence thresholds receive manual review before reaching downstream systems. For teams processing large volumes, the LLM auto-review feature can dramatically reduce review time \u2014 AI proposes approve or reject decisions based on the extraction context, and reviewers accept or override with a single click. Auto-review is especially effective for straightforward items that just missed the auto-approval threshold, letting reviewers focus their attention on the genuinely ambiguous cases that benefit most from human judgment."
+      },
       {
         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. 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."
@@ -4523,6 +6595,10 @@ var sections9 = [
       {
         question: "Can I batch approve or reject items?",
         answer: "Yes. Select multiple items in the queue and use the batch action buttons to approve or reject them all at once. Each item emits the appropriate delivery signal individually."
+      },
+      {
+        question: "What happens after I approve or reject an item?",
+        answer: "Approving emits a result.approved signal to the delivery pipeline. Rejecting emits a result.rejected signal. If you have delivery bindings configured for these signals, the corresponding payload is delivered to your destination immediately. Both signals are emitted individually even during batch operations, ensuring each item triggers its own downstream workflow."
       }
     ],
     mentions: [
@@ -4596,6 +6672,43 @@ var sections10 = [
         type: "paragraph",
         text: "For best results, start with a webhook destination to verify your binding configuration end-to-end. Once the payload shape and delivery cadence match your expectations, expand to file-based destinations (S3, SFTP) or spreadsheet destinations (Google Sheets). Most teams create separate bindings for different downstream consumers rather than routing all events to a single destination."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Create a webhook destination and binding end-to-end",
+        code: `# 1) Create the destination
+curl -X POST https://api.talonic.com/v1/delivery/destinations \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "Ops Webhook",
+    "type": "webhook",
+    "config": { "url": "https://ops.example.com/talonic", "method": "POST" },
+    "signing_secret": "whsec_rotate_monthly"
+  }'
+# -> { "id": "dest_001", "is_active": true }
+
+# 2) Create a binding
+curl -X POST https://api.talonic.com/v1/delivery/bindings \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "Notify on extraction",
+    "signal_filter": { "event_type": "document.extracted" },
+    "deliverable_type": "notification",
+    "destination_id": "dest_001",
+    "serializer_format": "json"
+  }'
+
+# 3) Test the destination
+curl -X POST https://api.talonic.com/v1/delivery/destinations/dest_001/test \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+# -> { "success": true, "duration_ms": 142 }`
+      },
+      {
+        type: "paragraph",
+        text: "The delivery pipeline is designed for zero-code configuration. Adding a new destination, creating a binding, and testing the connection can all be done via the API or dashboard without writing any integration code. The compatibility triangle validation ensures that your binding configuration is valid before any events are routed \u2014 you never end up with a misconfigured binding that silently drops deliveries. Every attempt is logged with full request/response details, and terminal failures are captured in the dead-letter queue for replay, giving you complete visibility into your delivery pipeline."
+      },
       {
         type: "callout",
         text: "Delivery is at-least-once with deterministic idempotency keys. Receivers should use the `X-Talonic-Idempotency-Key` header (or equivalent metadata for file-based connectors) to deduplicate on their end."
@@ -4618,6 +6731,10 @@ var sections10 = [
       {
         question: "What serialization formats are supported?",
         answer: "Ten formats: json, ndjson, csv, csv_file, xlsx, rows, graph, raw, md, and txt. Each serializer declares which deliverable shapes it supports, and the compatibility triangle validates the combination at binding creation time."
+      },
+      {
+        question: "What is the default retry ladder for failed deliveries?",
+        answer: "The default retry ladder uses 7 attempts over approximately 10 hours with exponential backoff: 0s (immediate), 30s, 2min, 8min, 30min, 2h, 8h. After all attempts are exhausted, the delivery moves to the dead-letter queue. You can override the retry schedule per binding via the delivery_policy field."
       }
     ],
     mentions: [
@@ -4693,6 +6810,37 @@ var sections10 = [
         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."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Create an S3 destination with test",
+        code: `curl -X POST https://api.talonic.com/v1/delivery/destinations \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "Data Lake S3",
+    "type": "s3",
+    "config": {
+      "bucket": "talonic-exports",
+      "region": "us-east-1",
+      "prefix": "extractions/{date}/"
+    },
+    "auth_config": {
+      "type": "access_key",
+      "access_key_id": "AKIA...",
+      "secret_access_key": "..."
+    }
+  }'
+
+# Test the connection (HeadBucket probe, no objects written):
+curl -X POST https://api.talonic.com/v1/delivery/destinations/dest_s3/test \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+# -> { "success": true, "message": "bucket 'talonic-exports' reachable" }`
+      },
+      {
+        type: "paragraph",
+        text: "File-based destinations (S3, SFTP, Google Drive, OneDrive, Azure Blob) support configurable filename templates with token substitution. Available tokens include {binding_id}, {event_id}, {customer_id}, {idempotency_key}, {attempt}, {timestamp_iso}, {date}, and {deliverable_type}. For example, a template like `extractions/{date}/{deliverable_type}_{event_id}.json` produces filenames like `extractions/2025-04-22/notification_12345.json`. Path traversal tokens (`..`) are automatically stripped for security. The idempotency key is embedded in the filename for SFTP and OneDrive destinations since these protocols do not support object metadata."
+      },
       {
         type: "callout",
         text: "Destinations can be disabled without deleting them. Set **is_active** to false and no bindings will route events to the destination until you re-enable it."
@@ -4715,6 +6863,10 @@ var sections10 = [
       {
         question: "Can one destination serve multiple bindings?",
         answer: "Yes. A single destination can back any number of bindings, each with its own signal filter, serializer, and field map. This lets you route different event types to the same endpoint with different payload shapes."
+      },
+      {
+        question: "How do OAuth-based destinations (Google Drive, Sheets) handle authentication?",
+        answer: "OAuth destinations require connecting your account through the OAuth flow in the dashboard. Tokens are encrypted at rest using AES-256-GCM and refreshed automatically before expiry. The connector is stateless \u2014 token lifecycle is managed by a shared refresh service so you never need to re-authenticate unless the token is revoked."
       }
     ],
     mentions: [
@@ -4754,6 +6906,34 @@ var sections10 = [
         type: "paragraph",
         text: "For best results, create one binding per downstream consumer per event type. This gives you independent control over payload shape, retry policy, and serialization format for each integration point. Most teams start with a `document.extracted` binding to a webhook and expand to run-level and approval signals as their pipeline matures."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Create a binding with field_map and custom retry policy",
+        code: `curl -X POST https://api.talonic.com/v1/delivery/bindings \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "Approved records to S3 as CSV",
+    "signal_filter": { "event_type": "result.approved" },
+    "deliverable_type": "record.approved",
+    "destination_id": "dest_s3",
+    "serializer_format": "csv_file",
+    "field_map": {
+      "rename": { "invoice_number": "inv_no", "total_amount": "amount" },
+      "drop": ["internal_notes", "debug_trace"],
+      "static": { "source": "talonic", "pipeline": "production" }
+    },
+    "delivery_policy": {
+      "max_attempts": 5,
+      "backoff_schedule": [0, 10000, 60000, 300000, 1800000]
+    }
+  }'`
+      },
+      {
+        type: "paragraph",
+        text: "The field_map feature eliminates the need for middleware transformation layers between Talonic and your downstream systems. The three operations \u2014 drop, rename, and static injection \u2014 compose in a fixed order: excluded fields are removed first, then remaining fields are renamed to match your downstream schema, then static values are injected. This means you can reshape the payload to match exactly what your ERP, data warehouse, or analytics system expects without writing any code or deploying a transformation service. Most teams create one binding per downstream consumer per event type for independent control over payload shape."
+      },
       {
         type: "callout",
         text: "The binding editor in the dashboard walks you through the compatibility triangle step by step \u2014 only showing serializers and deliverables that are compatible with your chosen signal and destination."
@@ -4776,6 +6956,10 @@ var sections10 = [
       {
         question: "What is the compatibility triangle?",
         answer: "The compatibility triangle validates that the signal, deliverable resolver, serializer, and connector all form a compatible combination. The backend enforces this on every binding create and update to prevent misconfigured delivery routes."
+      },
+      {
+        question: "How do I update a binding without disrupting active deliveries?",
+        answer: "Use PUT /v1/delivery/bindings/{id} to update a binding. The backend re-runs the compatibility triangle validation on every update. Changes take effect on the next event \u2014 in-flight deliveries using the previous configuration complete normally. If you need to pause a binding temporarily, disable its destination instead."
       }
     ],
     mentions: [
@@ -4871,6 +7055,39 @@ var sections10 = [
         type: "paragraph",
         text: "For best results, use the catalog API to populate dropdown menus and configuration forms rather than hardcoding signal or deliverable lists. The catalog always reflects the running registry contents, so new signal types and deliverables appear automatically as the platform evolves."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Query the delivery catalog API",
+        code: `# List all available signal types:
+curl -s https://api.talonic.com/v1/delivery/catalog/signals \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "types": ["document.extracted", "document.extraction_failed",
+#     "run.dataspace.completed", "run.structuring.completed",
+#     "run.resolution.completed", "run.extraction.completed",
+#     "result.approved", "result.rejected", "result.flagged",
+#     "delivery.item.completed", "delivery.item.failed"],
+#   "items": [
+#     {
+#       "type": "document.extracted",
+#       "label": "Document extracted",
+#       "description": "Fired when a document completes extraction"
+#     }
+#   ]
+# }
+
+# List compatible deliverables, serializers, and connectors:
+# GET /v1/delivery/catalog/deliverables
+# GET /v1/delivery/catalog/serializers
+# GET /v1/delivery/catalog/connectors`
+      },
+      {
+        type: "paragraph",
+        text: "The catalog API is designed for dynamic UI integration. Rather than hardcoding signal types or deliverable options in your application, query the catalog endpoints to populate dropdowns and configuration forms. This ensures your integration stays current as the platform evolves \u2014 new signal types, deliverable resolvers, and serializers appear automatically in the catalog when they are registered. The catalog also powers the compatibility triangle in the binding editor, filtering options at each step to show only compatible choices."
+      },
       {
         type: "callout",
         text: "The catalog API exposes four endpoints: `/v1/delivery/catalog/signals`, `/v1/delivery/catalog/deliverables`, `/v1/delivery/catalog/serializers`, and `/v1/delivery/catalog/connectors`. Each returns the full registry for that category."
@@ -4893,6 +7110,10 @@ var sections10 = [
       {
         question: "What are meta-signals?",
         answer: "Meta-signals (delivery.item.completed and delivery.item.failed) fire when a delivery attempt itself succeeds or fails. Use them for self-monitoring \u2014 for example, binding delivery.item.failed to a notification webhook for delivery failure alerts."
+      },
+      {
+        question: "How do I set up delivery failure alerts?",
+        answer: "Create a binding with signal_filter event_type set to delivery.item.failed, deliverable_type set to notification, and point it at a webhook destination connected to your alerting system (Slack, PagerDuty, etc.). The built-in loop prevention ensures that a failed alert delivery does not emit another failure signal, so you never get cascading meta-signal loops."
       }
     ],
     mentions: [
@@ -4926,6 +7147,41 @@ var sections10 = [
         type: "paragraph",
         text: "For best results, monitor the DLQ regularly and set up a `delivery.item.failed` meta-signal binding to receive alerts when deliveries fail terminally. Most teams configure a notification webhook for this signal so they are notified immediately rather than discovering failures during a manual review. Request and response bodies older than the configured retention period are automatically cleaned up, but row metadata (status, error code, duration) is retained indefinitely."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Inspect delivery history and replay from DLQ",
+        code: `# List delivery attempts for a binding:
+curl -s "https://api.talonic.com/v1/delivery/items?binding_id=bind_001&limit=5" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "items": [
+#     {
+#       "id": "item_abc",
+#       "status": "succeeded",
+#       "attempt": 1,
+#       "http_status": 200,
+#       "duration_ms": 142,
+#       "completed_at": "2025-04-22T10:05:00Z"
+#     }
+#   ]
+# }
+
+# Check the DLQ for terminal failures:
+curl -s "https://api.talonic.com/v1/delivery/dlq?binding_id=bind_001" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Replay a dead-letter entry (new attempt=1, same idempotency key):
+curl -X POST https://api.talonic.com/v1/delivery/dlq/dlq_xyz/replay \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+# -> { "replayed": true }`
+      },
+      {
+        type: "paragraph",
+        text: "The delivery history and DLQ together provide complete observability into your outbound data flow. Every attempt is logged with precise timing, HTTP status, error classification, and truncated request/response bodies for debugging. When a delivery fails terminally, the DLQ captures the full context \u2014 which event triggered it, which binding matched, what error occurred, and how many attempts were made. Replay is safe to run multiple times because the idempotency key is deterministic: receivers that deduplicate on the X-Talonic-Idempotency-Key header will not process the same delivery twice, even after multiple replays. Destinations that return authentication errors (401, 403) are automatically disabled to prevent a cascade of failed attempts from consuming your retry budget."
+      },
       {
         type: "callout",
         text: "Replay is safe to run multiple times. The idempotency key is deterministic \u2014 receivers that deduplicate on the key will not process the same delivery twice, even after multiple replays."
@@ -4948,6 +7204,10 @@ var sections10 = [
       {
         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) 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."
+      },
+      {
+        question: "What happens when a destination returns a 401 or 403 error?",
+        answer: "Authentication failures (401, 403) are classified as permanent errors. The delivery moves to the DLQ immediately without retrying, and the destination is automatically disabled (is_active set to false) to prevent further failed attempts. Fix the credentials, re-enable the destination, and replay the DLQ entry to resume deliveries."
       }
     ],
     mentions: [
@@ -4998,6 +7258,38 @@ var sections11 = [
           "**Encoding** \u2014 set the character encoding for file exports (UTF-8, ISO-8859-1, etc.)."
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Manage shared dialects via API",
+        code: `# List workspace dialects:
+curl -s https://api.talonic.com/v1/dialects \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Create a shared dialect:
+curl -X POST https://api.talonic.com/v1/dialects \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "US Standard",
+    "date_format": "MM/DD/YYYY",
+    "number_locale": "en-US",
+    "delimiter": ",",
+    "null_representation": "",
+    "boolean_format": "true/false",
+    "encoding": "UTF-8"
+  }'
+
+# Update an existing dialect:
+curl -X PUT https://api.talonic.com/v1/dialects/dial_us_002 \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{ "encoding": "UTF-8-BOM" }'`
+      },
+      {
+        type: "paragraph",
+        text: "Shared dialects are a workspace-level configuration that eliminates formatting inconsistencies across your output. Without them, each schema might use slightly different date formats or number locales, creating data quality issues when records from different schemas are combined in downstream systems. By configuring the dialect once at the workspace level, every schema inherits the same formatting rules automatically. This is particularly important for organizations with multiple teams creating schemas independently \u2014 the shared dialect ensures they all produce structurally consistent output regardless of who created the schema or when."
+      },
       {
         type: "callout",
         variant: "info",
@@ -5025,6 +7317,10 @@ var sections11 = [
       {
         question: "Do shared dialects affect the extraction process?",
         answer: "No. Dialects only affect output formatting \u2014 how extracted values are serialized in exports and deliveries. The extraction and validation phases work with normalized internal representations regardless of dialect settings."
+      },
+      {
+        question: "How do I manage shared dialects across multiple workspaces?",
+        answer: "Use the dialect API (GET, POST, PUT, DELETE on /v1/dialects) to export a dialect configuration from one workspace and replicate it in another. This ensures consistent formatting across your entire organization. If different regions need different formats, create separate workspaces with region-specific shared dialects rather than managing inline overrides on individual schemas."
       }
     ],
     mentions: [
@@ -5060,11 +7356,43 @@ var sections11 = [
         type: "paragraph",
         text: "For best results, keep reference primitives focused on a single domain \u2014 for example, one primitive for country codes, another for currency codes, and another for product categories. This makes each primitive reusable across multiple schemas and simplifies maintenance. When updating a primitive, test the new version against a few sample documents before updating the version reference in production schemas."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Create and version a reference primitive",
+        code: `# Create a reference primitive:
+curl -X POST https://api.talonic.com/v1/reference-primitives \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "Country Codes",
+    "entries": [
+      { "key": "US", "value": "United States" },
+      { "key": "US", "value": "USA" },
+      { "key": "DE", "value": "Germany" },
+      { "key": "DE", "value": "Deutschland" },
+      { "key": "GB", "value": "United Kingdom" },
+      { "key": "GB", "value": "UK" }
+    ]
+  }'
+
+# List versions:
+curl -s https://api.talonic.com/v1/reference-primitives/rp_001/versions \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Get a specific version:
+curl -s https://api.talonic.com/v1/reference-primitives/rp_001/versions/2 \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"`
+      },
       {
         type: "callout",
         variant: "info",
         text: "Versioning protects production stability. When you update a reference primitive, existing schemas continue using their pinned version until you explicitly update the version reference. This prevents unexpected changes to live extraction pipelines."
       },
+      {
+        type: "paragraph",
+        text: "Reference primitives are the centralized source of truth for code mapping across your workspace. Unlike schema-level reference tables that are defined inline and scoped to a single schema, workspace-level primitives are shared resources that any schema can reference. This eliminates duplication \u2014 instead of maintaining identical country code tables across five schemas, you maintain one primitive and reference it from all five. When a new country or code variation needs to be added, you update the primitive once and bump the version reference in each schema. The 3-tier lookup cascade (normalization, fuzzy, AI fallback) runs identically for both primitives and inline tables, so there is no difference in resolution quality."
+      },
       {
         type: "list",
         ordered: false,
@@ -5097,6 +7425,10 @@ var sections11 = [
       {
         question: "What happens when I update a reference primitive?",
         answer: "A new version is created. Existing schemas continue using their pinned version. You must explicitly update the version reference in each schema to use the new data, which protects production pipelines from unexpected changes."
+      },
+      {
+        question: "How do I pin a schema to a specific reference primitive version?",
+        answer: "When configuring a reference table on a schema field, specify both the reference primitive ID and the version number. The schema uses that exact version for all lookups until you explicitly update it. This pin-based approach means you can test a new primitive version against a draft schema without affecting production schemas that are pinned to the previous version."
       }
     ],
     mentions: [
@@ -5143,6 +7475,37 @@ var sections11 = [
           "**Format constraint changes** \u2014 regex pattern updates or fallback behavior modifications on schema fields."
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Check workspace governance settings",
+        code: `# View current workspace settings including change review status:
+curl -s https://api.talonic.com/v1/workspace/settings \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "workspace_id": "ws_001",
+#   "change_review_enabled": true,
+#   "pending_changes": 3,
+#   "reviewers": ["admin@example.com"],
+#   "categories_requiring_review": [
+#     "schema_changes",
+#     "dialect_changes",
+#     "reference_primitive_changes",
+#     "delivery_binding_changes",
+#     "routing_rule_changes"
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Change review is the governance layer that protects production workspaces from unintended disruptions. In a production environment, a small change to a schema field mapping or reference primitive value can ripple through to every document processed after that point. Without change review, these modifications take effect immediately with no undo for documents already processed with the new configuration. By enabling change review, every modification is queued for approval \u2014 a second pair of eyes verifies the technical and business impact before the change goes live. This is particularly important for organizations with compliance requirements where changes to data extraction rules must be documented and approved."
+      },
+      {
+        type: "paragraph",
+        text: "A common workflow for teams transitioning from development to production is to leave change review disabled during the initial setup phase for faster iteration. Once schemas, dialects, and reference primitives are stable and data is flowing to downstream systems through delivery bindings, enable change review. From that point forward, any modification \u2014 whether it is adding a field to a schema, updating a reference primitive version, or changing a delivery binding filter \u2014 requires explicit approval before it takes effect in the live pipeline."
+      },
       {
         type: "callout",
         variant: "warning",
@@ -5170,6 +7533,10 @@ var sections11 = [
       {
         question: "Can I bypass change review for urgent fixes?",
         answer: "Change review can be disabled temporarily from Workspace Settings if an urgent fix is needed. However, this should be done with caution in production workspaces, and the review requirement should be re-enabled afterward."
+      },
+      {
+        question: "Does change review apply to delivery binding modifications?",
+        answer: "Yes. When change review is enabled, modifications to delivery bindings \u2014 including changes to signal filters, field maps, serializer formats, and destination assignments \u2014 are queued for approval. This prevents accidental routing changes from disrupting active delivery pipelines."
       }
     ],
     mentions: [
@@ -5213,6 +7580,36 @@ var sections12 = [
         variant: "info",
         text: "Omnisearch results update as you type. The materialized index is rebuilt automatically whenever documents are processed or schemas change, so results are always current."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Search across documents and extracted values via API",
+        code: `curl -s "https://api.talonic.com/v1/search?q=INV-2025-0042" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "results": [
+#     {
+#       "category": "document",
+#       "id": "doc_001",
+#       "title": "Invoice_ACME_2025.pdf",
+#       "match_field": "invoice_number",
+#       "match_value": "INV-2025-0042"
+#     },
+#     {
+#       "category": "extracted_value",
+#       "document_id": "doc_003",
+#       "field": "reference_number",
+#       "value": "INV-2025-0042"
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Omnisearch is powered by a materialized values index that flattens all extracted field values into a searchable structure. This index is updated incrementally as documents are processed \u2014 there is no batch reindex step that could cause search results to lag behind your data. The search covers seven categories: documents (file names and metadata), extracted values (individual data points across all documents), field names (Field Registry canonical definitions), schema names (generated and template schemas), sources (connection names), matching configurations, and delivery bindings. Results are grouped by category and ranked by relevance, so you can quickly distinguish between a document match and an extracted value match."
+      },
       {
         type: "list",
         ordered: false,
@@ -5248,6 +7645,10 @@ var sections12 = [
       {
         question: "How quickly are new documents searchable in Omnisearch?",
         answer: "Documents become searchable as soon as extraction completes. The materialized index is updated automatically during document processing, so there is no manual reindex step."
+      },
+      {
+        question: "Can I search via the API?",
+        answer: "Yes. Use GET /v1/search?q={query} to search across all categories programmatically. The response groups results by category (document, extracted_value, field, schema, source) with match details including the matched field name and value. This is useful for building custom integrations or automating lookups against your document corpus."
       }
     ],
     mentions: ["omnisearch", "global search", "Cmd+K", "Ctrl+K", "document search", "materialized values index"]
@@ -5291,6 +7692,38 @@ 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: "code",
+        language: "bash",
+        title: "Filter documents by extracted field values via API",
+        code: `# Find high-value invoices from a specific vendor:
+curl -s "https://api.talonic.com/v1/filter?filters=vendor_name%20eq%20%22Acme%20Corp%22%20AND%20total_amount%20gt%205000&limit=10" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "documents": [
+#     {
+#       "id": "doc_001",
+#       "name": "Invoice_ACME_Q1.pdf",
+#       "document_type": "Invoice",
+#       "matched_values": {
+#         "vendor_name": "Acme Corp",
+#         "total_amount": "12450.00"
+#       }
+#     }
+#   ],
+#   "total": 15
+# }
+
+# Find documents missing a critical field:
+curl -s "https://api.talonic.com/v1/filter?filters=payment_terms%20is_empty" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"`
+      },
+      {
+        type: "paragraph",
+        text: 'Document filters are particularly powerful for quality assurance and operational workflows. Use the `is_empty` operator to find documents where critical fields were not extracted \u2014 these are candidates for schema instruction improvement or manual review. Combine `gt` and `between` operators on monetary fields to segment documents by value range for prioritized processing. The URL-serializable filter state means you can build a complex query, copy the URL, and share it with a colleague \u2014 they see exactly the same filtered view without re-building the conditions. Save frequently-used filter combinations as presets for one-click access to common queries like "missing payment terms this month" or "high-value contracts pending review".'
+      },
       {
         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.'
@@ -5317,6 +7750,10 @@ var sections12 = [
       {
         question: "Can I filter on fields that have no value?",
         answer: "Yes. The is_empty operator lets you find documents where a specific field was not extracted or has no value. This is useful for identifying documents that may need reprocessing or manual review."
+      },
+      {
+        question: "Can I use the filter API programmatically for automated reporting?",
+        answer: "Yes. Use GET /v1/filter with query parameters to filter documents by extracted field values programmatically. The filter syntax supports the same operators as the UI \u2014 eq, contains, gt, lt, between, and is_empty. Combine multiple conditions with AND. This is useful for building automated reports, dashboards, or alerts that trigger when documents matching specific criteria are processed."
       }
     ],
     mentions: [
@@ -5396,6 +7833,42 @@ var sections13 = [
             description: "Create and modify resources."
           }
         ]
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "api-key-usage",
+        text: "Using Your API Key"
+      },
+      {
+        type: "paragraph",
+        text: "Once you have created an API key, include it in the Authorization header of every request to the Talonic API. The key is passed as a Bearer token. All API endpoints require authentication \u2014 requests without a valid key receive a 401 Unauthorized response. Rate limiting is applied per API key, so each integration has its own independent rate limit allowance."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Authenticate an API request",
+        code: 'curl https://api.talonic.com/v1/documents \\\n  -H "Authorization: Bearer tlnc_your_api_key_here"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "data": [\n    {\n      "id": "doc_7f3a1b2c",\n      "filename": "invoice.pdf",\n      "status": "completed",\n      "document_type": "Invoice"\n    }\n  ],\n  "meta": { "total": 156, "cursor": "eyJpZCI6MTU2fQ" }\n}'
+      },
+      {
+        type: "paragraph",
+        text: "If your API key is compromised, delete it immediately from Settings and create a new one. Because keys are SHA-256 hashed at rest, the platform cannot display the key again after creation \u2014 you must generate a fresh key and update all integrations that used the old one. For production environments, store API keys in a secrets manager like AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault rather than in environment files or source code."
+      },
+      {
+        type: "paragraph",
+        text: "A common pattern for enterprise teams is to create three API keys with different scopes: one extract-only key for your ingestion pipeline, one read-only key for your BI dashboard or monitoring tools, and one write key for administrative automation scripts. This separation ensures that a compromised dashboard key cannot be used to upload documents or modify schemas, and that your ingestion pipeline key cannot access sensitive configuration endpoints. Rotate each key independently on a regular schedule \u2014 monthly rotation is a common best practice for production environments."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Check rate limit headers",
+        code: 'curl -I https://api.talonic.com/v1/documents \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"\n\n# Response headers include:\n# X-RateLimit-Remaining: 98\n# X-RateLimit-Reset: 1746604800'
       }
     ],
     related: [
@@ -5419,6 +7892,14 @@ var sections13 = [
       {
         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."
+      },
+      {
+        question: "How do I check my rate limit usage?",
+        answer: "Every API response includes X-RateLimit-Remaining and X-RateLimit-Reset headers. X-RateLimit-Remaining shows how many requests you can make before hitting the limit, and X-RateLimit-Reset shows the Unix timestamp when the limit resets. If you receive a 429 Too Many Requests response, wait until the reset time before retrying."
+      },
+      {
+        question: "What is the recommended API key setup for production?",
+        answer: "Create three separate keys with different scopes: one extract-only key for your ingestion pipeline, one read-only key for dashboards and monitoring, and one write key for administrative automation. This separation ensures a compromised read-only key cannot upload documents or modify schemas. Label each key with the integration it serves and rotate them on a regular monthly schedule."
       }
     ],
     mentions: ["API keys", "tlnc_", "SHA-256", "Bearer token", "scopes"]
@@ -5471,6 +7952,40 @@ var sections13 = [
         variant: "info",
         text: "See the full [API Documentation](/docs) for detailed endpoint specifications, request/response examples, and authentication guides. The API reference is organized by namespace and includes every parameter, status code, and error response."
       },
+      {
+        type: "heading",
+        level: 3,
+        id: "api-quick-start",
+        text: "API Quick Start"
+      },
+      {
+        type: "paragraph",
+        text: "The fastest way to start using the API is to upload a document and retrieve its extraction results. The example below shows the complete flow: upload a file to a source, poll until processing completes, then fetch the extracted fields. This three-step pattern is the foundation for any API integration \u2014 from simple one-off extractions to complex automated pipelines."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Step 1: Upload a document",
+        code: 'curl -X POST https://api.talonic.com/v1/sources/src_abc123/documents \\\n  -H "Authorization: Bearer $TALONIC_API_KEY" \\\n  -F "file=@invoice.pdf"'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Step 2: Check processing status",
+        code: 'curl https://api.talonic.com/v1/documents/doc_7f3a1b2c \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Step 3: Retrieve extraction results",
+        code: 'curl https://api.talonic.com/v1/extractions/doc_7f3a1b2c \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Extraction response",
+        code: '{\n  "document_id": "doc_7f3a1b2c",\n  "document_type": "Invoice",\n  "fields": [\n    {\n      "name": "invoice_number",\n      "value": "INV-2026-0472",\n      "confidence": 0.98\n    },\n    {\n      "name": "vendor_name",\n      "value": "Acme Corp",\n      "confidence": 0.96\n    },\n    {\n      "name": "total_amount",\n      "value": "4,250.00",\n      "confidence": 0.95\n    }\n  ]\n}'
+      },
       {
         type: "param-table",
         title: "API namespaces",
@@ -5649,6 +8164,42 @@ var sections13 = [
         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: "heading",
+        level: 3,
+        id: "webhook-setup-api",
+        text: "Setting Up Webhooks via API"
+      },
+      {
+        type: "paragraph",
+        text: "Webhooks are configured through the delivery API. First create a destination of type webhook with your endpoint URL and signing secret, then create a binding that maps signal types to the destination. You can bind multiple signal types to the same destination or use separate destinations for different event categories. The delivery catalog endpoint lists all available signal types so you can choose which events to subscribe to."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List available webhook signal types",
+        code: 'curl https://api.talonic.com/v1/delivery/catalog/signals \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Verify a webhook signature (Node.js example)",
+        code: `# Your endpoint receives:
+# Header: X-Talonic-Signature: sha256=abc123...
+# Body: {"type":"document.extracted","data":{...}}
+
+# Verify with:
+const crypto = require('crypto');
+const expected = crypto
+  .createHmac('sha256', SIGNING_SECRET)
+  .update(rawBody)
+  .digest('hex');
+const valid = signature === \`sha256=\${expected}\`;`
+      },
+      {
+        type: "paragraph",
+        text: "For high-reliability integrations, always verify the HMAC-SHA256 signature before processing webhook payloads. Compute the HMAC of the raw request body using your signing secret and compare it to the signature header. This verification confirms that the payload was sent by Talonic and has not been tampered with in transit. Additionally, use the idempotency key header to deduplicate retried deliveries \u2014 store processed idempotency keys and skip any payload you have already handled."
+      },
       {
         type: "param-table",
         title: "Delivery signal types (webhook-compatible)",
@@ -5728,6 +8279,14 @@ var sections13 = [
       {
         question: "How do I verify webhook signatures?",
         answer: "Each webhook payload is signed with HMAC-SHA256 using the signing secret from your delivery destination configuration. Compute the HMAC of the raw request body and compare it to the signature header to verify authenticity. This ensures the payload was sent by Talonic and was not tampered with in transit."
+      },
+      {
+        question: "How do I replay failed webhook deliveries?",
+        answer: "Failed deliveries that exhaust all retries are routed to the dead-letter queue (DLQ). You can replay any DLQ item via POST /v1/delivery/dlq/:id/replay, which enqueues a fresh delivery attempt. Replay is append-only \u2014 it creates a new attempt without modifying the original failure record, preserving the full delivery history for auditing."
+      },
+      {
+        question: "Can I use webhooks with batch processing?",
+        answer: "Yes. When documents uploaded with processing_mode=batch complete extraction, the document.extracted signal fires just like for realtime documents. You can bind this signal to a webhook destination to receive notifications when batch results are ready. The run.extraction.completed signal also fires when an entire batch inference run finishes, which is useful for monitoring batch completions at a higher level."
       }
     ],
     mentions: [
@@ -5816,6 +8375,36 @@ var sections14 = [
           "Assign the appropriate role based on their responsibilities.",
           "Optionally, change roles later from the same Team page."
         ]
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "team-api-access",
+        text: "API Access and Roles"
+      },
+      {
+        type: "paragraph",
+        text: "API key scopes are separate from team roles, but they work together to enforce access control. An API key created by an Owner can have any combination of scopes (extract, read, write), while team role permissions apply when members interact through the web interface or AI agent. For programmatic integrations, create dedicated API keys with the minimum required scopes rather than sharing a single key across all team members. This separation ensures that revoking a team member's access does not disrupt API-based workflows."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List documents using a read-scoped API key",
+        code: 'curl https://api.talonic.com/v1/documents \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "data": [\n    {\n      "id": "doc_7f3a1b2c",\n      "filename": "invoice.pdf",\n      "status": "completed",\n      "document_type": "Invoice"\n    }\n  ],\n  "meta": { "total": 156, "cursor": "eyJpZCI6MTU2fQ" }\n}'
+      },
+      {
+        type: "paragraph",
+        text: "When onboarding a new team, a common pattern is to have the Owner create the workspace and set up API keys, then invite team members via domain matching. Admins handle day-to-day member approvals and role assignments, while Members focus on document processing and schema configuration. This separation of concerns scales well from small teams of two or three people to larger organizations with dozens of members across multiple departments."
+      },
+      {
+        type: "paragraph",
+        text: 'For security-sensitive organizations, it is important to establish clear API key ownership practices. Only Owners can create and revoke API keys, which prevents team members from generating keys that might bypass role-based access controls. Each key should be labelled with the integration it serves (e.g., "BI Dashboard - Read Only", "ETL Pipeline - Extract") so that when a team member leaves or an integration is decommissioned, the corresponding key can be identified and revoked quickly without guessing which key belongs to which system.'
       }
     ],
     related: [
@@ -5830,7 +8419,7 @@ var sections14 = [
       },
       {
         question: "How are new team members added?",
-        answer: "New members are added via domain matching: company email domains auto-match to your organization with pending status. Admin approval is required before access is granted."
+        answer: "New members are added via domain matching: company email domains auto-match to your organization with pending status requiring admin approval. An Admin or Owner must explicitly approve each pending member before they gain access to any workspace data. This ensures no unauthorized users can access your documents or extraction results."
       },
       {
         question: "Can I change a team member's role after they join?",
@@ -5839,6 +8428,10 @@ var sections14 = [
       {
         question: "What happens if I remove a team member?",
         answer: "Removing a team member revokes their access to the organization immediately. Their past actions (edits, uploads, approvals) remain in the audit trail. They can be re-added later through the same domain matching process."
+      },
+      {
+        question: "How do API key scopes relate to team roles?",
+        answer: "API key scopes and team roles are separate access control mechanisms that work together to enforce security. API keys have three scopes (extract, read, write) that govern what API operations the key can perform. Team roles (Viewer, Member, Admin, Owner) govern what users can do through the web interface and AI agent. Only Owners can create and revoke API keys. Create dedicated API keys with minimum required scopes for each integration rather than sharing keys across team members."
       }
     ],
     mentions: [
@@ -5922,6 +8515,48 @@ var sections14 = [
         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. Each entry links back to the specific document and job that triggered the call."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "usage-api",
+        text: "Tracking Usage via API"
+      },
+      {
+        type: "paragraph",
+        text: "Usage data is fully accessible through the REST API, enabling you to build custom cost monitoring dashboards or integrate usage tracking into your financial systems. The credits endpoint provides credit balance, transaction history, daily breakdowns, and per-request usage logs. This is particularly useful for organizations that need to allocate extraction costs across departments or client projects based on actual usage."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Get credit balance and usage summary",
+        code: 'curl https://api.talonic.com/v1/credits \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "balance": 12450,\n  "total_used": 37550,\n  "usage_by_feature": {\n    "extraction": 22100,\n    "ocr": 8900,\n    "batch": 4200,\n    "matching": 2350\n  },\n  "period": "current_month"\n}'
+      },
+      {
+        type: "paragraph",
+        text: "For automated cost monitoring, query the daily breakdown endpoint to track spend trends over time. Set up alerts in your monitoring system when daily spend exceeds a threshold \u2014 this catches unexpected usage spikes caused by large document uploads or misconfigured routing rules before they accumulate into significant costs. Teams that monitor usage proactively typically identify optimization opportunities that reduce their monthly extraction costs by 20-30%."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Get daily usage breakdown",
+        code: 'curl https://api.talonic.com/v1/credits/daily \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "data": [\n    { "date": "2026-05-07", "cost": 12.50, "documents_processed": 45 },\n    { "date": "2026-05-06", "cost": 8.30, "documents_processed": 31 },\n    { "date": "2026-05-05", "cost": 15.80, "documents_processed": 62 }\n  ]\n}'
+      },
+      {
+        type: "paragraph",
+        text: "The per-request usage log is particularly valuable for cost allocation. Each entry includes the document ID, job ID, model used, token counts, and computed cost. This granular data lets you attribute costs to specific documents, document types, or processing jobs. For organizations that charge back extraction costs to departments or clients, this data provides the foundation for accurate, auditable billing. Export the usage log via the API and feed it into your accounting or BI system for automated cost reporting."
       }
     ],
     related: [
@@ -5941,6 +8576,10 @@ 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. 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."
+      },
+      {
+        question: "Can I access usage data through the API?",
+        answer: "Yes. The /v1/credits endpoint provides credit balance, transaction history, daily cost breakdowns, and per-request usage logs. Use this data to build custom cost dashboards, allocate costs across departments, or set up automated spending alerts in your monitoring system. Each entry links back to the specific document and job that generated the cost."
       }
     ],
     mentions: [
@@ -5975,6 +8614,10 @@ var sections14 = [
         type: "paragraph",
         text: "For best results, limit Admin Panel access to a small group of trusted platform operators. Use the **master registry** view to audit field definitions and schemas across tenants \u2014 this is particularly useful when standardizing extraction configurations or troubleshooting cross-tenant data quality issues."
       },
+      {
+        type: "paragraph",
+        text: "The data clear and rebuild operation is designed for specific scenarios: initial onboarding when a customer uploads test documents that should not persist, significant schema changes that require reprocessing the entire corpus, or data quality issues where starting fresh produces better results than incremental fixes. Before executing a data clear, always confirm with the customer and verify that any approved data products have been exported to downstream systems, since the operation permanently removes all extraction history and job results."
+      },
       {
         type: "list",
         ordered: false,
@@ -5990,6 +8633,36 @@ var sections14 = [
         type: "callout",
         variant: "warning",
         text: "The **data clear** operation is irreversible. It deletes all documents, extractions, jobs, and results for the selected customer. Use with caution and only when a full reprocessing is genuinely needed."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "admin-workflows",
+        text: "Common Admin Workflows"
+      },
+      {
+        type: "paragraph",
+        text: "The most common admin workflow is onboarding a new customer. Navigate to Customer Management, create the organization, then share the workspace URL with the customer's team lead. As team members sign up with their company email domain, they appear in the pending approval queue. The admin reviews and approves each member, assigning roles based on their responsibilities. Once the team is set up, the admin can create initial API keys and configure source connectors to get the customer started with document ingestion."
+      },
+      {
+        type: "paragraph",
+        text: "For troubleshooting, the master registry view is invaluable. It lets you inspect a customer's field registry, schemas, and extraction results from a single cross-tenant interface. If a customer reports low extraction quality, start by checking their field registry \u2014 a registry with mostly Tier 3 fields and low instruction coverage suggests the knowledge graph has not matured enough. Running a batch resolution followed by instruction synthesis often resolves the issue by promoting fields and generating master extraction instructions."
+      },
+      {
+        type: "paragraph",
+        text: "The Admin Panel also provides tools for platform capacity planning. By reviewing usage statistics across all customers, administrators can identify growth trends, forecast compute and storage needs, and plan infrastructure scaling ahead of demand spikes. The per-customer breakdown reveals which organizations are the heaviest users and which features drive the most cost, helping prioritize optimization efforts where they have the greatest impact."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "List all organizations (admin only)",
+        code: 'curl https://api.talonic.com/v1/admin/customers \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "code",
+        language: "json",
+        title: "Response",
+        code: '{\n  "data": [\n    {\n      "id": "cust_001",\n      "name": "Acme Corp",\n      "members_count": 12,\n      "documents_count": 1847,\n      "created_at": "2026-01-15T08:00:00Z"\n    }\n  ],\n  "meta": { "total": 8 }\n}'
       }
     ],
     related: [
@@ -6012,6 +8685,10 @@ var sections14 = [
       {
         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. This is useful for identifying high-usage tenants, tracking platform growth, and forecasting infrastructure needs."
+      },
+      {
+        question: "How do I troubleshoot low extraction quality for a customer?",
+        answer: "Start by checking the customer's field registry via the master registry view. Look at tier distribution, instruction coverage, and unresolved occurrence count. A registry dominated by Tier 3 fields with low instruction coverage suggests the knowledge graph needs more data. Run batch resolution followed by instruction synthesis to promote fields and generate extraction directives. Then review the telemetry metrics \u2014 capture rate, resolve rate, and synthesize rate \u2014 to confirm improvement."
       }
     ],
     mentions: [
@@ -6080,6 +8757,36 @@ var sections14 = [
         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. Use it when you receive a document via email or chat and want instant extraction results."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "shortcuts-workflow",
+        text: "Shortcuts in Practice"
+      },
+      {
+        type: "paragraph",
+        text: 'Keyboard shortcuts become especially powerful when combined with the AI agent. A typical power-user workflow looks like this: press `Cmd+J` to quick-extract a document that just arrived via email, then press `Cmd+I` to open the agent and ask "What fields did the platform extract from my latest document?" The agent responds with the full list of extracted fields, confidence scores, and the document classification. If you need to find a related document, press `Cmd+K` and search by a field value like the vendor name or invoice number. All three actions happen without navigating away from your current page.'
+      },
+      {
+        type: "paragraph",
+        text: "For teams that process documents throughout the day, these shortcuts save significant time by eliminating navigation clicks. Over a typical workday of processing 20-30 documents, keyboard shortcuts can save 15-20 minutes compared to clicking through the sidebar for each operation. The time savings compound further when reviewing extraction results, since `Cmd+I` (AI agent) provides instant answers to quality questions that would otherwise require navigating to multiple pages."
+      },
+      {
+        type: "paragraph",
+        text: "Omnisearch (`Cmd+K`) deserves special mention because it searches across multiple resource types simultaneously. When you type a query, it returns matching documents, extracted field values, schema names, source names, and field registry entries \u2014 all in a single search overlay. This makes it the fastest way to locate any resource in your workspace. For example, searching for a vendor name returns every document mentioning that vendor, every schema field that matches, and every registry entry related to that concept."
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Equivalent API call for quick extract (Cmd+J)",
+        code: 'curl -X POST https://api.talonic.com/v1/sources/src_abc123/documents \\\n  -H "Authorization: Bearer $TALONIC_API_KEY" \\\n  -F "file=@receipt.jpg"'
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Equivalent API call for omnisearch (Cmd+K)",
+        code: 'curl "https://api.talonic.com/v1/search?q=Acme%20Corp" \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
       }
     ],
     related: [
@@ -6098,6 +8805,14 @@ var sections14 = [
       {
         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. The AI Agent shortcut (Cmd+I) also works from any context. Quick extract (Cmd+J) is available from the main interface."
+      },
+      {
+        question: "Can I perform the same actions as keyboard shortcuts through the API?",
+        answer: "Yes. Quick extract (Cmd+J) corresponds to POST /v1/sources/:sourceId/documents for uploading a document. Omnisearch (Cmd+K) corresponds to GET /v1/search for querying across documents, fields, and schemas. The AI Agent (Cmd+I) does not have a direct API equivalent since it is a conversational interface, but all the data it queries is accessible through the individual API endpoints."
+      },
+      {
+        question: "Are there keyboard shortcuts for navigation within pages?",
+        answer: "The four global shortcuts (Cmd+K, Cmd+J, Cmd+I, Escape) work from any page. Within specific pages like the job results grid, you can use standard browser keyboard navigation (Tab, Enter, arrow keys) to move between cells and expand provenance panels. The platform does not override standard browser shortcuts beyond the four global bindings, so your usual browser keyboard patterns continue to work."
       }
     ],
     mentions: ["keyboard shortcuts", "Cmd+K", "Cmd+J", "Escape", "quick extract"]
@@ -6143,6 +8858,49 @@ var sections15 = [
           "**Immediate visibility** \u2014 documents appear in your library right after Stage 1 (OCR + classification).",
           "**Automatic result application** \u2014 when the batch completes, results are applied and documents transition to their final status."
         ]
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Upload documents in batch mode via API",
+        code: `curl -X POST https://api.talonic.com/v1/extract \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -F "file=@invoices_batch.pdf" \\
+  -F "processing_mode=batch"
+
+# Response:
+# {
+#   "document_id": "doc_batch_001",
+#   "status": "batch_queued",
+#   "processing_mode": "batch",
+#   "stage_1_completed": true,
+#   "document_type": "Invoice",
+#   "message": "Stage 1 complete. Stage 2 deferred to batch API."
+# }`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Check batch status",
+        code: `curl -s https://api.talonic.com/v1/batches \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "batches": [
+#     {
+#       "id": "batch_abc",
+#       "status": "submitted",
+#       "item_count": 150,
+#       "submitted_at": "2025-04-22T10:15:00Z",
+#       "provider": "anthropic"
+#     }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "Batch inference is particularly cost-effective for periodic bulk operations. A common workflow is to configure a source connection (such as Google Drive or S3) with the batch processing toggle enabled, so all documents ingested through that source are automatically routed to the batch queue. This is ideal for overnight processing of large document volumes \u2014 documents arrive throughout the day, accumulate in the batch queue, and are submitted together to the provider for off-peak processing. By morning, all results have been applied and documents are ready for review at half the extraction cost."
       }
     ],
     related: [
@@ -6166,6 +8924,10 @@ var sections15 = [
       {
         question: "Does batch mode affect extraction quality?",
         answer: "No. Batch mode uses the same Claude extraction model and prompts as real-time processing. The only difference is timing \u2014 extraction is deferred to take advantage of provider off-peak pricing."
+      },
+      {
+        question: "Can I mix batch and real-time documents in the same workspace?",
+        answer: "Yes. Batch and real-time documents coexist in the same workspace and library. Each document tracks its processing_mode independently. You can toggle batch mode per upload or per source connection. Time-sensitive documents use real-time processing while bulk backlogs use batch mode \u2014 both produce identical extraction output."
       }
     ],
     mentions: ["batch inference", "50% cost", "48-hour delivery", "backlog ingestion", "Message Batches API"]
@@ -6224,6 +8986,24 @@ var sections15 = [
           "**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."
         ]
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Enable batch processing on a source connection",
+        code: `# Toggle batch mode for all documents from a Google Drive source:
+curl -X PATCH https://api.talonic.com/v1/sources/src_gdrive_001 \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{ "batch_processing": true }'
+
+# All future documents ingested from this source will use
+# batch processing mode automatically.
+# Stage 1 (OCR + classify) still runs immediately.`
+      },
+      {
+        type: "paragraph",
+        text: "The two-stage architecture of batch processing provides an elegant balance between immediate feedback and cost optimization. Stage 1 processes immediately \u2014 within seconds, you know what type of document was uploaded, its classification, triage metadata, and it appears in your library. Only Stage 2 (the expensive LLM extraction step) is deferred. This means you can build workflows that react to document arrival (routing rules, notifications, triage) without waiting for batch results, while still saving 50% on the extraction cost. Documents show a clear `batch_queued` status in the library so you always know which documents are waiting for extraction results."
       }
     ],
     related: [
@@ -6247,6 +9027,10 @@ var sections15 = [
       {
         question: "Can I enable batch mode per source?",
         answer: "Yes. Each source connection has a batch processing toggle. When enabled, all documents ingested through that source are automatically processed in batch mode."
+      },
+      {
+        question: "Why are image-only documents excluded from batch processing?",
+        answer: "The batch payload is text-only \u2014 it contains the OCR markdown from Stage 1. Image-only documents (PNG, JPG) that have no extractable text require Claude Vision, which uses the image bytes directly. Since image bytes cannot be included in the text-based batch payload, these documents are automatically routed to real-time processing even when batch mode is enabled."
       }
     ],
     mentions: [
@@ -6306,6 +9090,36 @@ var sections15 = [
           }
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Monitor batch progress via API",
+        code: `# List all batches with their statuses:
+curl -s https://api.talonic.com/v1/batches \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Get detail for a specific batch including item states:
+curl -s https://api.talonic.com/v1/batches/batch_abc \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "id": "batch_abc",
+#   "status": "submitted",
+#   "item_count": 150,
+#   "submitted_at": "2025-04-22T10:15:00Z",
+#   "provider": "anthropic",
+#   "items": [
+#     { "document_id": "doc_001", "status": "pending" },
+#     { "document_id": "doc_002", "status": "completed" },
+#     { "document_id": "doc_003", "status": "parse_error", "retried_realtime": true }
+#   ]
+# }`
+      },
+      {
+        type: "paragraph",
+        text: "The batch detail view is your primary tool for diagnosing issues with batch processing. Each item shows its individual status \u2014 pending, completed, or parse_error with a retried_realtime flag indicating whether the system automatically retried it through the real-time path. Items with parse errors are retried exactly once through the real-time extraction path, ensuring the 48-hour SLA is maintained. If a batch has an unusually high parse error rate, this may indicate a problem with the documents themselves (corrupt files, unusual formatting) rather than a system issue. The crash recovery mechanism ensures that infrastructure disruptions \u2014 application restarts, memory pressure, or network interruptions \u2014 do not leave batches in a permanently stuck state."
+      },
       {
         type: "callout",
         variant: "info",
@@ -6333,6 +9147,10 @@ var sections15 = [
       {
         question: "What happens if a batch gets stuck?",
         answer: 'The platform includes crash recovery logic. Batches stuck in "processing" for more than 15 minutes are automatically reverted to "submitted" so the next poll cycle retries them. No manual intervention is needed.'
+      },
+      {
+        question: "How do I check the status of a specific document in a batch?",
+        answer: "Use GET /v1/batches/{id} to see the batch detail view, which lists every item with its individual status (pending, completed, or parse_error). You can also check the document directly via GET /v1/documents/{id} \u2014 batch-queued documents show status batch_queued until results are applied, then transition to their final status."
       }
     ],
     mentions: [
@@ -6377,6 +9195,48 @@ var sections16 = [
         variant: "info",
         text: "You can also import reference data directly from a SQL database connection. The import runs asynchronously \u2014 rows are streamed in batches of 500 and column headers appear immediately so you can preview the structure while the import runs."
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Upload reference data via CSV",
+        code: `curl -X POST https://api.talonic.com/v1/matching/reference-data \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -F "file=@vendor_registry.csv"
+
+# Response:
+# {
+#   "id": "ref_vendor_001",
+#   "name": "vendor_registry",
+#   "status": "ready",
+#   "row_count": 2450,
+#   "columns": ["vendor_id", "vendor_name", "country", "tax_id"],
+#   "created_at": "2025-04-22T10:00:00Z"
+# }`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Import reference data from a SQL database",
+        code: `curl -X POST https://api.talonic.com/v1/matching/reference-data/from-sql \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "connection_id": "src_sql_001",
+    "kind": "table",
+    "table_name": "vendors",
+    "schema_name": "public"
+  }'
+
+# Response (async \u2014 poll status until ready):
+# {
+#   "id": "ref_vendor_002",
+#   "status": "importing",
+#   "source_meta": {
+#     "connection_id": "src_sql_001",
+#     "table_name": "vendors"
+#   }
+# }`
+      },
       {
         type: "list",
         ordered: false,
@@ -6409,6 +9269,10 @@ var sections16 = [
       {
         question: "What happens if I delete a source connection that was used for a SQL import?",
         answer: 'The reference data remains intact. Deleting a source connection does not cascade to reference datasets \u2014 the UI shows a "source disconnected" indicator, but the imported data continues to work for matching.'
+      },
+      {
+        question: "How do I refresh reference data from a SQL source?",
+        answer: "Re-run the SQL import using the same connection and table parameters. A new reference dataset is created with the latest data. Update your matching configurations to point to the new dataset version. The previous version remains available for comparison."
       }
     ],
     mentions: [
@@ -6474,6 +9338,45 @@ var sections16 = [
         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: "code",
+        language: "bash",
+        title: "Create a matching configuration",
+        code: `curl -X POST https://api.talonic.com/v1/matching/configs \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "Invoice to PO Matching",
+    "reference_data_id": "ref_vendor_001",
+    "field_mappings": [
+      { "source": "vendor_name", "target": "vendor_name", "strategy": "fuzzy", "weight": 0.4 },
+      { "source": "po_number", "target": "po_number", "strategy": "exact", "weight": 0.35 },
+      { "source": "total_amount", "target": "amount", "strategy": "numeric_range", "weight": 0.15, "tolerance": 0.02 },
+      { "source": "invoice_date", "target": "po_date", "strategy": "date_range", "weight": 0.1, "tolerance_days": 7 }
+    ]
+  }'`
+      },
+      {
+        type: "code",
+        language: "bash",
+        title: "Generate AI-suggested matching strategy",
+        code: `curl -X POST https://api.talonic.com/v1/matching/strategies/generate \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "schema_id": "us_def456",
+    "reference_data_id": "ref_vendor_001"
+  }'
+
+# Response:
+# {
+#   "id": "strat_001",
+#   "suggested_mappings": [
+#     { "source": "vendor_name", "target": "vendor_name", "strategy": "fuzzy", "weight": 0.4, "confidence": 0.95 },
+#     { "source": "invoice_number", "target": "ref_number", "strategy": "exact", "weight": 0.35, "confidence": 0.88 }
+#   ]
+# }`
+      },
       {
         type: "list",
         ordered: false,
@@ -6506,6 +9409,10 @@ var sections16 = [
       {
         question: "What is the difference between fuzzy and exact matching?",
         answer: "Exact matching requires an identical string (case-insensitive). Fuzzy matching uses token-based comparison with a configurable similarity threshold, making it suitable for fields with minor variations like misspellings, abbreviations, or word reordering."
+      },
+      {
+        question: "How should I set weights for my matching fields?",
+        answer: "Assign high weights (0.3-0.5) to strong identifiers like reference numbers or unique IDs. Assign medium weights (0.1-0.2) to supporting fields like names, dates, and amounts. The weights must sum to 1.0. A common starting pattern is one high-weight exact match on a unique identifier plus two or three lower-weight fuzzy or range matches on supporting fields."
       }
     ],
     mentions: [
@@ -6552,6 +9459,31 @@ var sections16 = [
           "Review results when the run completes."
         ]
       },
+      {
+        type: "code",
+        language: "bash",
+        title: "Trigger a matching run and monitor progress",
+        code: `# Start a standard matching run:
+curl -X POST https://api.talonic.com/v1/matching/configs/cfg_001/run \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Start a smart run with AI resolution:
+curl -X POST https://api.talonic.com/v1/matching/configs/cfg_001/smart-run \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Check progress:
+curl -s "https://api.talonic.com/v1/matching/runs/mrun_001/progress" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+# -> { "processed": 180, "total": 245, "estimated_remaining_ms": 32000 }
+
+# Cancel if needed (partial results preserved):
+curl -X POST https://api.talonic.com/v1/matching/runs/mrun_001/cancel \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"`
+      },
+      {
+        type: "paragraph",
+        text: "You can also trigger an AI resolution pass on a completed run without re-running the entire job. The `POST /v1/matching/runs/{id}/ai-resolve` endpoint specifically targets low-confidence results from the initial deterministic matching pass and applies the embedding-based similarity search plus Haiku LLM evaluation to upgrade their scores. This is more efficient than running a full smart run when you only need to improve a small subset of borderline results. The AI resolver evaluates each ambiguous candidate in context, considering the full set of field comparisons and the document content, to make a more informed match decision than the deterministic strategies alone."
+      },
       {
         type: "callout",
         variant: "info",
@@ -6579,6 +9511,10 @@ var sections16 = [
       {
         question: "Can I cancel a matching run in progress?",
         answer: "Yes. You can cancel a running match job from the matching page. Partial results from documents already processed are preserved and available for review."
+      },
+      {
+        question: "Can I upgrade specific low-confidence results without re-running the entire job?",
+        answer: "Yes. Use POST /v1/matching/runs/{id}/ai-resolve to trigger an AI resolution pass on a completed run. This targets only low-confidence results and applies embedding similarity plus Haiku LLM evaluation to improve their match quality, without re-processing documents that already have high-confidence matches."
       }
     ],
     mentions: ["matching runs", "async execution", "BullMQ", "progress monitoring", "smart run", "AI resolution"]
@@ -6632,6 +9568,40 @@ var sections16 = [
         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: "code",
+        language: "bash",
+        title: "Get match results for a completed run",
+        code: `curl -s "https://api.talonic.com/v1/matching/runs/mrun_001/results?limit=5" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY"
+
+# Response:
+# {
+#   "results": [
+#     {
+#       "id": "mres_001",
+#       "document_id": "doc_001",
+#       "document_name": "Invoice_ACME.pdf",
+#       "top_candidates": [
+#         {
+#           "reference_row_id": "row_42",
+#           "confidence": 87,
+#           "evidence": [
+#             { "field": "vendor_name", "strategy": "fuzzy", "score": 92, "source_value": "Acme Corp", "target_value": "ACME Corporation" },
+#             { "field": "total_amount", "strategy": "numeric_range", "score": 100, "source_value": "12450.00", "target_value": "12450.00" }
+#           ]
+#         }
+#       ]
+#     }
+#   ]
+# }
+
+# Approve a match result:
+curl -X POST "https://api.talonic.com/v1/matching/runs/mrun_001/results/mres_001/review" \\
+  -H "Authorization: Bearer $TALONIC_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d '{ "action": "approve", "candidate_index": 0 }'`
+      },
       {
         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.'
@@ -6658,6 +9628,10 @@ var sections16 = [
       {
         question: "Why does a match have a low confidence score?",
         answer: "Low confidence usually means the fields being compared have significant differences or the matching strategies produced weak scores. Check the per-field evidence to identify which comparisons dragged the score down, then consider adjusting weights or strategies in the matching configuration."
+      },
+      {
+        question: "Do approved match results feed into delivery pipelines?",
+        answer: "Yes. Approved matches can be included in structured exports and delivery payloads alongside extraction data. This enables end-to-end workflows where extracted document data is matched against reference records and the combined result is delivered to your downstream system in a single payload."
       }
     ],
     mentions: [