@talonic/docs 0.20.31 → 0.20.33

package/dist/content.js

@@ -1,5 +1,5 @@
 // src/content/helpers.ts
-function deriveBreadcrumbs(sections62, leafId, domain) {
+function deriveBreadcrumbs(sections66, leafId, domain) {
   const domainLabels = {
     api: "API Reference",
     platform: "Platform Guide",
@@ -10,20 +10,20 @@ function deriveBreadcrumbs(sections62, leafId, domain) {
     label: domainLabels[domain] ?? domain,
     slug: domain
   };
-  for (const group of sections62) {
+  for (const group of sections66) {
     const child = group.children?.find((c) => c.id === leafId);
     if (child) {
       return [root, { label: group.label, slug: group.id }, { label: child.label, slug: child.id }];
     }
   }
-  const topLevel = sections62.find((s) => s.id === leafId);
+  const topLevel = sections66.find((s) => s.id === leafId);
   if (topLevel) {
     return [root, { label: topLevel.label, slug: topLevel.id }];
   }
   return [root];
 }
-function derivePrevNext(sections62, leafId) {
-  const flat = sections62.flatMap(
+function derivePrevNext(sections66, leafId) {
+  const flat = sections66.flatMap(
     (s) => s.children ?? [{ id: s.id, label: s.label }]
   );
   const idx = flat.findIndex((c) => c.id === leafId);
@@ -53,14 +53,18 @@ var API_NAV_SECTIONS = [
   { id: "documents", label: "Documents", children: [
     { id: "list-documents", label: "List Documents" },
     { id: "get-document", label: "Get Document" },
+    { id: "get-document-fields", label: "Get Document Fields" },
+    { id: "get-document-lineage", label: "Get Document Lineage" },
     { id: "delete-document", label: "Delete Document" },
-    { id: "convert-document", label: "Convert to Markdown" }
+    { id: "convert-document", label: "Convert to Markdown" },
+    { id: "inject-customer-metadata", label: "Inject Metadata" }
   ] },
   { id: "extractions", label: "Extractions", children: [
     { id: "list-extractions", label: "List Extractions" },
     { id: "get-extraction", label: "Get Extraction" },
     { id: "get-extraction-fields", label: "Get Extraction Data" },
-    { id: "get-extraction-markdown", label: "Correct Fields" }
+    { id: "get-extraction-markdown", label: "Correct Fields" },
+    { id: "correct-extraction", label: "Correct Extraction" }
   ] },
   { id: "schemas", label: "Schemas", children: [
     { id: "list-schemas", label: "List Schemas" },
@@ -78,7 +82,8 @@ var API_NAV_SECTIONS = [
     { id: "list-sources", label: "List Inputs" },
     { id: "create-source", label: "Create Input" },
     { id: "get-source", label: "Get / Update / Delete" },
-    { id: "update-source", label: "Source Documents" }
+    { id: "update-source", label: "Source Documents" },
+    { id: "ingest-source-document", label: "Ingest a Document" }
   ] },
   { id: "filter-search", label: "Filter & Search", children: [
     { id: "field-autocomplete", label: "Field Autocomplete" },
@@ -88,7 +93,8 @@ var API_NAV_SECTIONS = [
     { id: "omnisearch", label: "Saved Filters" },
     { id: "saved-filters", label: "Document Counts" },
     { id: "document-counts", label: "Materialize" },
-    { id: "materialized-index", label: "Materialized Index" }
+    { id: "materialized-index", label: "Materialized Index" },
+    { id: "search-endpoints", label: "Search Endpoints" }
   ] },
   { id: "webhooks", label: "Webhooks", children: [
     { id: "webhook-events", label: "Events" },
@@ -97,7 +103,8 @@ var API_NAV_SECTIONS = [
     { id: "webhook-retry", label: "Retry Policy" },
     { id: "list-webhook-configs", label: "List Configs" },
     { id: "create-webhook-config", label: "Create Config" },
-    { id: "manage-webhook-config", label: "Manage Config" }
+    { id: "manage-webhook-config", label: "Manage Config" },
+    { id: "webhook-reference-endpoints", label: "Reference Endpoints" }
   ] },
   { id: "resolutions", label: "Resolutions", children: [
     { id: "list-resolutions", label: "List Resolutions" },
@@ -195,6 +202,7 @@ var API_NAV_SECTIONS = [
     { id: "manage-delivery-binding", label: "Manage Binding" },
     { id: "delivery-history", label: "History" },
     { id: "delivery-dlq", label: "Dead Letter Queue" },
+    { id: "delivery-pending-events", label: "Pending & Events" },
     { id: "delivery-catalog", label: "Catalog" }
   ] },
   { id: "batches", label: "Batches", children: [
@@ -207,6 +215,7 @@ var API_NAV_SECTIONS = [
     { id: "list-cases", label: "List Cases" },
     { id: "get-case", label: "Get Case" },
     { id: "case-anomalies", label: "Anomalies" },
+    { id: "case-evidence", label: "Evidence" },
     { id: "case-operations", label: "Operations" },
     { id: "case-edges", label: "Edges" },
     { id: "case-documents", label: "Documents" },
@@ -233,8 +242,7 @@ var API_NAV_SECTIONS = [
   { id: "routing-rules", label: "Routing Rules", children: [
     { id: "list-routing-rules", label: "List Rules" },
     { id: "create-routing-rule", label: "Create Rule" },
-    { id: "manage-routing-rule", label: "Manage Rule" },
-    { id: "reorder-routing-rules", label: "Reorder" }
+    { id: "manage-routing-rule", label: "Manage Rule" }
   ] },
   { id: "reference-data", label: "Reference Data", children: [
     { id: "list-reference-data", label: "List & Create" },
@@ -252,13 +260,23 @@ var API_NAV_SECTIONS = [
     { id: "get-field", label: "Get Field" }
   ] },
   { id: "registry", label: "Registry", children: [
-    { id: "registry-query", label: "Query" }
+    { id: "registry-query", label: "Query" },
+    { id: "registry-health", label: "Health" }
+  ] },
+  { id: "customer-ontologies", label: "Customer Ontologies", children: [
+    { id: "customer-ontologies-overview", label: "Overview" },
+    { id: "import-customer-ontology", label: "Import" },
+    { id: "get-customer-ontology", label: "Get & Versions" },
+    { id: "publish-customer-ontology", label: "Update & Publish" },
+    { id: "customer-ontology-mappings", label: "Map to Talonic Types" }
   ] },
   { id: "data-products", label: "Data Products", children: [
     { id: "list-data-products", label: "List Data Products" },
+    { id: "create-data-product", label: "Create Data Product" },
     { id: "get-data-product", label: "Get Data Product" },
     { id: "delete-data-product", label: "Delete Data Product" },
     { id: "get-data-product-results", label: "Get Results" },
+    { id: "export-data-product", label: "Export Data Product" },
     { id: "data-product-share", label: "Data Product Share Link" }
   ] },
   { id: "data-policies", label: "Data Policies", children: [
@@ -281,12 +299,25 @@ var API_NAV_SECTIONS = [
   { id: "billing", label: "Billing", children: [
     { id: "billing-settings", label: "Settings" },
     { id: "billing-topup", label: "Auto Top-Up" },
+    { id: "billing-upgrade-link", label: "Upgrade Link" },
     { id: "cost-headers", label: "Cost Headers" }
   ] },
   { id: "usage", label: "Usage", children: [
     { id: "usage-overview", label: "Overview" },
     { id: "usage-credits", label: "Credit Usage" }
   ] },
+  { id: "account", label: "Account", children: [
+    { id: "get-account", label: "Account Snapshot" },
+    { id: "account-keys", label: "Manage API Keys" }
+  ] },
+  { id: "nodes", label: "Node Jobs", children: [
+    { id: "node-jobs", label: "Node Jobs" }
+  ] },
+  { id: "process", label: "Process", children: [
+    { id: "submit-process", label: "Submit for Processing" },
+    { id: "get-run", label: "Get Run" },
+    { id: "list-configs", label: "Processing Configs" }
+  ] },
   { id: "pricing", label: "Pricing", children: [
     { id: "pricing-overview", label: "Pricing Catalog" }
   ] },
@@ -314,7 +345,9 @@ var API_NAV_SECTIONS = [
     { id: "resolve-field-review", label: "Resolve Field Review" },
     { id: "bulk-resolve-field-reviews", label: "Bulk Resolve Field Reviews" },
     { id: "list-field-review-decisions", label: "Decision Log" },
-    { id: "export-field-review-decisions", label: "Export Decision Log" }
+    { id: "export-field-review-decisions", label: "Export Decision Log" },
+    { id: "field-review-triage", label: "Triage Breakdown" },
+    { id: "field-review-value-clusters", label: "Value Clusters" }
   ] },
   { id: "spec-config", label: "Spec Config", children: [
     { id: "get-spec-rail", label: "Get Rail" },
@@ -1135,6 +1168,11 @@ var sections2 = [
             name: "Delivery",
             type: "read",
             description: "Check delivery status and preview binding output."
+          },
+          {
+            name: "Spec Architect",
+            type: "read",
+            description: "Look up the Spec config catalog, estimate review volume before a Spec runs, and back-solve the review rate over a completed run."
           }
         ]
       },
@@ -1167,6 +1205,24 @@ var sections2 = [
         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}'
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "agent-spec-architect",
+        text: "Spec Architect"
+      },
+      {
+        type: "paragraph",
+        text: "When you ask the agent to help design or tune a Spec, it acts as a Spec Architect: it reasons over the real configuration catalog rather than from memory, and it can estimate how much human review a Spec will generate before you commit to it. This matters because the cost of a Spec is not just extraction \u2014 it is the number of cells a person has to review, and that is driven by which validation gates and triage thresholds you place in the rail. The agent grounds every suggestion in the actual primitives and their review-volume effect."
+      },
+      {
+        type: "paragraph",
+        text: "Review estimation comes in two touches. **Touch-0** (`estimate_review_volume`) is an instant, free, read-only heatmap of which fields are likely to need review, computed from data already captured at ingestion \u2014 it returns a qualitative per-field risk band (low / medium / high), not a percentage, and is the right tool for a Spec that has not run yet. **Touch-1** (`estimate_review_rate`) is the precise, warm estimate over a completed pipeline run: it replays the real triage decision over the run's real cells and validation verdicts, returns the actual review rate under a candidate triage config, plots the review-rate-vs-capacity tradeoff curve, and \u2014 given a target review rate \u2014 back-solves the capacity and risk cut that hit a sustainable review budget. Neither touch extracts or writes anything."
+      },
+      {
+        type: "paragraph",
+        text: 'These capabilities run inside the agent loop; there is no separate REST endpoint to call them directly. `GET /v1/agent/tools` lists the tools the agent can use, including the Spec Architect set, and you reach them by asking the agent in natural language \u2014 for example, "Estimate the review rate if I cap review capacity at three cells per document" or "Which fields will need the most review on this Spec before I run it?".'
       }
     ],
     related: [
@@ -2434,6 +2490,26 @@ var sections4 = [
         language: "bash",
         title: "Get registry aggregate stats",
         code: 'curl https://api.talonic.com/v1/schemas/stats \\\n  -H "Authorization: Bearer $TALONIC_API_KEY"'
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "registry-health-monitoring",
+        text: "Monitoring Registry Health"
+      },
+      {
+        type: "paragraph",
+        text: "A richer health snapshot is available over the public API at `GET /v1/registry/health`. It returns tier and admission counts, the singleton and weak-name rates, occurrence and recent-resolution stats, the deterministic transfer hit rate (the share of cells filled with no AI call), and coherence and atomicity metrics. This is the same view the in-app registry dashboard reads, and it is read-only: it exposes no lifecycle or cleanup actions. Teams poll it to track how the knowledge graph matures \u2014 a rising transfer hit rate means more extraction resolves for free, while a rising singleton or weak-name rate is an early signal that naming or clustering needs attention."
+      },
+      {
+        type: "heading",
+        level: 3,
+        id: "customer-ontology-overlay",
+        text: "The Customer Ontology Overlay"
+      },
+      {
+        type: "paragraph",
+        text: "The registry learns field names bottom-up from your documents, but you can also seed it top-down with a **customer ontology** \u2014 a versioned overlay of your own document types and field concepts that augments the built-in Talonic ontology. You author the doctypes and fields specific to your domain, anchor each doctype to a Talonic type, and publish. Publishing projects your authored fields into the registry as pinned canonical rows (protected from cleanup) and adds your custom doctypes to the classifier on a customer axis that runs alongside the always-on Talonic axis. The overlay is additive: an empty or unpublished ontology leaves capture and classification identical to the Talonic-only path, so adopting it never regresses existing extractions. The full lifecycle \u2014 create, import, update, publish, unpublish, delete, and embedding-assisted mapping to Talonic types \u2014 is available over the API under `/v1/customer-ontologies`."
       }
     ],
     related: [
@@ -6715,6 +6791,10 @@ curl -X POST https://api.talonic.com/v1/field-reviews/frev_001/override \\
         type: "paragraph",
         text: "The field-review queue is the human checkpoint in your pipeline. It ensures that fields a blocking checkpoint could not clear receive a person's decision before they flow downstream into the data product. Because routing is field-level, reviewers see only the specific fields that failed rather than whole records, which keeps the queue focused. The Decision log preserves the full history of who decided what, satisfying audit requirements without a separate tracking system."
       },
+      {
+        type: "paragraph",
+        text: "Two endpoints help a reviewer work the queue efficiently at scale. `GET /v1/field-reviews/triage` returns the queue's shape rather than its items \u2014 a classification-backed breakdown by reason, field, document, assignee, and tag, each group carrying a per-group reason mix \u2014 so a dashboard can show which fields are mostly safe to bulk-approve versus which need a careful look. `GET /v1/field-reviews/value-clusters` groups the held items by their current value: when a field is held across many documents with the same value, those items form one cluster you can review once and approve together with `POST /v1/field-reviews/bulk-resolve`. Together they turn a long flat queue into a prioritized, batch-resolvable worklist."
+      },
       {
         type: "callout",
         text: "The legacy `POST /v1/review/:id/approve` and `/reject` endpoints and the `result.approved` / `result.rejected` signal model are superseded. The central field-review queue uses `/v1/field-reviews` with approve / correct / override. If you must call the older review surface, the correct shape is `POST /v1/review/:id/action` with an `{ action }` body."
@@ -9796,6 +9876,10 @@ var sections17 = [
         type: "paragraph",
         text: "The engine runs four kinds of per-document phase in sequence. **Transfer** fills cells deterministically from the Field Registry, binding known values with no AI call. **Extraction** runs Claude over the gap fields that transfer could not fill. **Resolution** applies your Data Policies to normalize and transform values. **Validation** checks the document against the gates you placed in the rail. After every document is terminal, a pipeline-scoped **Assembly** step can compose grouped documents into a single record. Phases are strictly sequential per document: phase N+1 starts only once phase N completes."
       },
+      {
+        type: "paragraph",
+        text: "Resolution and Validation can also run **after** Assembly, not only per document. When a Data Policy or a validation checkpoint sits after the Assembly node in the rail, it becomes a pipeline-scoped phase that runs once over the composed record. A **post-assembly resolution** normalizes the assembled row and mirrors the resolved values back onto each anchor document, so the data product ships the resolved value rather than the raw composed one. A **post-assembly validation** gate then checks the full composed row. The two run in that order \u2014 resolution before validation \u2014 so a gate placed after Assembly sees resolved composed values. Both are best-effort tail steps and do not appear in the per-document progress phases."
+      },
       {
         type: "callout",
         variant: "info",
@@ -11443,7 +11527,7 @@ var sections20 = [
       },
       { type: "paragraph", text: "Most integrations call this endpoint after receiving an `extraction.complete` webhook or after polling a document's status until it reaches `completed`. A typical workflow is to extract a document via `POST /v1/extract`, store the returned `document.id`, then fetch full metadata here when needed." },
       { type: "paragraph", text: "The response includes the current `status` field which will be `completed` when extraction has finished, `processing` while in progress, or `error` if something went wrong. Use the `latest_extraction_id` to navigate directly to the extraction result via `GET /v1/extractions/:id`." },
-      { type: "paragraph", text: "Pair this with `GET /v1/documents/:id/markdown` to retrieve the raw OCR text, or with `GET /v1/extractions/:id/data` for just the structured field values. Note that the `triage` object is only populated after ingestion completes and may be `null` for documents still in processing." },
+      { type: "paragraph", text: "Pair this with `GET /v1/documents/:id/markdown` to retrieve the raw OCR text, or with `GET /v1/extractions/:id/data` for just the structured field values. To list every extraction a document has, call `GET /v1/documents/:id/extractions`. Note that the `triage` object is only populated after ingestion completes and may be `null` for documents still in processing." },
       { type: "callout", variant: "info", text: "The `links.dashboard` URL opens the document directly in the Talonic platform UI, which is useful for sharing with team members who need to review or correct extractions." },
       { type: "heading", level: 2, id: "get-document-errors", text: "Errors" },
       {
@@ -11609,6 +11693,245 @@ var sections20 = [
       { question: "How do I disable vision OCR during conversion?", answer: "Send a `vision` form field set to the string `false`. Scanned pages and images will then rely on the native text layer only, and the `vision_pages` array in the response will be empty." }
     ],
     mentions: ["convert", "markdown", "multipart upload", "vision OCR", "stateless conversion"]
+  },
+  {
+    slug: "get-document-fields",
+    parentSlug: "documents",
+    title: "Get Document Fields",
+    seoTitle: "Get Document Fields Endpoint \u2014 Talonic Docs",
+    description: "Return a document's captured fields bound into the field registry \u2014 one row per occurrence with its canonical concept, tier, value, and confidence.",
+    content: [
+      { type: "paragraph", text: "Returns the fields captured from a document and bound into the field registry. Where the extraction endpoints give you the raw field-name/value pairs a document produced, this endpoint gives you the registry-resolved view: each captured value is reported alongside the canonical concept it bound to, that concept's tier, and the confidence of the binding. It is the structured result most integrations actually want per document." },
+      { type: "paragraph", text: "Each row carries the occurrence value and confidence, the resolved registry field (its id, canonical name, display name, and data type), the registry tier (1 = canonical, 2 = provisional, 3 = candidate), and the semantic cluster the field belongs to when one is assigned. Rows are ordered by tier, so the most established concepts come first." },
+      { type: "callout", variant: "info", text: "A **linked duplicate** transparently returns the canonical document's fields. When a re-ingested file is byte-identical to one already in your workspace, it becomes a thin link to the canonical, and reads dereference to it \u2014 so you always see the captured data without re-extraction." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/documents/{id}/fields",
+        summary: "List a document's captured fields bound into the field registry.",
+        description: "Requires read scope. A linked duplicate returns the canonical document's fields.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Path parameters",
+            params: [
+              { name: "id", type: "string", required: true, description: "The document UUID." }
+            ]
+          }
+        ]
+      },
+      { type: "heading", level: 2, id: "get-document-fields-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response fields",
+        params: [
+          { name: "document_id", type: "string", description: "The document UUID the fields belong to." },
+          { name: "data[].field_id", type: "string", description: "Registry field UUID the value bound to." },
+          { name: "data[].canonical_name", type: "string", description: "Canonical name of the registry concept." },
+          { name: "data[].display_name", type: "string | null", description: "Human-readable display name, when set." },
+          { name: "data[].cluster_name", type: "string | null", description: "Semantic cluster the field belongs to, when assigned." },
+          { name: "data[].data_type", type: "string | null", description: "Declared data type of the concept." },
+          { name: "data[].tier", type: "integer", description: "Registry tier: 1 canonical, 2 provisional, 3 candidate." },
+          { name: "data[].value", type: "any", description: "The captured value for this occurrence." },
+          { name: "data[].confidence", type: "number | null", description: "Confidence of the binding (0\u20131)." }
+        ]
+      },
+      {
+        type: "code",
+        title: "curl",
+        language: "bash",
+        code: `curl -s https://api.talonic.ai/v1/documents/7f3a1b2c-0000-0000-0000-000000000000/fields \\
+  -H "Authorization: Bearer tlnc_your_api_key"`
+      },
+      {
+        type: "code",
+        title: "Response",
+        code: `{
+  "document_id": "7f3a1b2c-0000-0000-0000-000000000000",
+  "data": [
+    {
+      "field_id": "b2c3d4e5-0000-0000-0000-000000000000",
+      "canonical_name": "invoice_total",
+      "display_name": "Invoice Total",
+      "cluster_name": "amounts",
+      "data_type": "number",
+      "tier": 1,
+      "value": "490.00",
+      "confidence": 0.97
+    }
+  ]
+}`
+      }
+    ],
+    related: [
+      { label: "Get Document", slug: "get-document" },
+      { label: "Get Document Lineage", slug: "get-document-lineage" },
+      { label: "List Extractions", slug: "list-extractions" }
+    ],
+    faq: [
+      { question: "How is this different from the extraction data endpoint?", answer: "The extraction endpoints return the raw field-name/value pairs a document produced. This endpoint returns the registry-resolved view: each value reported with the canonical concept it bound to, that concept's tier, and the binding confidence." },
+      { question: "What does tier mean?", answer: "Tier is the registry maturity of the concept a value bound to: 1 is a canonical (proven) concept, 2 is provisional, 3 is a candidate. Rows are ordered by tier so the most established concepts appear first." },
+      { question: "Why does a duplicate document return fields it never extracted?", answer: "A byte-identical re-ingest becomes a thin link to the canonical document and reads its captured data through. The link carries no occurrences of its own, so this endpoint returns the canonical's fields." }
+    ],
+    mentions: ["field registry", "captured fields", "canonical concept", "tier", "linked duplicate"]
+  },
+  {
+    slug: "get-document-lineage",
+    parentSlug: "documents",
+    title: "Get Document Lineage",
+    seoTitle: "Get Document Lineage Endpoint \u2014 Talonic Docs",
+    description: "Return a document's downstream footprint: the pipelines that consumed it, the data products built from them, the field-registry concepts it contributed, and the cases it belongs to.",
+    content: [
+      { type: "paragraph", text: `Returns the document's lineage \u2014 its downstream footprint across the platform. This is the "used in" view: where a document ended up after ingestion, rather than what it contains. It answers questions like "which pipelines consumed this file?", "which data products ship its values?", and "which cases does it belong to?".` },
+      { type: "paragraph", text: "The response groups the footprint into sections: `pipelines` (the One Engine runs that included the document), `data_products` (datasets built from those pipelines), `field_registry` (the canonical concepts the document contributed, with per-tier counts and a sample), `cases`, and `business_cases`. Each entry carries a deep link to the corresponding public surface, so you can follow lineage outward without constructing URLs yourself." },
+      { type: "callout", variant: "info", text: "Pipeline, data-product, and case membership key on the document's own id; the field-registry section keys on the effective (canonical) id, so a linked duplicate reflects the concepts it reads through. This is the document passport \u2014 new platform surfaces that reference documents are added here over time." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/documents/{id}/lineage",
+        summary: "Get a document's downstream footprint across pipelines, data products, the registry, and cases.",
+        description: "Requires read scope.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Path parameters",
+            params: [
+              { name: "id", type: "string", required: true, description: "The document UUID." }
+            ]
+          }
+        ]
+      },
+      { type: "heading", level: 2, id: "get-document-lineage-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response fields",
+        params: [
+          { name: "document_id", type: "string", description: "The document UUID." },
+          { name: "pipelines[]", type: "object", description: "Pipelines that consumed the document (id, name, status, document_status, schema, links.self)." },
+          { name: "data_products[]", type: "object", description: "Data products built from those pipelines (id, name, status, links.self)." },
+          { name: "field_registry.total", type: "integer", description: "Distinct canonical concepts the document contributed." },
+          { name: "field_registry.by_tier", type: "object[]", description: "Per-tier concept counts." },
+          { name: "field_registry.sample", type: "object[]", description: "A capped sample of contributed concepts." },
+          { name: "cases[]", type: "object", description: "Cases the document belongs to (id, case_key, status, links.self)." },
+          { name: "business_cases[]", type: "object", description: "Business cases the document belongs to." }
+        ]
+      },
+      {
+        type: "code",
+        title: "curl",
+        language: "bash",
+        code: `curl -s https://api.talonic.ai/v1/documents/7f3a1b2c-0000-0000-0000-000000000000/lineage \\
+  -H "Authorization: Bearer tlnc_your_api_key"`
+      },
+      {
+        type: "code",
+        title: "Response",
+        code: `{
+  "document_id": "7f3a1b2c-0000-0000-0000-000000000000",
+  "pipelines": [
+    { "id": "c3d4e5f6-...", "name": "Delivery Notes", "status": "completed",
+      "document_status": "completed", "schema_id": "b2c3d4e5-...",
+      "schema_name": "Delivery Note", "links": { "self": "/v1/pipelines/c3d4e5f6-..." } }
+  ],
+  "data_products": [
+    { "id": "d4e5f6a7-...", "name": "Q2 Deliveries", "status": "active",
+      "links": { "self": "/v1/data-products/d4e5f6a7-..." } }
+  ],
+  "field_registry": {
+    "total": 18,
+    "by_tier": [ { "tier": 1, "count": 12 }, { "tier": 2, "count": 6 } ],
+    "sample": [ { "canonical_name": "invoice_total", "display_name": "Invoice Total", "tier": 1 } ],
+    "links": { "fields": "/v1/fields?document_id=7f3a1b2c-..." }
+  },
+  "cases": [],
+  "business_cases": []
+}`
+      }
+    ],
+    related: [
+      { label: "Get Document", slug: "get-document" },
+      { label: "Get Document Fields", slug: "get-document-fields" },
+      { label: "List Documents", slug: "list-documents" }
+    ],
+    faq: [
+      { question: "What is lineage useful for?", answer: "It shows a document's downstream footprint \u2014 which pipelines consumed it, which data products ship its values, which registry concepts it contributed, and which cases it belongs to. Use it to trace provenance outward from a single file." },
+      { question: "Does a duplicate document show the same lineage as its canonical?", answer: "Pipeline, data-product, and case membership key on the document's own id, so a duplicate shows where its own id was used. The field-registry section keys on the canonical id, so it reflects the concepts the duplicate reads through." }
+    ],
+    mentions: ["lineage", "document passport", "pipelines", "data products", "provenance"]
+  },
+  {
+    slug: "inject-customer-metadata",
+    parentSlug: "documents",
+    title: "Inject Metadata",
+    seoTitle: "Inject Customer Metadata Endpoint \u2014 Talonic Docs",
+    description: "Upload a CSV of customer-provided metadata and attach those values to matching documents by document_id or a custom reference column.",
+    content: [
+      { type: "paragraph", text: "Attach your own metadata to documents in bulk by uploading a CSV. Each row identifies a document and carries one or more metadata fields to write onto it. This is how you bring system-of-record identifiers and status flags \u2014 contract IDs, account numbers, lifecycle states \u2014 alongside the fields Talonic extracted, so downstream filtering, matching, and delivery can use them." },
+      { type: "paragraph", text: "By default the endpoint expects a comma-delimited UTF-8 CSV with a `document_id` column; every other non-empty column is written as injected metadata on the matching document. Point at a different layout with `reference_column` (the column used to identify the document), `field_columns` (an explicit comma-separated subset of columns to inject), `delimiter` (for example `\\t` for tab-separated), and `encoding`." },
+      { type: "paragraph", text: "The response summarizes the run: a `batch_id` for the injection, `rows_processed`, how many documents were `documents_matched` versus `documents_pending` (rows whose reference did not yet match a document), and the total `fields_written`. Rows that do not match are reported as pending rather than failing the whole upload." },
+      { type: "callout", variant: "info", text: "Identification is exact: `document_id` matches the document UUID. Use `reference_column` to match on a different column present in your CSV, paired with a reference the documents already carry. The upload accepts files up to 200 MB." },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/inject-customer-metadata",
+        summary: "Upload a CSV of metadata and attach it to matching documents.",
+        description: "Requires write scope. Multipart upload.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Multipart form fields",
+            params: [
+              { name: "file", type: "file", required: true, description: "CSV file containing document references and metadata values. Max 200 MB." },
+              { name: "reference_column", type: "string", description: "CSV column used to identify the document.", default: "document_id" },
+              { name: "field_columns", type: "string", description: "Comma-separated columns to inject. Defaults to all non-reference columns." },
+              { name: "delimiter", type: "string", description: "CSV delimiter. Use \\t for tab-delimited files.", default: "," },
+              { name: "encoding", type: "string", description: "Buffer encoding used to read the uploaded file.", default: "utf8" }
+            ]
+          }
+        ]
+      },
+      { type: "heading", level: 2, id: "inject-customer-metadata-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response fields",
+        params: [
+          { name: "batch_id", type: "string", description: "UUID identifying this injection run." },
+          { name: "rows_processed", type: "integer", description: "Number of CSV rows read." },
+          { name: "documents_matched", type: "integer", description: "Rows whose reference matched a document." },
+          { name: "documents_pending", type: "integer", description: "Rows whose reference did not match a document yet." },
+          { name: "fields_written", type: "integer", description: "Total metadata fields written across matched documents." }
+        ]
+      },
+      {
+        type: "code",
+        title: "curl",
+        language: "bash",
+        code: `curl -s -X POST https://api.talonic.ai/v1/inject-customer-metadata \\
+  -H "Authorization: Bearer tlnc_your_api_key" \\
+  -F "file=@contract-ids.csv"`
+      },
+      {
+        type: "code",
+        title: "Response",
+        code: `{
+  "batch_id": "b0c1d2e3-f4a5-6789-abcd-ef0123456789",
+  "rows_processed": 30,
+  "documents_matched": 30,
+  "documents_pending": 0,
+  "fields_written": 30
+}`
+      }
+    ],
+    related: [
+      { label: "List Documents", slug: "list-documents" },
+      { label: "Get Document Fields", slug: "get-document-fields" }
+    ],
+    faq: [
+      { question: "How are CSV rows matched to documents?", answer: "By default each row's document_id column is matched to a document UUID. Set reference_column to match on a different column in your CSV against a reference the documents already carry." },
+      { question: "What happens to rows that do not match a document?", answer: "They are counted as documents_pending in the response rather than failing the upload. The rest of the batch still applies." },
+      { question: "Which columns get written?", answer: "By default every non-empty column other than the reference column. Pass field_columns with a comma-separated list to inject only a specific subset." }
+    ],
+    mentions: ["metadata injection", "CSV upload", "document_id", "customer metadata", "bulk"]
   }
 ];
 
@@ -11997,6 +12320,44 @@ var sections21 = [
       { question: "What happens to the confidence score of a corrected field?", answer: "Corrected fields are automatically set to confidence 1.0 and added to the `locked_fields` array. The overall confidence score is recalculated to reflect the correction." }
     ],
     mentions: ["field corrections", "propagation", "locked fields", "confidence override"]
+  },
+  {
+    slug: "correct-extraction",
+    parentSlug: "extractions",
+    title: "Correct Extraction",
+    seoTitle: "Correct Extraction Endpoint \u2014 Talonic Docs",
+    description: "Override extracted field values on an extraction. Each corrected field is set to full confidence and locked.",
+    content: [
+      { type: "paragraph", text: "The correct endpoint overrides field values on an extraction. Pass a flat map of field name to corrected value; each field you set is written at confidence 1.0 and locked, so it is treated as ground truth and not re-derived. Use it to fix a misread value programmatically without re-running extraction." },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/extractions/:id/correct",
+        summary: "Override extracted field values (each set to confidence 1.0 and locked).",
+        description: "Requires write scope. Body is a flat map of field name to corrected value.",
+        blocks: [
+          { type: "param-table", title: "Path parameters", params: [{ name: "id", type: "string", required: true, description: "The extraction UUID." }] }
+        ]
+      },
+      {
+        type: "code",
+        title: "curl",
+        language: "bash",
+        code: `curl -s -X POST https://api.talonic.ai/v1/extractions/EXTRACTION_ID/correct \\
+  -H "Authorization: Bearer tlnc_your_api_key" \\
+  -H "Content-Type: application/json" \\
+  -d '{ "invoice_total": "1240.00" }'`
+      }
+    ],
+    related: [
+      { label: "Get Extraction", slug: "get-extraction" },
+      { label: "Get Extraction Data", slug: "get-extraction-fields" }
+    ],
+    faq: [
+      { question: "What happens to a corrected field?", answer: "It is written at confidence 1.0 and locked, so it is treated as ground truth and not overwritten by a later re-derivation." },
+      { question: "How is this different from PATCH /v1/extractions/{id}/data?", answer: "Both set field values. Correct is the explicit correction path that locks each field at full confidence; use it when you are asserting a known-good value." }
+    ],
+    mentions: ["correct extraction", "override", "locked", "confidence", "ground truth"]
   }
 ];
 
@@ -13413,6 +13774,55 @@ var sections24 = [
       { question: "What file formats are supported for document ingestion?", answer: "Talonic supports 25+ formats including PDF, DOCX, XLSX, CSV, PPTX, MSG, EML, PNG, JPG, HTML, XML, JSON, and more. See the supported file types documentation for the full list." }
     ],
     mentions: ["document ingestion", "batch processing", "duplicate detection", "file upload"]
+  },
+  {
+    slug: "ingest-source-document",
+    parentSlug: "sources",
+    title: "Ingest a Document",
+    seoTitle: "Ingest Source Document \u2014 Talonic Docs",
+    description: "Upload a single document into a source for extraction. Alias of POST /v1/sources/{id}/documents.",
+    content: [
+      { type: "paragraph", text: "The ingest endpoint uploads one document (up to 500 MB) into a source and queues it for extraction. It is an alias of POST /v1/sources/{id}/documents, provided as a clearer verb for one-off ingestion. Pass the file as multipart form data; optionally set processing_mode to batch for deferred, lower-cost extraction (otherwise realtime)." },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/sources/:id/ingest",
+        summary: "Upload a document into a source for extraction.",
+        description: "Requires the extract scope. Multipart upload.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Parameters",
+            params: [
+              { name: "id", type: "string", required: true, description: "The source id (path)." },
+              { name: "file", type: "file", required: true, description: "The document to ingest (multipart, max 500 MB)." },
+              { name: "processing_mode", type: "string", description: "batch or realtime. Batch defers extraction at lower cost." }
+            ]
+          }
+        ]
+      },
+      { type: "heading", level: 2, id: "ingest-source-document-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response fields",
+        params: [
+          { name: "document_id", type: "string", description: "The created document UUID." },
+          { name: "filename", type: "string", description: "The uploaded filename." },
+          { name: "status", type: "string", description: "queued." },
+          { name: "processing_mode", type: "string", description: "The mode the document will be processed in." },
+          { name: "source_id", type: "string", description: "The source it was ingested into." }
+        ]
+      }
+    ],
+    related: [
+      { label: "Source Documents", slug: "update-source" },
+      { label: "List Inputs", slug: "list-sources" }
+    ],
+    faq: [
+      { question: "How is ingest different from POST /v1/sources/{id}/documents?", answer: "They are the same operation. Ingest is an alias with a clearer verb for submitting a single document." },
+      { question: "What does batch processing_mode do?", answer: "It defers extraction through the provider batch APIs at roughly half the cost, delivered within 48 hours, instead of realtime processing." }
+    ],
+    mentions: ["ingest", "source", "upload", "processing mode", "batch"]
   }
 ];
 
@@ -13430,7 +13840,7 @@ var sections25 = [
       {
         type: "endpoint",
         method: "GET",
-        path: "/fields/autocomplete",
+        path: "/v1/search/autocomplete",
         summary: "Autocomplete field names from the registry.",
         description: "Returns matching fields ranked by relevance and occurrence count. Use this to power field picker UIs.",
         blocks: [
@@ -13511,7 +13921,7 @@ var sections25 = [
       {
         type: "endpoint",
         method: "GET",
-        path: "/fields/:fieldId/values",
+        path: "/v1/search/field-values",
         summary: "List distinct values for a field across documents.",
         description: "Returns value distribution with counts. Useful for building filter dropdowns and faceted search.",
         blocks: [
@@ -13519,6 +13929,7 @@ var sections25 = [
             type: "param-table",
             title: "Query parameters",
             params: [
+              { name: "field", type: "string", required: true, description: "The field registry UUID to read values for (resolve it via field autocomplete)." },
               { name: "sourceId", type: "string", description: "Scope to a specific source connection." },
               { name: "q", type: "string", description: "Filter values by substring match." },
               { name: "limit", type: "integer", default: "20", description: "Maximum number of values to return." }
@@ -13558,7 +13969,7 @@ var sections25 = [
           { name: "429", type: "rate_limited", description: "Too many requests. Retry after the period indicated in the Retry-After header." }
         ]
       },
-      { type: "paragraph", text: 'Pair this endpoint with the **field autocomplete** endpoint to build a two-step filter UI: first let the user select a field via `GET /fields/autocomplete`, then populate a dropdown with that field\'s distinct values from this endpoint. The `totalDistinct` count is useful for showing "N of M values" pagination hints.' }
+      { type: "paragraph", text: 'Pair this endpoint with the **field autocomplete** endpoint to build a two-step filter UI: first let the user select a field via `GET /v1/search/autocomplete`, then populate a dropdown with that field\'s distinct values from this endpoint. The `totalDistinct` count is useful for showing "N of M values" pagination hints.' }
     ],
     related: [
       { label: "Field Autocomplete", slug: "field-autocomplete" },
@@ -13661,7 +14072,7 @@ var sections25 = [
           { name: "429", type: "rate_limited", description: "Too many requests. Retry after the period indicated in the Retry-After header." }
         ]
       },
-      { type: "paragraph", text: "Build conditions programmatically by first calling `GET /fields/autocomplete` to resolve field IDs, then `GET /fields/:fieldId/values` to populate value pickers. The response includes the full `fieldValues` map per document, so you can render result tables without additional per-document fetches." }
+      { type: "paragraph", text: "Build conditions programmatically by first calling `GET /v1/search/autocomplete` to resolve field IDs, then `GET /v1/search/field-values` to populate value pickers. The response includes the full `fieldValues` map per document, so you can render result tables without additional per-document fetches." }
     ],
     related: [
       { label: "Field Autocomplete", slug: "field-autocomplete" },
@@ -13769,7 +14180,7 @@ var sections25 = [
       {
         type: "endpoint",
         method: "GET",
-        path: "/saved-filters",
+        path: "/v1/search/saved-filters",
         summary: "List saved filters.",
         description: "Returns all saved filter configurations, optionally scoped to a source.",
         blocks: [
@@ -13799,7 +14210,7 @@ var sections25 = [
       },
       {
         type: "code",
-        title: "Response (GET /saved-filters)",
+        title: "Response (GET /v1/search/saved-filters)",
         code: `{
   "data": [
     {
@@ -13819,7 +14230,7 @@ var sections25 = [
       {
         type: "endpoint",
         method: "POST",
-        path: "/saved-filters",
+        path: "/v1/search/saved-filters",
         summary: "Create a saved filter.",
         description: "Persist a filter configuration for reuse.",
         blocks: [
@@ -13995,6 +14406,58 @@ var sections25 = [
       { question: "Does the materialized index affect omnisearch results?", answer: "Yes. Omnisearch queries field values from the same materialized index. An out-of-date index may cause missing results in both filter and omnisearch endpoints." }
     ],
     mentions: ["materialized index", "filter performance"]
+  },
+  {
+    slug: "search-endpoints",
+    parentSlug: "filter-search",
+    title: "Search Endpoints",
+    seoTitle: "Search Endpoints \u2014 Talonic Docs",
+    description: "The search namespace: a filter alias, the omnisearch POST, and the materialize trigger that rebuilds the field-value index.",
+    content: [
+      { type: "paragraph", text: "The `/v1/search` namespace gathers the document filter, omnisearch, and the materialization trigger under one prefix. The filter route is an alias of the document filter, omnisearch runs a global search across documents, fields, sources, and schemas, and materialize rebuilds the field-value index that powers autocomplete and field-values." },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/search/filter",
+        summary: "Filter documents by field-value conditions (alias of POST /v1/documents/filter).",
+        description: "Requires read scope. Same body as /v1/documents/filter.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/search/omnisearch",
+        summary: "Global search across documents, fields, sources, and schemas.",
+        description: "Requires read scope. Body: query, limit.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Body parameters",
+            params: [
+              { name: "query", type: "string", description: "The search query." },
+              { name: "limit", type: "integer", description: "Maximum results." }
+            ]
+          }
+        ]
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/search/materialize",
+        summary: "Rebuild the field-value index used by autocomplete and field-values.",
+        description: "Requires write scope.",
+        blocks: []
+      }
+    ],
+    related: [
+      { label: "Field Autocomplete", slug: "field-autocomplete" },
+      { label: "Field Values", slug: "field-values" }
+    ],
+    faq: [
+      { question: "Is /v1/search/filter the same as /v1/documents/filter?", answer: "Yes \u2014 it is an alias with the same request body and response, grouped under the search namespace." },
+      { question: "When do I need to materialize?", answer: "The field-value index backs autocomplete and field-values. Trigger materialize to rebuild it after large ingestion if those reads look stale." }
+    ],
+    mentions: ["search", "omnisearch", "materialize", "filter alias", "field values"]
   }
 ];
 
@@ -14429,6 +14892,57 @@ echo -n '{"event":"extraction.complete","delivery_id":"dlv_test123","timestamp":
       { question: "Can I re-enable a deleted webhook?", answer: "No. Deletion is permanent. Create a new configuration with the same URL and settings if needed." }
     ],
     mentions: ["manage webhook", "update webhook", "delete webhook", "secret rotation"]
+  },
+  {
+    slug: "webhook-reference-endpoints",
+    parentSlug: "webhooks",
+    title: "Reference Endpoints",
+    seoTitle: "Webhook Reference Endpoints \u2014 Talonic Docs",
+    description: "Read the webhook event catalog, delivery payload format, signature scheme, and retry policy programmatically.",
+    content: [
+      { type: "paragraph", text: "The webhook event catalog, delivery format, signature scheme, and retry policy are all available as live read-only endpoints, so an integration can discover them at runtime instead of hard-coding them. Each returns the same reference information described in the sections above, as JSON." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/webhooks/events",
+        summary: "List the supported webhook event types.",
+        description: "Requires read scope. Returns { data: [{ event, description }] }.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/webhooks/delivery",
+        summary: "Get the delivery payload format (content type, method, headers, example).",
+        description: "Requires read scope.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/webhooks/signatures",
+        summary: "Get the HMAC-SHA256 signature verification reference.",
+        description: "Requires read scope.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/webhooks/retries",
+        summary: "Get the retry policy (max attempts, backoff schedule, timeout).",
+        description: "Requires read scope.",
+        blocks: []
+      }
+    ],
+    related: [
+      { label: "Events", slug: "webhook-events" },
+      { label: "Signature Verification", slug: "webhook-security" },
+      { label: "Retry Policy", slug: "webhook-retry" }
+    ],
+    faq: [
+      { question: "Why read these from an endpoint?", answer: "So your integration can discover the supported events, delivery format, signature scheme, and retry policy at runtime rather than hard-coding them, and stay current if they change." }
+    ],
+    mentions: ["webhook events", "delivery format", "signature", "retry policy", "reference"]
   }
 ];
 
@@ -17692,7 +18206,7 @@ var sections31 = [
     ],
     faq: [
       { question: "Can a single result appear multiple times in pending approvals?", answer: "Yes. If a result fails multiple checks, each failed check outcome appears as a separate item in the pending approvals list. Approving the result clears all pending items for that result." },
-      { question: "How do I clear the pending approvals queue?", answer: "Approve or reject each pending result via `POST /v1/structuring/approvals/{id}/approve` or `/reject`. Alternatively, configure `auto_approve_after_hours` on the gate to auto-clear items after a timeout." }
+      { question: "How do I clear the pending approvals queue?", answer: "Approve or reject each pending result via `POST /v1/structuring/approvals/{id}/approve` or `POST /v1/structuring/approvals/{id}/reject`. Alternatively, configure `auto_approve_after_hours` on the gate to auto-clear items after a timeout." }
     ],
     mentions: ["pending approvals", "approval queue", "manual review"]
   },
@@ -21974,6 +22488,73 @@ var sections37 = [
       { question: "Are all catalog entries available for use?", answer: "Most entries are live. Some deliverable types (case_snapshot, graph_relations) are registered as stubs with empty compatible_signals arrays \u2014 they appear in the catalog but cannot be used in bindings until their resolvers are implemented." }
     ],
     mentions: ["delivery catalog", "registry discovery", "compatibility"]
+  },
+  {
+    slug: "delivery-pending-events",
+    parentSlug: "delivery",
+    title: "Pending & Events",
+    seoTitle: "Delivery Pending & Events \u2014 Talonic Docs",
+    description: "Inspect and cancel pending (debounced) deliveries, and list and replay the raw delivery events that drive bindings.",
+    content: [
+      { type: "paragraph", text: "Two surfaces sit underneath the delivery items and dead-letter queue: the pending (debounced) deliveries that have not fired yet, and the raw delivery events that bindings consume. Use them to see what is queued to go out, cancel a debounced delivery before it fires, and replay an event through the binding pipeline." },
+      { type: "paragraph", text: "Pending deliveries are those still inside their debounce window. List them with the pending endpoint, drop a single queued job by id, or cancel all pending deliveries for one binding. Events are the upstream signals (a case resolved, a run completed) that matched a binding; list them and replay any one to re-run its delivery." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/delivery/pending",
+        summary: "List pending (debounced) deliveries that have not fired yet.",
+        description: "Requires read scope.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "DELETE",
+        path: "/v1/delivery/pending/:jobId",
+        summary: "Cancel a single pending delivery by job id.",
+        description: "Requires write scope.",
+        blocks: [
+          { type: "param-table", title: "Path parameters", params: [{ name: "jobId", type: "string", required: true, description: "The pending delivery job id." }] }
+        ]
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/delivery/bindings/:id/cancel-pending",
+        summary: "Cancel all pending deliveries for a binding.",
+        description: "Requires write scope.",
+        blocks: [
+          { type: "param-table", title: "Path parameters", params: [{ name: "id", type: "string", required: true, description: "The binding id." }] }
+        ]
+      },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/delivery/events",
+        summary: "List the raw delivery events that drive bindings.",
+        description: "Requires read scope.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/delivery/events/:id/replay",
+        summary: "Replay a delivery event through the binding pipeline.",
+        description: "Requires write scope.",
+        blocks: [
+          { type: "param-table", title: "Path parameters", params: [{ name: "id", type: "string", required: true, description: "The event id to replay." }] }
+        ]
+      }
+    ],
+    related: [
+      { label: "Dead Letter Queue", slug: "delivery-dlq" },
+      { label: "History", slug: "delivery-history" },
+      { label: "Manage Binding", slug: "manage-delivery-binding" }
+    ],
+    faq: [
+      { question: "What is a pending delivery?", answer: "A delivery still inside its debounce window that has not fired yet. You can cancel it by job id, or cancel all pending deliveries for a binding, before it goes out." },
+      { question: "How is replaying an event different from replaying an item?", answer: "Replaying an event re-runs it through binding matching and delivery from the source signal. Replaying a delivery item re-sends an already-produced delivery to its destination." }
+    ],
+    mentions: ["pending delivery", "debounce", "delivery events", "replay", "cancel"]
   }
 ];
 
@@ -22549,41 +23130,104 @@ var sections39 = [
     parentSlug: "cases",
     title: "Case Anomalies",
     seoTitle: "Case Anomalies Endpoint \u2014 Talonic Docs",
-    description: "List anomalies detected within a case with severity filtering and dismissed toggle. Dismiss individual anomalies after review.",
+    description: "Detector anomalies for a case \u2014 field conflicts, divergent shared keys, suspicious value reuse, missing-document-type signals \u2014 plus open dangling-reference findings and the matched workflow template.",
     content: [
-      { type: "paragraph", text: "Anomalies are open **findings** detected across the documents in a case. The primary finding kind is the **dangling reference** \u2014 a document points at an identifier (a contract number, a parent agreement) that resolves to no document in your workspace, signalling a likely missing document." },
-      { type: "paragraph", text: "Findings are produced by the case-synthesis rebuild and carry a kind, the field and value that raised them, a severity, and a dismissed flag. Dismissed findings stay dismissed across rebuilds." },
-      { type: "paragraph", text: "On the public API, findings surface through `GET /v1/cases/:key` as `anomaly_count` (the number of open, undismissed findings on the case) and through `GET /v1/cases/:key/completeness`, whose `missing` array lists each open finding with its `kind`, `via_field`, and `value`. Reviewing and dismissing individual findings is done in the platform \u2014 the Business Cases view \u2014 rather than through dedicated public endpoints." },
-      { type: "callout", variant: "info", text: "There are currently no public `/v1/cases/:key/anomalies` endpoints. Use `anomaly_count` on the case detail plus the `completeness` endpoint to monitor open findings programmatically, and the platform UI to curate them." },
-      { type: "heading", level: 2, id: "case-anomalies-monitoring", text: "Monitoring findings programmatically" },
+      { type: "paragraph", text: "The anomalies endpoint is the case **risk surface**. It runs the case's documents through the anomaly detectors and returns what looks wrong: `field_conflict` (the same key carries divergent values across documents), `duplicate_key_divergence`, `value_reuse_suspicious`, and `missing_document_type` (the matched workflow template expects a document type the case lacks). Each anomaly carries a type, severity, title, description, the `document_ids` involved, and `targets` \u2014 the (document, field, value) tuples so you can open the offending value directly." },
+      { type: "paragraph", text: "Alongside the detector anomalies, the response includes the case's open **findings** \u2014 the dangling references (a document points at an identifier that resolves to no document in your workspace, signalling a likely missing document) \u2014 and the matched workflow `template`. Anomalies are computed on-read from the case's live field occurrences: no AI call is made and nothing is persisted, so the result always reflects the current documents." },
+      { type: "callout", variant: "info", text: "Anomaly detection is bounded: for very large cases (more than ~120 documents) the detectors are skipped and only the open findings are returned, to keep the read fast." },
       {
-        type: "code",
-        title: "Open findings via the completeness endpoint",
-        code: `curl -s "$URL/v1/cases/5c7fa78c-4d92-4613-9f42-9fe74458d8a9/completeness" \\
-  -H "Authorization: Bearer $API_KEY"
-
-{
-  "case_id": "5c7fa78c-4d92-4613-9f42-9fe74458d8a9",
-  "document_count": 17,
-  "open_findings": 2,
-  "dismissed_findings": 1,
-  "completeness": 0.894,
-  "missing": [
-    { "kind": "dangling_reference", "via_field": "parent_agreement_ref", "value": "00129370" }
-  ]
-}`
-      }
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/cases/:key/anomalies",
+        summary: "Get the case risk surface: detector anomalies, open findings, and matched template.",
+        description: "Requires read scope. Keyed on the case UUID.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Path parameters",
+            params: [{ name: "key", type: "string", required: true, description: "Case UUID (the stable resource id)." }]
+          }
+        ]
+      },
+      { type: "heading", level: 2, id: "case-anomalies-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response fields",
+        params: [
+          { name: "data[].type", type: "string", description: "Anomaly type (field_conflict, duplicate_key_divergence, value_reuse_suspicious, missing_document_type)." },
+          { name: "data[].severity", type: "string", description: "critical | warning | info." },
+          { name: "data[].title", type: "string", description: "Short headline for the anomaly." },
+          { name: "data[].description", type: "string", description: "Human-readable explanation." },
+          { name: "data[].document_ids", type: "string[]", description: "Documents involved in the anomaly." },
+          { name: "data[].targets", type: "object[]", description: "Offending (document_id, field, value) tuples for direct navigation." },
+          { name: "findings", type: "object[]", description: "Open dangling-reference / missing-document findings (kind, via_field, value, severity)." },
+          { name: "template", type: "object | null", description: "Matched workflow template (name, required_types, optional_types) or null." }
+        ]
+      },
+      { type: "paragraph", text: "Two complementary signals also live on the case: `anomaly_count` on `GET /v1/cases/:key` (the number of open findings) and `GET /v1/cases/:key/completeness` (members \xF7 members + open findings). Use those for a cheap health number, and this endpoint when you need the detailed anomaly list." }
     ],
     related: [
+      { label: "Case Evidence", slug: "case-evidence" },
       { label: "Get Case", slug: "get-case" },
       { label: "Case Operations", slug: "case-operations" }
     ],
     faq: [
-      { question: "What kinds of findings are detected?", answer: "The primary kind is the dangling reference: a reference-typed field whose value resolves to no document in the workspace \u2014 evidence of a likely missing document. Each finding carries the field and value that raised it." },
-      { question: "Can I dismiss a finding via the API?", answer: "Not on the public API today. Dismissal is done in the platform (Business Cases view); a dismissed finding stays dismissed across rebuilds and stops counting toward anomaly_count." },
-      { question: "How do findings relate to completeness?", answer: "The completeness score is members / (members + open findings) \u2014 each open finding lowers it. A case with no open findings reads 1.0." }
+      { question: "What kinds of anomalies are detected?", answer: "Field conflicts (divergent values for a shared key), duplicate-key divergence, suspicious value reuse, and missing document types relative to the matched workflow template. Open dangling-reference findings (likely missing documents) are returned alongside them." },
+      { question: "Does this endpoint cost an AI call?", answer: "No. Anomalies are computed on-read from the case's field occurrences with deterministic detectors. Nothing is persisted and no LLM is invoked." },
+      { question: "Can I dismiss a finding via the API?", answer: "Not on the public API today. Dismissal is done in the platform (Business Cases view); a dismissed finding stays dismissed across rebuilds and stops counting toward anomaly_count." }
+    ],
+    mentions: ["anomalies", "findings", "risk", "dangling reference", "field conflict"]
+  },
+  {
+    slug: "case-evidence",
+    parentSlug: "cases",
+    title: "Case Evidence",
+    seoTitle: "Case Evidence Endpoint \u2014 Talonic Docs",
+    description: "The connective evidence for a case: the shared-reference links that join its documents, the open gaps (dangling references / missing documents), and its member documents.",
+    content: [
+      { type: "paragraph", text: 'The evidence endpoint answers "why are these documents one case, and what is missing?". It returns the `connections` \u2014 the shared-reference links that join pairs of documents, each carrying the `via_field` and `value` that connect them, the link `kind`, a `confidence`, and any curator `verdict` (confirmed/rejected) \u2014 together with the open `gaps` (dangling references and missing-document findings) and the member `documents`.' },
+      { type: "paragraph", text: "This is the synth case's evidence model: a case is a connected component over reference edges, so the connections ARE the evidence. Where `GET /v1/cases/:key/edges` is the raw edge list used to confirm or reject links, this endpoint is the read-oriented evidence view \u2014 connections plus the gaps that show what the case is still waiting on." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/cases/:key/evidence",
+        summary: "Get the case connective evidence: connections, gaps, and documents.",
+        description: "Requires read scope. Keyed on the case UUID.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Path parameters",
+            params: [{ name: "key", type: "string", required: true, description: "Case UUID (the stable resource id)." }]
+          }
+        ]
+      },
+      { type: "heading", level: 2, id: "case-evidence-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response fields",
+        params: [
+          { name: "connections[].document_a", type: "string", description: "One side of the link." },
+          { name: "connections[].document_b", type: "string | null", description: "The other side (null for a single-document anchor)." },
+          { name: "connections[].via_field", type: "string", description: "The field whose value joins the two documents." },
+          { name: "connections[].value", type: "string", description: "The shared value." },
+          { name: "connections[].kind", type: "string", description: "Link kind (e.g. reference, value-sibling, citation)." },
+          { name: "connections[].confidence", type: "number | null", description: "Link confidence." },
+          { name: "connections[].verdict", type: "string | null", description: "Curator verdict (confirmed / rejected) if set." },
+          { name: "gaps", type: "object[]", description: "Open findings (dangling references / missing documents)." },
+          { name: "documents", type: "object[]", description: "Member documents with filename, type, and date." }
+        ]
+      }
+    ],
+    related: [
+      { label: "Case Anomalies", slug: "case-anomalies" },
+      { label: "Case Edges", slug: "case-edges" },
+      { label: "Get Case", slug: "get-case" }
+    ],
+    faq: [
+      { question: "How is evidence different from edges?", answer: "Edges (GET /v1/cases/:key/edges) is the raw link list, used as the target for confirm/reject. Evidence is the read-oriented view: the same connections enriched with the joining field and value, plus the open gaps and the member documents." },
+      { question: "What are gaps?", answer: "Open findings on the case \u2014 primarily dangling references, where a document points at an identifier that resolves to no document in your workspace, indicating a likely missing document." }
     ],
-    mentions: ["anomalies", "findings", "dangling reference", "completeness"]
+    mentions: ["evidence", "connections", "links", "gaps", "shared reference"]
   },
   {
     slug: "case-operations",
@@ -23700,7 +24344,7 @@ var sections41 = [
     description: "Create a new ground truth dataset linked to a schema. The dataset defines the expected extraction output used for accuracy benchmarking.",
     content: [
       { type: "paragraph", text: "Create an empty ground truth dataset that you can populate with verified entries. Datasets serve as the baseline for benchmark runs that measure extraction accuracy. After creating a dataset, add entries individually or import them in bulk via CSV." },
-      { type: "paragraph", text: "The typical workflow is: create the dataset, then populate it using `POST /v1/quality/ground-truth/:id/entries` for individual entries or `POST /v1/quality/ground-truth/:id/entries/import-csv` for bulk import. Once populated, create a benchmark run with `POST /v1/quality/benchmarks`." },
+      { type: "paragraph", text: "The typical workflow is: create the dataset, then populate it using `POST /v1/quality/ground-truth/:id/entries` for each entry. Once populated, create a benchmark run with `POST /v1/quality/benchmarks`." },
       { type: "paragraph", text: "The response returns the dataset with `document_count: 0` since it is initially empty. `user_schema_id` echoes the `schema_id` you passed in. The `links.self` URL points to the detail endpoint where you can retrieve entries or delete the dataset." },
       { type: "paragraph", text: "For best results, aim for at least 30-50 entries per dataset. The `schema_id` scoping ensures ground truth field names align with your extraction schema, producing more meaningful benchmark comparisons." },
       { type: "callout", variant: "info", text: "Field keys in `expected_data` entries should match the field names used in your extraction schema. Unmatched fields are stored but ignored during benchmark comparison." },
@@ -23967,37 +24611,6 @@ var sections41 = [
   "created_at": "2024-09-05T12:00:00.000Z"
 }`
       },
-      { type: "paragraph", text: "For bulk entry creation, use the CSV import endpoint. The CSV must have `document_id` as the first column, with remaining columns matching your schema field names." },
-      {
-        type: "endpoint",
-        method: "POST",
-        path: "/v1/quality/ground-truth/:datasetId/entries/import-csv",
-        summary: "Import entries from a CSV file.",
-        description: "Upload a CSV where each row is an entry and columns map to schema fields. The first column must be `document_id`.",
-        blocks: [
-          {
-            type: "param-table",
-            title: "Form data parameters",
-            params: [
-              { name: "file", type: "binary", required: true, description: "CSV file with ground truth values." }
-            ]
-          }
-        ]
-      },
-      { type: "heading", level: 2, id: "quality-entries-import-response", text: "Response (CSV import)" },
-      {
-        type: "param-table",
-        title: "Response fields",
-        params: [
-          { name: "imported", type: "integer", description: "Number of entries successfully imported." },
-          { name: "skipped", type: "integer", description: "Number of rows skipped (e.g. missing document_id or duplicate)." }
-        ]
-      },
-      {
-        type: "code",
-        title: "Response (CSV import)",
-        code: `{ "imported": 25, "skipped": 2 }`
-      },
       {
         type: "endpoint",
         method: "DELETE",
@@ -24475,7 +25088,7 @@ var sections42 = [
     ],
     related: [
       { label: "Create Routing Rule", slug: "create-routing-rule" },
-      { label: "Reorder Rules", slug: "reorder-routing-rules" }
+      { label: "Manage Routing Rule", slug: "manage-routing-rule" }
     ],
     faq: [
       { question: "How are routing rules evaluated?", answer: "Rules are evaluated in priority order (lowest number first). The first rule whose conditions match the incoming document is applied." },
@@ -24493,7 +25106,7 @@ var sections42 = [
     content: [
       { type: "paragraph", text: 'Create a rule that automatically applies actions to incoming documents based on their metadata. Conditions define what to match (e.g. document type equals "invoice"), and actions define what to do (e.g. assign the finance schema). Rules are evaluated on every `document_classified` event.' },
       { type: "paragraph", text: 'The typical workflow is: create rules ordered by specificity \u2014 put narrow, high-priority rules first (e.g. "contracts from vendor X") and broader catch-all rules last. New rules are active immediately upon creation, so the next classified document will be evaluated against them.' },
-      { type: "paragraph", text: "The response returns the rule with `is_active: true`, a `trigger_type` of `document_classified`, and the assigned `priority` (defaults to 100 if omitted). The `action_type` is resolved from the `actions` object. Use the reorder endpoint after creation to adjust the priority relative to existing rules." },
+      { type: "paragraph", text: "The response returns the rule with `is_active: true`, a `trigger_type` of `document_classified`, and the assigned `priority` (defaults to 100 if omitted). The `action_type` is resolved from the `actions` object. Adjust the priority of a rule relative to others with `PATCH /v1/routing-rules/{id}`." },
       { type: "paragraph", text: "Pair with `GET /v1/routing-rules` to verify the full priority chain after creating a rule. Use `source_connection_id` to scope rules to documents from a specific source \u2014 documents from other sources will skip the rule entirely. To test a rule before going live, create it and immediately disable it via `PATCH` with `is_active: false`." },
       { type: "callout", variant: "info", text: "New rules are created with `is_active: true` by default. If you want to test a rule before activating it, create it, then immediately disable it via `PATCH /v1/routing-rules/:id` with `is_active: false`." },
       {
@@ -24585,7 +25198,7 @@ var sections42 = [
     faq: [
       { question: "What condition fields are available?", answer: "Conditions can match on `document_type`, `source`, `language`, `sensitivity`, and other document metadata fields." },
       { question: "Can a rule have multiple actions?", answer: "Yes. Actions are executed in order. Common combinations include assigning a schema and triggering a job." },
-      { question: "What is the default priority?", answer: "If you omit the priority field, it defaults to 100. Use the reorder endpoint to adjust priorities after creation." }
+      { question: "What is the default priority?", answer: "If you omit the priority field, it defaults to 100. Adjust priorities after creation with PATCH on each rule." }
     ],
     mentions: ["create rule", "conditions", "actions", "assign_schema", "trigger_job", "route_to"]
   },
@@ -24599,7 +25212,7 @@ var sections42 = [
       { type: "paragraph", text: "Retrieve, update, or delete a single routing rule. Updates take effect immediately \u2014 the next `document_classified` event will use the updated rule. Deleting a rule does not retroactively affect documents that were already routed by it." },
       { type: "paragraph", text: "Use `GET` to inspect a rule's conditions, actions, and priority. Use `PATCH` to adjust conditions, change the schema assignment, toggle `is_active`, or update the priority. Use `DELETE` when a rule is no longer needed \u2014 previously routed documents are not affected." },
       { type: "paragraph", text: "The `PATCH` response returns the full updated rule including the new `updated_at` timestamp. All fields are optional \u2014 only include fields you want to change. The `is_active` toggle lets you temporarily disable a rule without deleting it, which is useful for testing or during maintenance windows." },
-      { type: "paragraph", text: "After updating priority via `PATCH`, use `GET /v1/routing-rules` to verify the full evaluation order. For bulk priority changes, prefer the `POST /v1/routing-rules/reorder` endpoint instead of patching individual rules. Pair deletion with rule creation to replace a rule atomically." },
+      { type: "paragraph", text: "After updating priority via `PATCH`, use `GET /v1/routing-rules` to verify the full evaluation order. Apply priority changes by patching the `priority` on each rule. Pair deletion with rule creation to replace a rule atomically." },
       { type: "callout", variant: "info", text: "Rule changes only affect future `document_classified` events. Documents already routed by a previous version of the rule retain their assigned schema and routing actions." },
       {
         type: "endpoint",
@@ -24766,81 +25379,13 @@ var sections42 = [
     ],
     related: [
       { label: "List Routing Rules", slug: "list-routing-rules" },
-      { label: "Reorder Rules", slug: "reorder-routing-rules" }
+      { label: "Create Routing Rule", slug: "create-routing-rule" }
     ],
     faq: [
       { question: "Do updates affect already-routed documents?", answer: "No. Rule changes only affect future document_classified events. Documents that were already routed by the previous version of the rule are not retroactively updated." },
       { question: "Can I temporarily disable a rule without deleting it?", answer: "Yes. Use PATCH with is_active: false to disable the rule. It will be skipped during evaluation but retained for future re-activation." }
     ],
     mentions: ["update rule", "delete rule", "manage routing"]
-  },
-  {
-    slug: "reorder-routing-rules",
-    parentSlug: "routing-rules",
-    title: "Reorder Routing Rules",
-    seoTitle: "Reorder Routing Rules Endpoint \u2014 Talonic Docs",
-    description: "Reorder routing rules by providing an ordered array of rule IDs. Priority values are reassigned sequentially based on the new order.",
-    content: [
-      { type: "paragraph", text: "Reassign priority values for all routing rules at once. Pass an ordered array of rule IDs \u2014 the first ID receives priority 1, the second receives priority 2, and so on. This is the recommended way to change evaluation order after initial creation." },
-      { type: "paragraph", text: "Use this endpoint when you need to rearrange the evaluation order of multiple rules at once \u2014 for example, when promoting a new rule to the top of the chain or inserting a rule between two existing ones. This is more reliable than patching individual rule priorities, which can create gaps or collisions." },
-      { type: "paragraph", text: "The response returns a `reordered` array with each rule's `id` and new `priority` value. Priority 1 is evaluated first. The reorder takes effect immediately \u2014 the next `document_classified` event uses the new priority sequence." },
-      { type: "paragraph", text: "List all rules first via `GET /v1/routing-rules` to get the current IDs and order, then construct the reordered array. Include both active and inactive rules in the array to maintain a consistent priority sequence. Omitting any rule ID results in a validation error." },
-      { type: "callout", variant: "warning", text: "All active rule IDs must be included in the `rule_ids` array. Omitting any rule returns a validation error. Inactive rules should also be included to maintain a consistent priority sequence." },
-      {
-        type: "endpoint",
-        method: "POST",
-        path: "/v1/routing-rules/reorder",
-        summary: "Reorder rules by priority.",
-        blocks: [
-          {
-            type: "param-table",
-            title: "Body parameters",
-            params: [
-              { name: "rule_ids", type: "string[]", required: true, description: "Ordered array of rule IDs. First ID gets priority 1, second gets priority 2, and so on." }
-            ]
-          }
-        ]
-      },
-      { type: "heading", level: 2, id: "reorder-routing-rules-response", text: "Response" },
-      {
-        type: "param-table",
-        title: "Response fields",
-        params: [
-          { name: "reordered", type: "array", description: "Array of rules with their updated priority values." },
-          { name: "reordered[].id", type: "string", description: "Routing rule UUID." },
-          { name: "reordered[].priority", type: "integer", description: "New priority assigned to this rule." }
-        ]
-      },
-      {
-        type: "code",
-        title: "Response",
-        code: `{
-  "reordered": [
-    { "id": "c3d4e5f6-a7b8-9012-cdef-123456789012", "priority": 1 },
-    { "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "priority": 2 },
-    { "id": "b2c3d4e5-f6a7-8901-bcde-f12345678901", "priority": 3 }
-  ]
-}`
-      },
-      { type: "heading", level: 2, id: "reorder-routing-rules-errors", text: "Errors" },
-      {
-        type: "param-table",
-        title: "Error responses",
-        params: [
-          { name: "401", type: "unauthorized", description: "Missing or invalid API key." },
-          { name: "429", type: "rate_limited", description: "Too many requests. Retry after the period indicated in the Retry-After header." }
-        ]
-      }
-    ],
-    related: [
-      { label: "List Routing Rules", slug: "list-routing-rules" },
-      { label: "Manage Routing Rule", slug: "manage-routing-rule" }
-    ],
-    faq: [
-      { question: "Do I need to include all rule IDs?", answer: "Yes. All active rule IDs must be included in the array. Omitting a rule ID will result in an error." },
-      { question: "Does reordering affect currently processing documents?", answer: "No. Reordering only affects future document_classified events. Documents currently being processed continue with their already-matched rule." }
-    ],
-    mentions: ["reorder", "priority", "rule ordering"]
   }
 ];
 
@@ -25140,6 +25685,43 @@ X-Talonic-Cells-Resolved-AI: 1`
       }
     ],
     mentions: ["cost headers", "X-Talonic-Cost", "credits", "balance", "cells resolved"]
+  },
+  {
+    slug: "billing-upgrade-link",
+    parentSlug: "billing",
+    title: "Upgrade Link",
+    seoTitle: "Billing Upgrade Link \u2014 Talonic Docs",
+    description: "Get the URL an agent hands to a human to upgrade the plan or add a payment method.",
+    content: [
+      { type: "paragraph", text: "The upgrade-link endpoint returns a URL an AI agent can hand to a human to upgrade the workspace or add a payment method. Plan changes and payment are deliberately a human-in-the-loop step, so this endpoint never charges anything: it returns a deep link into the dashboard plus a flag indicating a human is required." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/billing/upgrade-link",
+        summary: "Get the dashboard upgrade / add-payment link.",
+        description: "Requires read scope.",
+        blocks: []
+      },
+      { type: "heading", level: 2, id: "billing-upgrade-link-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response fields",
+        params: [
+          { name: "url", type: "string", description: "The dashboard deep link to upgrade or add payment." },
+          { name: "provider", type: "string", description: "The link provider (dashboard)." },
+          { name: "requires_human", type: "boolean", description: "Always true \u2014 a person must complete the upgrade." },
+          { name: "message", type: "string", description: "A human-readable instruction." }
+        ]
+      }
+    ],
+    related: [
+      { label: "Billing Settings", slug: "billing-settings" },
+      { label: "Account Snapshot", slug: "get-account" }
+    ],
+    faq: [
+      { question: "Does this endpoint charge anything?", answer: "No. It only returns a link a human follows to upgrade or add payment. Plan changes are human-in-the-loop by design." }
+    ],
+    mentions: ["upgrade link", "billing", "payment", "human-in-the-loop"]
   }
 ];
 
@@ -25277,11 +25859,659 @@ var sections44 = [
       "zero re-extraction",
       "resolved_document_values"
     ]
+  },
+  {
+    slug: "registry-health",
+    parentSlug: "registry",
+    title: "Registry Health",
+    seoTitle: "Field Registry Health \u2014 Talonic Docs",
+    description: "Read-only health snapshot of your field registry: tier and admission counts, singleton and weak-name rates, occurrence and resolution stats, transfer hit rate, and coherence/atomicity metrics.",
+    content: [
+      { type: "paragraph", text: "The registry health endpoint returns a read-only snapshot of your workspace's field registry \u2014 the same view the in-app registry dashboard reads. It is how you monitor the health of the deduplicated knowledge graph that extraction builds over time: how many canonical concepts exist, how many fields are still provisional, how often deterministic transfer fills cells without an AI call, and where naming or coherence is degrading. No lifecycle or cleanup actions are exposed; this is a metrics read only." },
+      { type: "paragraph", text: "The response is grouped into sections. `registry` carries tier counts (tier 1 canonical, tier 2 provisional, tier 3 candidate), admission counts, and the singleton rate. `occurrences` and `resolution_last_24h` track how values bind into the graph. `transfer` reports the deterministic transfer hit rate (the share of cells filled with no AI call). `name_quality`, `coherence`, and `atomicity` surface quality signals \u2014 weak names, incoherent canonicals, non-atomic values \u2014 and `junk_classes` flags clusters that look like noise." },
+      { type: "callout", variant: "info", text: "Use this to track registry health as your corpus grows. A rising transfer hit rate means more cells resolve for free; a rising singleton or weak-name rate is an early signal that naming or clustering needs attention." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/registry/health",
+        summary: "Read a health snapshot of the field registry.",
+        description: "Requires read scope. Read-only \u2014 no lifecycle or cleanup actions.",
+        blocks: []
+      },
+      { type: "heading", level: 2, id: "registry-health-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response sections",
+        params: [
+          { name: "registry", type: "object", description: "total_fields, tier_1/2/3, singleton_count, singleton_rate, admission_canonical, admission_provisional, admission_provisional_rate." },
+          { name: "embeddings", type: "object", description: "provisional_backlog and oldest_provisional_minutes." },
+          { name: "occurrences", type: "object", description: "total, unresolved, needs_confirmation." },
+          { name: "resolution_last_24h", type: "object", description: "total resolutions in the last 24h and their confidence-band breakdown." },
+          { name: "convergence", type: "object", description: "convergence_rate and confirm_rate (nullable)." },
+          { name: "name_quality", type: "object", description: "weak_name_count and weak_name_rate." },
+          { name: "coherence", type: "object", description: "multi_occ_fields, incoherent_canonical_count, incoherent_rate." },
+          { name: "transfer", type: "object", description: "transfer_cells, extraction_cells, transfer_hit_rate." },
+          { name: "atomicity", type: "object", description: "total_values, non_atomic_count, non_atomic_rate." },
+          { name: "junk_classes", type: "object", description: "Counts of clusters flagged as likely noise." }
+        ]
+      },
+      {
+        type: "code",
+        title: "curl",
+        language: "bash",
+        code: `curl -s https://api.talonic.ai/v1/registry/health \\
+  -H "Authorization: Bearer tlnc_your_api_key"`
+      },
+      {
+        type: "code",
+        title: "Response (truncated)",
+        code: `{
+  "registry": {
+    "total_fields": 8174,
+    "tier_1": 162,
+    "tier_2": 724,
+    "tier_3": 7288,
+    "singleton_count": 6099,
+    "singleton_rate": 0.746,
+    "admission_canonical": 6449,
+    "admission_provisional": 1725,
+    "admission_provisional_rate": 0.211
+  },
+  "transfer": { "transfer_cells": 12044, "extraction_cells": 5310, "transfer_hit_rate": 0.69 },
+  "name_quality": { "weak_name_count": 88, "weak_name_rate": 0.011 },
+  "coherence": { "multi_occ_fields": 2075, "incoherent_canonical_count": 12, "incoherent_rate": 0.006 }
+}`
+      }
+    ],
+    related: [
+      { label: "Query the Registry", slug: "registry-query" },
+      { label: "Field Registry", slug: "list-fields" }
+    ],
+    faq: [
+      { question: "Does this endpoint change anything?", answer: "No. It is read-only \u2014 a metrics snapshot. Lifecycle, promotion, and cleanup actions are not exposed on the public API." },
+      { question: "What is the transfer hit rate?", answer: "The share of cells filled deterministically from the registry with no AI call. A higher rate means more of your extraction resolves for free as the registry grows." },
+      { question: "What do the tiers mean?", answer: "Tier 1 is canonical (proven) concepts, tier 2 provisional, tier 3 candidate. The mix tells you how much of the registry is established versus still being learned." }
+    ],
+    mentions: ["registry health", "field registry", "tiers", "transfer hit rate", "coherence"]
   }
 ];
 
-// src/content/api/reference-data.ts
+// src/content/api/customer-ontologies.ts
 var sections45 = [
+  {
+    slug: "customer-ontologies-overview",
+    parentSlug: "customer-ontologies",
+    title: "Customer Ontologies",
+    seoTitle: "Customer Ontologies \u2014 Overlay API \u2014 Talonic Docs",
+    description: "A versioned overlay of your own document types and field concepts that augments the built-in Talonic ontology. List and create ontologies, then author, publish, and project them.",
+    content: [
+      { type: "paragraph", text: 'A customer ontology is your own overlay on top of the built-in Talonic ontology: a versioned container of custom document types and field concepts specific to your domain. You define the doctypes you care about (a "Lieferschein", a "Rahmenvertrag") and the fields that matter on them, anchor each doctype to a Talonic type, and publish. Publishing projects your authored fields and doctypes into the field registry and the classifier, so extraction and classification start recognizing your vocabulary.' },
+      { type: "paragraph", text: "Ontologies are versioned with a draft/publish lifecycle. Editing a published ontology auto-forks a new draft, so the published overlay your pipelines read never changes underneath them mid-run. The overlay is additive: an empty or unpublished ontology leaves capture and classification byte-identical to the Talonic-only path, so adopting ontologies never regresses existing behavior." },
+      { type: "callout", variant: "info", text: "Publishing is a write operation with side effects: it pins fields into your registry (protected from cleanup) and adds custom doctypes the classifier will assign. Unpublishing or deleting reverses the projection." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/customer-ontologies",
+        summary: "List your ontologies with their latest version status.",
+        description: "Requires read scope.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/customer-ontologies",
+        summary: "Create an ontology and its empty draft v1.",
+        description: "Requires write scope.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Body parameters",
+            params: [
+              { name: "name", type: "string", required: true, description: "A name for the ontology." },
+              { name: "description", type: "string", description: "Optional description." }
+            ]
+          }
+        ]
+      },
+      {
+        type: "code",
+        title: "curl",
+        language: "bash",
+        code: `curl -s -X POST https://api.talonic.ai/v1/customer-ontologies \\
+  -H "Authorization: Bearer tlnc_your_api_key" \\
+  -H "Content-Type: application/json" \\
+  -d '{"name":"Logistics","description":"Delivery + freight doctypes"}'`
+      }
+    ],
+    related: [
+      { label: "Import an Ontology", slug: "import-customer-ontology" },
+      { label: "Map to Talonic Types", slug: "customer-ontology-mappings" }
+    ],
+    faq: [
+      { question: "What does an ontology change?", answer: "Once published, your custom doctypes are assigned by the classifier (a customer axis alongside the always-on Talonic axis) and your authored fields are pinned into the registry so extraction targets them. Unpublished ontologies change nothing." },
+      { question: "Is the overlay additive?", answer: "Yes. An empty or unpublished overlay leaves capture and classification identical to the Talonic-only path, so adopting ontologies never regresses existing extractions." }
+    ],
+    mentions: ["customer ontology", "overlay", "doctypes", "field concepts", "classification"]
+  },
+  {
+    slug: "import-customer-ontology",
+    parentSlug: "customer-ontologies",
+    title: "Import an Ontology",
+    seoTitle: "Import Customer Ontology \u2014 Talonic Docs",
+    description: "Top-down import of a complete ontology \u2014 doctypes and fields in one call, optionally published immediately. Blank doctype anchors are auto-mapped to Talonic types.",
+    content: [
+      { type: "paragraph", text: "Import is the fast path for standing up an ontology from a definition you already have. You post the whole thing \u2014 name, doctypes, and fields \u2014 in one call, and optionally publish it immediately with `publish: true`. Any doctype you leave without a `maps_to` anchor is auto-mapped to the best-matching Talonic type by embedding similarity before it is saved, so you do not have to hand-anchor every doctype." },
+      { type: "paragraph", text: "Each doctype carries a `key`, a `name`, an optional `category`, classification `signals`, and the `maps_to` Talonic anchor. Each field carries a `key` plus optional `canonical_name`, `display_name`, `data_type`, `synonyms`, a `doctype_scope` (a doctype key, or null/empty/* for a global field), `required`, `format`, `enum_values`, and `examples`." },
+      { type: "callout", variant: "info", text: "Auto-mapping is advisory and never overwrites a maps_to you supplied. A doctype whose top match is ambiguous is left blank for you to resolve with the suggest-mappings endpoint." },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/customer-ontologies/import",
+        summary: "Create or replace the draft from a full definition, optionally publishing.",
+        description: "Requires write scope.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Body parameters",
+            params: [
+              { name: "name", type: "string", required: true, description: "Ontology name." },
+              { name: "description", type: "string", description: "Optional description." },
+              { name: "doctypes", type: "object[]", description: "Custom doctypes (key, name, category?, maps_to?, signals?)." },
+              { name: "fields", type: "object[]", description: "Field concepts (key, canonical_name?, data_type?, doctype_scope?, \u2026)." },
+              { name: "publish", type: "boolean", description: "Publish immediately after import." }
+            ]
+          }
+        ]
+      }
+    ],
+    related: [
+      { label: "Customer Ontologies", slug: "customer-ontologies-overview" },
+      { label: "Publish & Lifecycle", slug: "publish-customer-ontology" }
+    ],
+    faq: [
+      { question: "Do I have to anchor every doctype?", answer: "No. A doctype with no maps_to is auto-mapped to the closest Talonic type by embedding similarity before saving \u2014 unless the match is ambiguous, in which case it is left blank for you to pick." },
+      { question: "Does import replace my draft?", answer: "Import creates or replaces the draft version. Publish it (or pass publish: true) to make it live; the previously published version stays in history." }
+    ],
+    mentions: ["import", "doctypes", "fields", "auto-mapping", "publish"]
+  },
+  {
+    slug: "get-customer-ontology",
+    parentSlug: "customer-ontologies",
+    title: "Get & Version History",
+    seoTitle: "Get Customer Ontology \u2014 Talonic Docs",
+    description: "Read an ontology header with its latest version content, and list its full version history newest-first.",
+    content: [
+      { type: "paragraph", text: "Read a single ontology by id to get its header plus the content of its latest version (its doctypes and fields). List its versions to see the full draft/publish history, newest first \u2014 each publish and each auto-fork is a version, so the history is the audit trail of how the overlay evolved." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/customer-ontologies/{id}",
+        summary: "Ontology header + latest version content.",
+        description: "Requires read scope.",
+        blocks: [
+          { type: "param-table", title: "Path parameters", params: [{ name: "id", type: "string", required: true, description: "Ontology UUID." }] }
+        ]
+      },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/customer-ontologies/{id}/versions",
+        summary: "Version history, newest first.",
+        description: "Requires read scope.",
+        blocks: []
+      }
+    ],
+    related: [
+      { label: "Customer Ontologies", slug: "customer-ontologies-overview" },
+      { label: "Publish & Lifecycle", slug: "publish-customer-ontology" }
+    ],
+    faq: [
+      { question: "What is in a version?", answer: "Each version snapshots the ontology's doctypes and fields and its status (draft or published). Editing a published ontology auto-forks a new draft version, so the published one your pipelines read is immutable." }
+    ],
+    mentions: ["ontology version", "history", "draft", "published"]
+  },
+  {
+    slug: "publish-customer-ontology",
+    parentSlug: "customer-ontologies",
+    title: "Update, Publish & Lifecycle",
+    seoTitle: "Publish Customer Ontology \u2014 Talonic Docs",
+    description: "Update the draft, publish it to project into the registry and classifier, unpublish to retract, or delete the ontology \u2014 each reversing the projection as needed.",
+    content: [
+      { type: "paragraph", text: "Updating an ontology edits its draft; if the ontology is already published, the update auto-forks a fresh draft so the live overlay is untouched until you publish again. Publishing projects the latest version into your workspace: authored fields become pinned registry rows (protected from cleanup), and custom doctypes become classifier types on the customer axis. Unpublishing flips the published version back to a draft and reverses the projection; deleting removes the ontology and reverses the projection too." },
+      { type: "callout", variant: "warning", text: "Publish, unpublish, and delete change extraction and classification behavior for your workspace. They are write-scope operations; treat publishing an ontology like a configuration change, not a read." },
+      {
+        type: "endpoint",
+        method: "PATCH",
+        path: "/v1/customer-ontologies/{id}",
+        summary: "Update the draft (auto-forks if published).",
+        description: "Requires write scope.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Body parameters",
+            params: [
+              { name: "name", type: "string", description: "Rename the ontology." },
+              { name: "description", type: "string", description: "Update the description." },
+              { name: "doctypes", type: "object[]", description: "Replace the doctype set." },
+              { name: "fields", type: "object[]", description: "Replace the field set." }
+            ]
+          }
+        ]
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/customer-ontologies/{id}/publish",
+        summary: "Publish the latest version and project it.",
+        description: "Requires write scope.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/customer-ontologies/{id}/unpublish",
+        summary: "Retract the published version to a draft and reverse projection.",
+        description: "Requires write scope.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "DELETE",
+        path: "/v1/customer-ontologies/{id}",
+        summary: "Delete the ontology (versions cascade) and reverse projection.",
+        description: "Requires write scope.",
+        blocks: []
+      }
+    ],
+    related: [
+      { label: "Customer Ontologies", slug: "customer-ontologies-overview" },
+      { label: "Import an Ontology", slug: "import-customer-ontology" }
+    ],
+    faq: [
+      { question: "What happens to my registry when I unpublish?", answer: "Unpublish reverses the projection: it un-pins the authored registry rows (they are kept, not deleted, since occurrences may bind) and drops custom doctypes no document is classified under. Concepts another still-published ontology declares are left intact." },
+      { question: "Is publishing idempotent?", answer: "Yes. Re-publishing upserts the pinned registry rows and matches doctypes by name, so publishing the same content twice is a no-op." }
+    ],
+    mentions: ["publish", "unpublish", "projection", "registry", "lifecycle"]
+  },
+  {
+    slug: "customer-ontology-mappings",
+    parentSlug: "customer-ontologies",
+    title: "Map to Talonic Types",
+    seoTitle: "Customer Ontology Mappings \u2014 Talonic Docs",
+    description: "List the full Talonic type catalog, embedding-match your custom doctypes onto Talonic types, and preview the published doctypes the classifier will see.",
+    content: [
+      { type: "paragraph", text: "Every custom doctype anchors to a Talonic ontology type so the dual-axis classifier always has a built-in anchor alongside your custom label. These endpoints help you build and verify those anchors. List the full Talonic type catalog to populate a picker, embedding-match a set of your doctypes to get ranked suggestions, and preview the published custom doctypes the classifier will actually apply." },
+      { type: "paragraph", text: "Suggest-mappings is stateless \u2014 it runs over the doctypes you post and persists nothing, so an authoring UI can call it on unsaved edits. For each doctype it returns a confident `auto` target (or null), an `ambiguous` flag, and ranked `candidates` for the user to choose from." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/customer-ontologies/talonic-types",
+        summary: "The full Talonic ontology type list (id + name + breadcrumb).",
+        description: "Requires read scope. A global catalog, not tenant data.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/customer-ontologies/suggest-mappings",
+        summary: "Embedding-match posted doctypes onto Talonic types.",
+        description: "Requires read scope. Stateless \u2014 persists nothing.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Body parameters",
+            params: [
+              { name: "doctypes", type: "object[]", required: true, description: "Doctypes to match (key, name, \u2026). Returns per-doctype auto/ambiguous/candidates." }
+            ]
+          }
+        ]
+      },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/customer-ontologies/overlay/doctypes",
+        summary: "The published custom doctypes the classifier will apply.",
+        description: "Requires read scope.",
+        blocks: []
+      }
+    ],
+    related: [
+      { label: "Customer Ontologies", slug: "customer-ontologies-overview" },
+      { label: "Import an Ontology", slug: "import-customer-ontology" }
+    ],
+    faq: [
+      { question: "Why does every doctype need a Talonic anchor?", answer: "The classifier runs a Talonic axis that is always on; anchoring your custom doctype to a Talonic type preserves that built-in signal, so a custom-classified document still carries a Talonic type for routing and downstream logic." },
+      { question: "Is suggest-mappings free of side effects?", answer: "Yes. It runs over the doctypes you post and persists nothing, so you can call it on unsaved edits while authoring." }
+    ],
+    mentions: ["talonic types", "suggest mappings", "embedding match", "maps_to", "overlay doctypes"]
+  }
+];
+
+// src/content/api/account.ts
+var sections46 = [
+  {
+    slug: "get-account",
+    parentSlug: "account",
+    title: "Account Snapshot",
+    seoTitle: "Account Snapshot Endpoint \u2014 Talonic Docs",
+    description: "Read your workspace account snapshot: tier, status, credit balance and monthly allowance, daily limits, and usage so far today.",
+    content: [
+      { type: "paragraph", text: "The account endpoint returns a self-serve snapshot of your workspace: its plan `tier` and `status`, your `credits` (balance, currency, and \u2014 for the free tier \u2014 the monthly allowance and reset date), the per-namespace `daily_limits`, and `usage_today`. It is the single call an agent or dashboard reads to understand how much headroom is left before hitting a limit or running out of credits." },
+      { type: "paragraph", text: "Credits are the unit of spend. The `credits.balance` is what remains; `monthly_allowance` and `tier_resets_at` are populated for metered free-tier workspaces and null for paid tiers. The `daily_limits` are abuse ceilings per namespace (extract, platform, ingest, operations), and `usage_today` is how much of each you have consumed since midnight UTC." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/account",
+        summary: "Read the workspace account snapshot.",
+        description: "Requires read scope.",
+        blocks: []
+      },
+      { type: "heading", level: 2, id: "get-account-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response fields",
+        params: [
+          { name: "tier", type: "string", description: "Plan tier (e.g. free, pro)." },
+          { name: "status", type: "string", description: "Account status (e.g. active)." },
+          { name: "credits.balance", type: "integer", description: "Remaining credit balance." },
+          { name: "credits.currency", type: "string", description: "Credit currency (EUR)." },
+          { name: "credits.monthly_allowance", type: "integer | null", description: "Free-tier monthly credit grant (null for paid tiers)." },
+          { name: "credits.tier_resets_at", type: "string | null", description: "When the free-tier allowance resets (null for paid)." },
+          { name: "daily_limits", type: "object", description: "Per-namespace daily ceilings (extract, platform, ingest, operations)." },
+          { name: "usage_today", type: "object", description: "Per-namespace usage since midnight UTC." }
+        ]
+      },
+      {
+        type: "code",
+        title: "curl",
+        language: "bash",
+        code: `curl -s https://api.talonic.ai/v1/account \\
+  -H "Authorization: Bearer tlnc_your_api_key"`
+      }
+    ],
+    related: [
+      { label: "Manage API Keys", slug: "account-keys" },
+      { label: "Credit Balance", slug: "credits-balance" }
+    ],
+    faq: [
+      { question: "What are credits?", answer: "Credits are the unit of spend for metered operations. The account snapshot shows your remaining balance, and (on the free tier) the monthly allowance and its reset date." },
+      { question: "What do daily_limits mean?", answer: "They are per-namespace abuse ceilings, not billing limits. Spend is governed by the credit balance; the daily limits only stop pathological request volume." }
+    ],
+    mentions: ["account", "tier", "credits", "daily limits", "usage"]
+  },
+  {
+    slug: "account-keys",
+    parentSlug: "account",
+    title: "Manage API Keys",
+    seoTitle: "Manage API Keys \u2014 Talonic Docs",
+    description: "List your workspace API keys (masked), mint a new scoped key (the raw secret is returned once), and revoke a key.",
+    content: [
+      { type: "paragraph", text: "These endpoints let a workspace manage its own API keys programmatically. List your keys (always masked \u2014 the raw secret is never returned again), mint a new key with a name and a chosen scope set, and revoke a key you no longer need. The raw secret of a new key is returned exactly once, on creation; store it immediately." },
+      { type: "paragraph", text: "A key carries a subset of the valid scopes \u2014 `extract`, `read`, `write`, `operations`, `billing`, `delivery`. If you omit `scopes` on create, the key defaults to `extract, read, write, operations`. Revocation is scoped to your own workspace, so you can never revoke another tenant's key." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/account/keys",
+        summary: "List the workspace API keys (masked).",
+        description: "Requires read scope. The raw secret is never returned.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/account/keys",
+        summary: "Mint a scoped API key. Returns the raw secret once.",
+        description: "Requires write scope.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Body parameters",
+            params: [
+              { name: "name", type: "string", required: true, description: "A label for the key." },
+              { name: "scopes", type: "string[]", description: "Requested scopes (subset of extract, read, write, operations, billing, delivery). Defaults to extract, read, write, operations." }
+            ]
+          }
+        ]
+      },
+      {
+        type: "endpoint",
+        method: "DELETE",
+        path: "/v1/account/keys/:keyId",
+        summary: "Revoke an API key.",
+        description: "Requires write scope. Scoped to your own workspace.",
+        blocks: [
+          { type: "param-table", title: "Path parameters", params: [{ name: "keyId", type: "string", required: true, description: "The API key id to revoke." }] }
+        ]
+      },
+      { type: "callout", variant: "warning", text: "The raw key secret is shown only once, in the create response. If you lose it, revoke the key and mint a new one \u2014 it cannot be retrieved again." }
+    ],
+    related: [
+      { label: "Account Snapshot", slug: "get-account" },
+      { label: "Authentication", slug: "authentication" }
+    ],
+    faq: [
+      { question: "Can I retrieve a key secret later?", answer: "No. The raw secret is returned only once on creation. Listing keys returns masked values. If lost, revoke and mint a new key." },
+      { question: "What scopes can a key have?", answer: "A subset of extract, read, write, operations, billing, and delivery. Omitting scopes on create defaults to extract, read, write, operations." }
+    ],
+    mentions: ["api keys", "scopes", "mint key", "revoke", "self-serve"]
+  }
+];
+
+// src/content/api/nodes.ts
+var sections47 = [
+  {
+    slug: "node-jobs",
+    parentSlug: "nodes",
+    title: "Node Jobs",
+    seoTitle: "Node Jobs \u2014 Per-Stage Primitives \u2014 Talonic Docs",
+    description: "Run a single pipeline stage as a standalone async job \u2014 transfer, extract, resolve, validate, or assemble \u2014 chained over one record set.",
+    content: [
+      { type: "paragraph", text: "Node jobs expose the individual stages of the structuring pipeline as standalone primitives. Where a Spec/pipeline runs the whole rail end to end, node jobs let you run one stage at a time \u2014 Transfer, Extraction, Resolution, Validation, or Assembly \u2014 and chain them yourself over a shared `record_set_id`. Each call is asynchronous: it returns a node-run id you poll for status and results." },
+      { type: "paragraph", text: "The typical chain starts with `POST /v1/nodes/transfer` (or `extract`) against a set of `document_ids` and a `schema_id`, which creates a record set and fills cells. Each subsequent stage takes the `record_set_id` from the previous one: `extract` fills gaps the registry could not, `resolve` applies Data Policies, `validate` runs your gates, and `assemble` composes grouped documents. This gives you fine-grained control over the structuring flow when a single Spec run is too coarse." },
+      { type: "callout", variant: "info", text: "Node jobs are an advanced primitive. Most integrations should run a configured Spec via POST /v1/pipelines, which compiles and runs the whole rail in one call. Reach for node jobs when you need to drive stages individually." },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/nodes/transfer",
+        summary: "Fill cells deterministically from the field registry (creates a record set).",
+        description: "Requires write scope. Body: schema_id, document_ids.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Body parameters",
+            params: [
+              { name: "schema_id", type: "string", required: true, description: "The schema to structure against." },
+              { name: "document_ids", type: "string[]", required: true, description: "Documents to process." }
+            ]
+          }
+        ]
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/nodes/extract",
+        summary: "Run extraction for gap fields over a record set.",
+        description: "Requires write scope. Body: schema_id, document_ids, record_set_id.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/nodes/resolve",
+        summary: "Apply Data Policies to a record set.",
+        description: "Requires write scope. Body: record_set_id (+ the policies to apply).",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/nodes/validate",
+        summary: "Run validation gates over a record set.",
+        description: "Requires write scope. Body: record_set_id (+ the validation stage to run).",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/nodes/assemble",
+        summary: "Compose grouped documents within a record set.",
+        description: "Requires write scope. Body: record_set_id, grouping_field, anchor_field.",
+        blocks: []
+      },
+      { type: "heading", level: 2, id: "node-jobs-poll", text: "Polling a node run" },
+      { type: "paragraph", text: "Each stage call returns a node-run id. Poll `GET /v1/nodes/:id` for its status and progress, and `GET /v1/nodes/:id/results` for its output once it completes. Carry the `record_set_id` forward to the next stage to chain the pipeline." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/nodes/:id",
+        summary: "Get a node run's status and progress.",
+        description: "Requires read scope.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/nodes/:id/results",
+        summary: "Get a node run's output.",
+        description: "Requires read scope.",
+        blocks: []
+      }
+    ],
+    related: [
+      { label: "Run a Pipeline", slug: "run-pipeline" },
+      { label: "List Schemas", slug: "list-schemas" }
+    ],
+    faq: [
+      { question: "When should I use node jobs instead of a pipeline?", answer: "Use a pipeline (POST /v1/pipelines) for the normal end-to-end run. Use node jobs when you need to drive individual stages \u2014 for example to inspect or branch between transfer, extraction, and resolution." },
+      { question: "How do stages share state?", answer: "Through the record_set_id. The first stage creates a record set; pass that id to each subsequent stage so they operate on the same cells." }
+    ],
+    mentions: ["node jobs", "record set", "transfer", "extract", "resolve", "assemble"]
+  }
+];
+
+// src/content/api/process.ts
+var sections48 = [
+  {
+    slug: "submit-process",
+    parentSlug: "process",
+    title: "Submit for Processing",
+    seoTitle: "Submit for Processing \u2014 Named Operations \u2014 Talonic Docs",
+    description: "Submit a document against a named processing configuration and have results delivered via webhook. Idempotent per (config, batch, file).",
+    content: [
+      { type: "paragraph", text: "The process endpoint is the named-operations front door: upload a document, name the processing configuration to run it through, and get results delivered asynchronously via the `process.completed` webhook. It always returns immediately (202 Accepted) with a `run_id` and a `poll_url`, so you never block on the pipeline." },
+      { type: "paragraph", text: "Idempotency is automatic. The same `(config_id, batch_id, file)` combination returns the existing run instead of re-processing, so a retried upload is safe. If `batch_id` is absent, dedup applies within a 24-hour window. This makes the endpoint robust for at-least-once delivery from upstream systems." },
+      { type: "callout", variant: "info", text: "This surface uses the operations scope. Configure the processing configurations (and discover their IDs) with GET /v1/configs." },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/process",
+        summary: "Submit a document for processing through a named configuration.",
+        description: "Requires operations scope. Multipart upload. Always returns 202; results via webhook.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Multipart form fields",
+            params: [
+              { name: "config_id", type: "string", required: true, description: "Processing configuration ID (from GET /v1/configs)." },
+              { name: "file", type: "file", required: true, description: "Document to process. Max 500 MB." },
+              { name: "batch_id", type: "string", description: "Optional batch identifier. Enables permanent dedup for this (config, batch, file) triple." },
+              { name: "metadata", type: "string", description: "Optional JSON string with additional metadata." }
+            ]
+          }
+        ]
+      },
+      { type: "heading", level: 2, id: "submit-process-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response fields (202)",
+        params: [
+          { name: "request_id", type: "string", description: "Identifier for this submission." },
+          { name: "run_id", type: "string", description: "The run UUID to poll." },
+          { name: "config_id", type: "string", description: "The configuration used." },
+          { name: "status", type: "string", description: "processing." },
+          { name: "poll_url", type: "string", description: "URL to poll for the run result." }
+        ]
+      },
+      { type: "callout", variant: "info", text: "A 200 (instead of 202) means an idempotency hit \u2014 the existing run result is returned without re-processing." }
+    ],
+    related: [
+      { label: "Get Run", slug: "get-run" },
+      { label: "List Configs", slug: "list-configs" }
+    ],
+    faq: [
+      { question: "How is idempotency handled?", answer: "The same (config_id, batch_id, file) returns the existing run rather than re-processing. Without batch_id, dedup applies within a 24-hour window." },
+      { question: "How do I get results?", answer: "Results are delivered via the process.completed webhook, or poll the run via the poll_url / GET /v1/runs/:id." }
+    ],
+    mentions: ["process", "named operations", "idempotency", "webhook", "config"]
+  },
+  {
+    slug: "get-run",
+    parentSlug: "process",
+    title: "Get Run",
+    seoTitle: "Get Run \u2014 Named Operations \u2014 Talonic Docs",
+    description: "Poll a processing run by id for its status and result.",
+    content: [
+      { type: "paragraph", text: "Retrieve a processing run by its id to read its status and, once complete, its structured result. This is the polling target for the `poll_url` returned by the process submission, for callers that prefer polling over the completion webhook." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/runs/:id",
+        summary: "Get a processing run by id.",
+        description: "Requires operations scope.",
+        blocks: [
+          { type: "param-table", title: "Path parameters", params: [{ name: "id", type: "string", required: true, description: "The run UUID." }] }
+        ]
+      }
+    ],
+    related: [
+      { label: "Submit for Processing", slug: "submit-process" },
+      { label: "List Configs", slug: "list-configs" }
+    ],
+    faq: [
+      { question: "Should I poll or use the webhook?", answer: "Either. The process.completed webhook pushes results; polling GET /v1/runs/:id pulls them. Webhooks are preferred for scale; polling is simpler for one-off scripts." }
+    ],
+    mentions: ["run", "poll", "process", "status"]
+  },
+  {
+    slug: "list-configs",
+    parentSlug: "process",
+    title: "Processing Configs",
+    seoTitle: "Processing Configs \u2014 Named Operations \u2014 Talonic Docs",
+    description: "List the named processing configurations available to your workspace and read one by id.",
+    content: [
+      { type: "paragraph", text: "Processing configurations are the named pipelines the process endpoint runs documents through. List them to discover the `config_id` values you pass to `POST /v1/process`, and read one by id to inspect its settings." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/configs",
+        summary: "List processing configurations.",
+        description: "Requires operations scope.",
+        blocks: []
+      },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/configs/:id",
+        summary: "Get a processing configuration by id.",
+        description: "Requires operations scope.",
+        blocks: [
+          { type: "param-table", title: "Path parameters", params: [{ name: "id", type: "string", required: true, description: "The configuration id." }] }
+        ]
+      }
+    ],
+    related: [
+      { label: "Submit for Processing", slug: "submit-process" },
+      { label: "Get Run", slug: "get-run" }
+    ],
+    faq: [
+      { question: "Where do config IDs come from?", answer: "From GET /v1/configs. Each entry has an id you pass as config_id when submitting a document to POST /v1/process." }
+    ],
+    mentions: ["configs", "processing configuration", "config_id", "named operations"]
+  }
+];
+
+// src/content/api/reference-data.ts
+var sections49 = [
   {
     slug: "list-reference-data",
     parentSlug: "reference-data",
@@ -25713,7 +26943,7 @@ V003,Initech Ltd,DE,DE987654321`
 ];
 
 // src/content/api/errors-rate-limits.ts
-var sections46 = [
+var sections50 = [
   {
     slug: "error-format",
     parentSlug: "errors-rate-limits",
@@ -25865,7 +27095,7 @@ X-RateLimit-Reset: 2026-04-26T00:00:00.000Z`
 ];
 
 // src/content/api/usage.ts
-var sections47 = [
+var sections51 = [
   {
     slug: "usage-overview",
     parentSlug: "usage",
@@ -26138,7 +27368,7 @@ var sections47 = [
 ];
 
 // src/content/api/pricing.ts
-var sections48 = [
+var sections52 = [
   {
     slug: "pricing-overview",
     parentSlug: "pricing",
@@ -26250,7 +27480,7 @@ console.log(\`Batch:    \${batchCredits} credits (\${batchCredits / pricing.cred
 ];
 
 // src/content/api/document-types.ts
-var sections49 = [
+var sections53 = [
   {
     slug: "list-document-types",
     parentSlug: "document-types",
@@ -26407,7 +27637,7 @@ var sections49 = [
 ];
 
 // src/content/api/dialects.ts
-var sections50 = [
+var sections54 = [
   {
     slug: "list-dialects",
     parentSlug: "dialects",
@@ -26936,7 +28166,7 @@ var sections50 = [
 ];
 
 // src/content/api/fields.ts
-var sections51 = [
+var sections55 = [
   {
     slug: "list-fields",
     parentSlug: "fields",
@@ -27355,7 +28585,7 @@ var sections51 = [
 ];
 
 // src/content/api/data-products.ts
-var sections52 = [
+var sections56 = [
   {
     slug: "list-data-products",
     parentSlug: "data-products",
@@ -27843,11 +29073,131 @@ var sections52 = [
       { question: "What does the public share link expose?", answer: "A read-only view of the assembled data product: its result rows and metadata. Visitors cannot edit the product, access other products, or authenticate into your workspace. If the share has a password, visitors must enter it to view the data." }
     ],
     mentions: ["share token", "public link", "data product", "read-only", "rotate"]
+  },
+  {
+    slug: "create-data-product",
+    parentSlug: "data-products",
+    title: "Create Data Product",
+    seoTitle: "Create Data Product Endpoint \u2014 Talonic Docs",
+    description: "Assemble a data product from one or more completed job or resolution runs and mint its share token in a single call.",
+    content: [
+      { type: "paragraph", text: "Create a data product from one or more completed runs. A data product is the platform's final deliverable: an assembled, canonical dataset wrapped for handover, with quality thresholds, a share link, and CSV export. This endpoint is the run-backed create path \u2014 pass the run IDs that feed the product and it assembles them and mints a share token in one call." },
+      { type: "paragraph", text: "The body requires a `name` and a non-empty `run_ids` array (the completed job or resolution runs whose results the product assembles). You may optionally pass `thresholds` to filter rows by quality \u2014 `min_confidence`, `require_validation_pass`, and `require_approval`. The response is the created product with its `id`, `run_ids`, `status`, and `links`." },
+      { type: "callout", variant: "info", text: "This is the run-backed create path. Products built from a validation session or a pipeline are created through their own surfaces (the pipeline's `POST /v1/pipelines/{id}/data-product`)." },
+      {
+        type: "endpoint",
+        method: "POST",
+        path: "/v1/data-products",
+        summary: "Create a run-backed data product and mint its share token.",
+        description: "Requires write scope.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Body parameters",
+            params: [
+              { name: "name", type: "string", required: true, description: "A name for the data product." },
+              { name: "run_ids", type: "string[]", required: true, description: "Completed job/resolution run UUIDs to assemble." },
+              { name: "description", type: "string", description: "Optional description." },
+              { name: "thresholds", type: "object", description: "Optional quality filters: min_confidence (0\u20131), require_validation_pass, require_approval." }
+            ]
+          }
+        ]
+      },
+      {
+        type: "code",
+        title: "curl",
+        language: "bash",
+        code: `curl -s -X POST https://api.talonic.ai/v1/data-products \\
+  -H "Authorization: Bearer tlnc_your_api_key" \\
+  -H "Content-Type: application/json" \\
+  -d '{
+    "name": "Q2 Deliveries",
+    "run_ids": ["c3d4e5f6-a7b8-9012-cdef-123456789012"],
+    "thresholds": { "min_confidence": 0.8 }
+  }'`
+      },
+      {
+        type: "code",
+        title: "Response",
+        code: `{
+  "id": "6ecb46fa-24ba-4b5d-93ee-b8b6c6b97655",
+  "name": "Q2 Deliveries",
+  "description": null,
+  "run_ids": ["c3d4e5f6-a7b8-9012-cdef-123456789012"],
+  "status": "active",
+  "created_at": "2026-06-27T10:00:00.000Z",
+  "links": {
+    "self": "/v1/data-products/6ecb46fa-24ba-4b5d-93ee-b8b6c6b97655",
+    "results": "/v1/data-products/6ecb46fa-24ba-4b5d-93ee-b8b6c6b97655/results",
+    "export_plain": "/v1/data-products/6ecb46fa-24ba-4b5d-93ee-b8b6c6b97655/export/plain",
+    "export_audit": "/v1/data-products/6ecb46fa-24ba-4b5d-93ee-b8b6c6b97655/export/audit"
+  }
+}`
+      }
+    ],
+    related: [
+      { label: "List Data Products", slug: "list-data-products" },
+      { label: "Export Data Product", slug: "export-data-product" },
+      { label: "Data Product Share Link", slug: "data-product-share" }
+    ],
+    faq: [
+      { question: "What runs can feed a data product?", answer: "Completed job or resolution runs. Pass their UUIDs in run_ids. The product assembles their results into one canonical dataset." },
+      { question: "Does creating a product make it public?", answer: "A share token is minted on create, but the public link is governed by the share endpoints and is password-protected. Use GET /v1/data-products/{id}/share to read it." }
+    ],
+    mentions: ["create data product", "run-backed", "assemble", "thresholds", "share token"]
+  },
+  {
+    slug: "export-data-product",
+    parentSlug: "data-products",
+    title: "Export Data Product",
+    seoTitle: "Export Data Product CSV \u2014 Talonic Docs",
+    description: "Download a data product as CSV \u2014 a plain values export, or an audit export with PENDING_REVIEW markers for held pipeline cells.",
+    content: [
+      { type: "paragraph", text: "Export a data product's rows as a CSV file. Two variants are available: a **plain** export of the values, and an **audit** export that preserves the handover trail. Both stream the file as an attachment." },
+      { type: "paragraph", text: "For a pipeline-backed product, cells still held in the review queue (`pending_approval`) are treated carefully: the plain export writes them as empty, and the audit export writes a `PENDING_REVIEW` marker so the held value is never serialized into the file. This keeps an in-flight review from leaking an unapproved value while still letting you export everything that has cleared." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/data-products/:id/export/plain",
+        summary: "Download the plain-values CSV.",
+        description: "Requires read scope. Held pipeline cells are written empty.",
+        blocks: [
+          { type: "param-table", title: "Path parameters", params: [{ name: "id", type: "string", required: true, description: "Data product UUID." }] }
+        ]
+      },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/data-products/:id/export/audit",
+        summary: "Download the audit CSV (handover trail).",
+        description: "Requires read scope. Held pipeline cells are written as PENDING_REVIEW.",
+        blocks: [
+          { type: "param-table", title: "Path parameters", params: [{ name: "id", type: "string", required: true, description: "Data product UUID." }] }
+        ]
+      },
+      {
+        type: "code",
+        title: "curl",
+        language: "bash",
+        code: `curl -s https://api.talonic.ai/v1/data-products/6ecb46fa-24ba-4b5d-93ee-b8b6c6b97655/export/plain \\
+  -H "Authorization: Bearer tlnc_your_api_key" -o data-product.csv`
+      },
+      { type: "callout", variant: "info", text: "The response is a CSV attachment (`text/csv`), not JSON. Both variants accept the product UUID as the path parameter." }
+    ],
+    related: [
+      { label: "Get Data Product Results", slug: "get-data-product-results" },
+      { label: "Create Data Product", slug: "create-data-product" }
+    ],
+    faq: [
+      { question: "What is the difference between the plain and audit exports?", answer: "Plain is the values only. Audit preserves the handover trail and marks held pipeline cells as PENDING_REVIEW instead of writing them empty." },
+      { question: "Why is a cell empty (plain) or PENDING_REVIEW (audit)?", answer: "That cell is still held in the field-review queue. Its value is never serialized into an export until a reviewer resolves it, so an in-flight review cannot leak an unapproved value." }
+    ],
+    mentions: ["export", "CSV", "audit trail", "pending review", "data product"]
   }
 ];
 
 // src/content/api/data-policies.ts
-var sections53 = [
+var sections57 = [
   {
     slug: "list-data-policies",
     parentSlug: "data-policies",
@@ -28432,9 +29782,10 @@ var sections53 = [
     ],
     faq: [
       { question: "What happens to values not declared as fields?", answer: "Values computed by rules but not declared as policy fields are treated as intermediate variables and discarded from the final output. Only declared fields appear in resolution results. You can enable `emit_undeclared_cells` in pipeline config for debugging." },
-      { question: "Can Lua scripts write to undeclared field keys?", answer: "Yes. Lua scripts can write to any cell name as a temporary variable for intermediate computation. However, only values written to declared field keys will appear in the resolution output. Undeclared keys are silently dropped unless debugging is enabled." }
+      { question: "Can Lua scripts write to undeclared field keys?", answer: "Yes. Lua scripts can write to any cell name as a temporary variable for intermediate computation. However, only values written to declared field keys will appear in the resolution output. Undeclared keys are silently dropped unless debugging is enabled." },
+      { question: "Can Lua rules use regular expressions?", answer: "Yes. Lua scripts have a built-in `regex` helper \u2014 `regex.test(subject, pattern)`, `regex.match(subject, pattern)`, and `regex.replace(subject, pattern, replacement)` \u2014 backed by the RE2 engine, so matching is linear-time and immune to catastrophic backtracking (ReDoS). Pattern and subject length are capped (configurable), and an invalid pattern fails the rule loudly rather than silently." }
     ],
-    mentions: ["data policy", "transformation", "normalization", "Lua"]
+    mentions: ["data policy", "transformation", "normalization", "Lua", "regex"]
   },
   {
     slug: "list-data-policy-rules",
@@ -28535,7 +29886,7 @@ var sections53 = [
 ];
 
 // src/content/api/record-sets.ts
-var sections54 = [
+var sections58 = [
   {
     slug: "list-record-sets",
     parentSlug: "record-sets",
@@ -28995,7 +30346,7 @@ var sections54 = [
 ];
 
 // src/content/api/pipelines.ts
-var sections55 = [
+var sections59 = [
   {
     slug: "run-pipeline",
     parentSlug: "pipelines",
@@ -29258,6 +30609,7 @@ var sections55 = [
       { type: "paragraph", text: 'Each document moves through the per-document phases sequentially: transfer, extraction, resolution, then validation checkpoints. Pipeline-scoped phases such as assembly run once after every document is terminal, so they report a single `status` and `scope: "pipeline"` instead of per-document counters. The `errors` array surfaces per-document failures, including documents that errored before reaching any phase, so no failure is invisible.' },
       { type: "paragraph", text: "This endpoint is the polling target after `POST /v1/pipelines`. Poll every few seconds and watch the per-phase counters advance as documents flow through the rail. When `completedDocuments` plus `errorDocuments` reaches `totalDocuments`, the run is terminal and you can produce a data product. This endpoint requires an API key with the `read` scope." },
       { type: "callout", variant: "info", text: 'A phase row with `scope: "pipeline"` (such as assembly) reports its own `status` field. Its per-document counters are approximations for older consumers; trust the `status` value for pipeline-scoped phases.' },
+      { type: "paragraph", text: "A Spec can place Resolution or Validation **after** Assembly in the rail. These compile to pipeline-scoped tail phases that run once over the composed record: a post-assembly resolution normalizes the assembled row (and mirrors the resolved values back so the data product ships them), and a post-assembly validation gate checks the full composed row, resolution first. Like assembly, these tail phases run after every document is terminal and are not surfaced as per-document progress rows, so do not wait on them in the counters \u2014 the run is terminal once `completedDocuments` plus `errorDocuments` reaches `totalDocuments`." },
       {
         type: "endpoint",
         method: "GET",
@@ -29552,7 +30904,7 @@ var sections55 = [
 ];
 
 // src/content/api/field-reviews.ts
-var sections56 = [
+var sections60 = [
   {
     slug: "list-field-reviews",
     parentSlug: "field-reviews",
@@ -30163,11 +31515,124 @@ dec_uuid_1,a1b2c3d4-e5f6-7890-abcd-ef1234567890,lease_oct.pdf,total_amount,gate,
       { question: "Is the CSV export paginated?", answer: "No. Unlike the JSON decisions list, the CSV returns the full decision history for the requested scope in one download, which is what a handover audit needs." }
     ],
     mentions: ["decision export", "CSV", "handover", "audit trail", "RFC 4180"]
+  },
+  {
+    slug: "field-review-triage",
+    parentSlug: "field-reviews",
+    title: "Triage Breakdown",
+    seoTitle: "Field Review Triage \u2014 Talonic Docs",
+    description: "A classification-backed breakdown of the review queue: counts by reason, field, document, assignee, and tag, each group carrying a per-group reason mix.",
+    content: [
+      { type: "paragraph", text: "The triage endpoint returns the review queue's shape rather than its items: how the held fields break down `byReason`, `byField`, `byDocument`, `byAssignee`, and `byTag`. Each group carries a per-group reason `mix`, so you can see not just how many items a field or document has, but why they are held \u2014 disagreement, low confidence, a failed check, a missing value. It is what a review dashboard reads to draw section headers and prioritize work." },
+      { type: "paragraph", text: "Triage honors the same scope filters as the queue list (`pipeline_id`, `schema_id`, `document_id`, `stage_id`, `trigger`, `older_than_hours`, `include_held`, `assignee`, and the free-text `q`), so you can scope the breakdown to one pipeline or one schema. It intentionally does NOT honor `reason` or tag filters \u2014 those facets stay the full switchable vocabulary so every reason and tag is represented." },
+      { type: "callout", variant: "info", text: "Use triage to power a queue header or routing logic: the reason mix tells you which fields are mostly safe to bulk-approve versus which need a careful human look." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/field-reviews/triage",
+        summary: "Get the review-queue breakdown by reason, field, document, assignee, and tag.",
+        description: "Requires read scope.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Query parameters",
+            params: [
+              { name: "pipeline_id", type: "string", description: "Scope to one pipeline." },
+              { name: "schema_id", type: "string", description: "Scope to one schema." },
+              { name: "document_id", type: "string", description: "Scope to one pipeline document." },
+              { name: "stage_id", type: "string", description: "Scope to one validation stage." },
+              { name: "trigger", type: "string", description: "gate | declarative." },
+              { name: "assignee", type: "string", description: "me | unassigned." },
+              { name: "q", type: "string", description: "Free-text filter over field key, display name, filename, assignee." },
+              { name: "older_than_hours", type: "integer", description: "Only items requested before this many hours ago." },
+              { name: "include_held", type: "boolean", description: "Include hold-routed items (default false)." }
+            ]
+          }
+        ]
+      },
+      { type: "heading", level: 2, id: "field-review-triage-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response fields",
+        params: [
+          { name: "byReason", type: "object", description: "Counts per reason bucket (missing_value, disagreement, failed_check, low_confidence, likely_fine, other)." },
+          { name: "byField", type: "object[]", description: "Per-field groups with count and reason mix." },
+          { name: "byDocument", type: "object[]", description: "Per-document groups with count and reason mix." },
+          { name: "byAssignee", type: "object[]", description: "Per-assignee groups (null owners folded into one unassigned bucket)." },
+          { name: "byTag", type: "object[]", description: "Per-tag groups (an item joins every tag on its schema field)." }
+        ]
+      }
+    ],
+    related: [
+      { label: "List Field Reviews", slug: "list-field-reviews" },
+      { label: "Value Clusters", slug: "field-review-value-clusters" }
+    ],
+    faq: [
+      { question: "How is triage different from the summary endpoint?", answer: "Summary is cheap top-level counts for a nav badge. Triage loads cells and verdicts to classify each item, so it can return the full reason mix per field, document, assignee, and tag." },
+      { question: "Why does triage ignore the reason and tag filters?", answer: "Those facets are the switchable vocabulary the breakdown itself produces, so they must reflect the scope before a selection \u2014 otherwise selecting one reason would hide the others from the breakdown." }
+    ],
+    mentions: ["triage", "review queue", "reason mix", "by field", "by tag"]
+  },
+  {
+    slug: "field-review-value-clusters",
+    parentSlug: "field-reviews",
+    title: "Value Clusters",
+    seoTitle: "Field Review Value Clusters \u2014 Talonic Docs",
+    description: "Distinct current values among the filtered review set (typically one field), with counts and member items \u2014 drives identical-value cluster bulk-approve.",
+    content: [
+      { type: "paragraph", text: 'The value-clusters endpoint groups held review items by their current value. When a single field is held across many documents with the same value, those items form one cluster you can review once and approve together. This is the data behind a "approve all 40 documents where vendor_name is Meridian Energy AG" action: one decision instead of forty.' },
+      { type: "paragraph", text: "Filter to the set you want to cluster \u2014 typically a single `field_key`, optionally scoped by `pipeline_id`, `schema_id`, `document_id`, `stage_id`, `trigger`, `reason`, `assignee`, or age. Each returned cluster carries the distinct value, a count, and its member items (the document + field-key pairs), which you can hand straight to `POST /v1/field-reviews/bulk-resolve`." },
+      { type: "callout", variant: "info", text: "Pair value clusters with bulk-resolve: cluster a field's held values, then bulk-approve the clusters you trust and inspect only the outliers." },
+      {
+        type: "endpoint",
+        method: "GET",
+        path: "/v1/field-reviews/value-clusters",
+        summary: "Group held review items by their current value.",
+        description: "Requires read scope.",
+        blocks: [
+          {
+            type: "param-table",
+            title: "Query parameters",
+            params: [
+              { name: "field_key", type: "string", description: "Cluster a single field (the common case)." },
+              { name: "pipeline_id", type: "string", description: "Scope to one pipeline." },
+              { name: "schema_id", type: "string", description: "Scope to one schema." },
+              { name: "document_id", type: "string", description: "Scope to one pipeline document." },
+              { name: "stage_id", type: "string", description: "Scope to one validation stage." },
+              { name: "trigger", type: "string", description: "gate | declarative." },
+              { name: "reason", type: "string", description: "Restrict to one reason bucket." },
+              { name: "assignee", type: "string", description: "me | unassigned." },
+              { name: "older_than_hours", type: "integer", description: "Only items requested before this many hours ago." },
+              { name: "include_held", type: "boolean", description: "Include hold-routed items (default false)." }
+            ]
+          }
+        ]
+      },
+      { type: "heading", level: 2, id: "field-review-value-clusters-response", text: "Response" },
+      {
+        type: "param-table",
+        title: "Response fields",
+        params: [
+          { name: "clusters[].value", type: "string", description: "The distinct current value shared by the cluster." },
+          { name: "clusters[].count", type: "integer", description: "Number of held items with this value." },
+          { name: "clusters[].items", type: "object[]", description: "Member items (pipeline document id + field key) for bulk-resolve." }
+        ]
+      }
+    ],
+    related: [
+      { label: "Bulk Resolve Field Reviews", slug: "bulk-resolve-field-reviews" },
+      { label: "Triage Breakdown", slug: "field-review-triage" }
+    ],
+    faq: [
+      { question: "How do I act on a cluster?", answer: "Pass the cluster's member items to POST /v1/field-reviews/bulk-resolve with an action (approve, correct, or override). Each item runs through the single-field resolve path, so the decision log and promotion behave identically." },
+      { question: "Should I cluster across multiple fields at once?", answer: "Usually no. Clustering is most useful per field_key \u2014 identical values mean the same thing within one field. Across fields, the same string can mean different things." }
+    ],
+    mentions: ["value clusters", "bulk approve", "review queue", "identical values"]
   }
 ];
 
 // src/content/api/spec-config.ts
-var sections57 = [
+var sections61 = [
   {
     slug: "get-spec-rail",
     parentSlug: "spec-config",
@@ -31159,7 +32624,7 @@ var sections57 = [
 ];
 
 // src/content/api/reconciliation.ts
-var sections58 = [
+var sections62 = [
   {
     slug: "analyze-reconciliation",
     parentSlug: "reconciliation",
@@ -31731,7 +33196,7 @@ var sections58 = [
 ];
 
 // src/content/api/matching-packages.ts
-var sections59 = [
+var sections63 = [
   {
     slug: "create-matching-package-config",
     parentSlug: "matching-packages",
@@ -32624,7 +34089,7 @@ talonic --help` }
 ];
 
 // src/content/sdk/index.ts
-var sections60 = sections_default;
+var sections64 = sections_default;
 
 // src/content/mcp/sections.json
 var sections_default2 = [
@@ -35119,7 +36584,7 @@ var sections_default2 = [
 ];
 
 // src/content/mcp/index.ts
-var sections61 = sections_default2;
+var sections65 = sections_default2;
 
 // src/content/index.ts
 var ALL_PLATFORM_RAW = [
@@ -35170,10 +36635,10 @@ var ALL_API_RAW = [
   ...sections43,
   ...sections44,
   ...sections45,
+  ...sections46,
   ...sections47,
   ...sections48,
   ...sections49,
-  ...sections50,
   ...sections51,
   ...sections52,
   ...sections53,
@@ -35183,10 +36648,14 @@ var ALL_API_RAW = [
   ...sections57,
   ...sections58,
   ...sections59,
-  ...sections46
+  ...sections60,
+  ...sections61,
+  ...sections62,
+  ...sections63,
+  ...sections50
 ];
-var ALL_SDK_RAW = [...sections60];
-var ALL_MCP_RAW = [...sections61];
+var ALL_SDK_RAW = [...sections64];
+var ALL_MCP_RAW = [...sections65];
 function enrich(raw, navSections, domain) {
   return raw.map((r) => {
     const { prev, next } = derivePrevNext(navSections, r.slug);