Extend vs Datalab

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Extend
   Extend✓fullprobed9/10

   Extend has a confirmed live llms.txt at docs.extend.ai/llms.txt (HTTP 200) providing agent-oriented documentation, alongside agent-oriented docs like the Agent Quickstart and MCP integration docs that an AI agent could consume directly. Missing for 10: no independent/community confirmation of an agent actually consuming llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.extend.ai/llms.txt # Extend > Extend is a platform for building, iterating on, evaluating, and dep…”
   • [claimed-docs] “Agent Quickstart | Extend Documentation”
   • [claimed-docs] “Using Extend via MCP | Extend Documentation”

   proof ↗⚑ flag

   Datalab✓fullprobed8/10

   Datalab hosts a working llms.txt confirmed via direct probe (HTTP 200) at documentation.datalab.to/llms.txt, and also exposes .md variants of docs pages, both signals of agent-oriented documentation. Missing for 10: no independent third-party confirmation of agent usage/adoption, and no dedicated agent-facing onboarding guide beyond the llms.txt file and .md endpoints.

   • [probe] “PROBE llms.txt: HTTP 200 at https://documentation.datalab.to/llms.txt # Datalab Documentation - [Welcome to Datalab](https://documentation.…”
   • [claimed-docs] “You can override the default webhook URL for specific API requests by including the `webhook_url` parameter”
   • [claimed-docs] “Fill PDF and image forms with structured field data using the Datalab SDK.”
   • [claimed-docs] “Datalab provides file storage for documents you want to process with pipelines or reuse across multiple API calls.”
   • [claimed-docs] “Pipelines chain processors (convert, extract, segment, custom) into reusable, versioned configurations.”
   • [claimed-docs] “Create a DOCX document from markdown with track changes support. Supports <ins>, <del>, and <comment> tags.”
   • [claimed-docs] “Run a published agent processor on a document. Address it with processor=<id>, optionally pinned to a version as <id>@<version>”
   • [claimed-docs] “For a given file, generate potential extraction schemas.”
   • [claimed-docs] “This endpoint is used to check the health of the API, given an API key.”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Datalab
   Extend~partialprobed6/10

   Extend offers a documented CLI, Python SDK (pip install), and REST API with sync/async modes and a test API key mode, all of which support headless/CI-driven automation of document processing. However, there is no explicit CI/CD integration guide, GitHub Actions example, or independent hands-on report of running it in a CI pipeline. missing for 10: explicit CI pipeline examples/integration guide, independent hands-on verification of headless CI usage, and details on exit codes/CLI scripting ergonomics for automation.

   • [claimed-docs] “pip install extend-ai”
   • [claimed-docs] “CLI | Extend Documentation”
   • [claimed-docs] “SDKs | Extend Documentation”
   • [claimed-docs] “API Quickstart | Extend Documentation”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”
   • [claimed-docs] “Runs made with a test API key never touch production data and never fire production webhooks”
   • [probe] “official CLI documented at https://docs.extend.ai/cli”

   proof ↗⚑ flag

   Datalab✓fullprobed8/10

   Datalab exposes a REST API, Python SDK, and dedicated CLI for document conversion/extraction that can be scripted headlessly, plus webhooks to avoid polling and health-check endpoints for automation/CI monitoring. Missing for 10: independent hands-on evidence of CI pipeline usage (e.g., GitHub Actions example) and no discoverable OpenAPI spec for programmatic tooling.

   • [claimed-docs] “Use the Datalab CLI to convert documents from the command line.”
   • [probe] “official CLI documented at https://documentation.datalab.to/docs/welcome/sdk/cli”
   • [claimed-docs] “The Datalab Python SDK provides a simple interface for document conversion, pipelines, structured extraction, form filling, and file managem…”
   • [claimed-docs] “Webhooks provide real-time notifications when your document processing jobs complete, eliminating the need for continuous polling.”
   • [claimed-docs] “This endpoint is used to check the health of the API, given an API key.”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Extend—none0/10

   Extend documents 'Using Extend via MCP' (docs.extend.ai/mcp), which describes exposing Extend's own tools via MCP to other agents — this is the opposite direction of the story (product consuming external MCP servers as a client). No evidence shows Extend can ingest or plug in third-party MCP servers to use their tools.

   • [claimed-docs] “Using Extend via MCP | Extend Documentation”
   • [probe] “official MCP server documented at https://docs.extend.ai/mcp”

   proof ↗⚑ flag

   Datalab—none0/10

   No evidence anywhere in the pack of an official MCP server or MCP integration for Datalab; documentation covers SDK, CLI, webhooks, API endpoints, and on-prem deployment but never mentions MCP. As a document-processing API/platform, this axis is applicable (an official MCP server is plausible for such a product) but no evidence shows it exists, so absence of evidence means none rather than na.

   • [claimed-docs] “The Datalab Python SDK provides a simple interface for document conversion, pipelines, structured extraction, form filling, and file managem…”
   • [claimed-docs] “Use the Datalab CLI to convert documents from the command line.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://documentation.datalab.to/openapi.json, https://documentation.datalab.to/swagger.json, https:…”
   • [probe] “official CLI documented at https://documentation.datalab.to/docs/welcome/sdk/cli”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Extend
   Extend✓fullprobed8/10

   Extend is a document-processing platform (not an agent itself), and it documents an official MCP server ('Using Extend via MCP' at docs.extend.ai/mcp), confirmed by probe as live documentation, allowing AI agents to connect via MCP. missing for 10: no independent/hands-on confirmation of the MCP server working in practice, and limited detail on setup specifics beyond the doc title.

   • [claimed-docs] “Using Extend via MCP | Extend Documentation”
   • [probe] “official MCP server documented at https://docs.extend.ai/mcp”

   proof ↗⚑ flag

   Datalab—none0/10

   Datalab is a document conversion/extraction API with SDK, CLI, webhooks, and pipelines, but no evidence anywhere in the pack of an official MCP server or MCP integration for connecting AI agents. This axis applies since Datalab is a SaaS/API platform with an ecosystem where an MCP server would be plausible, but no such capability is documented.

   ⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Extend
   Extend✓fullprobed8/10

   Extend documents an official CLI at docs.extend.ai/cli, alongside SDKs and MCP support, indicating a first-party CLI exists for AI-native workflows. Missing for 10: no independent/hands-on confirmation of CLI usage or specific command examples beyond the docs listing page.

   • [claimed-docs] “CLI | Extend Documentation”
   • [probe] “official CLI documented at https://docs.extend.ai/cli”

   proof ↗⚑ flag

   Datalab✓fullprobed7/10

   Datalab documents an official CLI for converting documents from the command line, confirmed both in docs and a live probe of the CLI page. Missing for 10: no independent/hands-on corroboration of CLI usage, and no detail on CLI feature parity with the SDK (pipelines, extraction, etc.) beyond basic conversion.

   • [claimed-docs] “Use the Datalab CLI to convert documents from the command line.”
   • [probe] “official CLI documented at https://documentation.datalab.to/docs/welcome/sdk/cli”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Extend✓fullcommunity9/10

   Extend provides a documented public API with authentication, endpoints (upload, extract, classify, split, parse), sync/async modes, SDKs, CLI, and a dedicated API Quickstart, giving AI-native users a clear path to drive the product programmatically. Community feedback confirms real-world usage of the product's data extraction capabilities. missing for 10: independent third-party validation specifically of API robustness/rate limits beyond docs.

   • [claimed-docs] “Authenticate a request”
   • [claimed-docs] “SDKs | Extend Documentation”
   • [claimed-docs] “API Quickstart | Extend Documentation”
   • [claimed-docs] “This endpoint accepts file contents and registers them as a File in Extend, which can be used for running workflows, creating evaluation set…”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”
   • [claimed-docs] “CLI | Extend Documentation”
   • [community] “We've been using Extend for over a year and have been super happy with the product and accuracy of the data extraction.”

   proof ↗⚑ flag

   Datalab✓fullprobed9/10

   Datalab exposes a documented public API/SDK with explicit endpoints (convert, extract, segment, pipelines, webhooks, health check), plus CLI and Python SDK, all backed by extensive first-party API reference docs; a llms.txt probe confirms machine-readable docs discoverability. Minor gap: no formal OpenAPI/swagger spec was found (404s), so machine-consumable schema is less standardized. Missing for 10: a discoverable OpenAPI/swagger spec and independent third-party confirmation of API robustness.

   • [claimed-docs] “The Datalab Python SDK provides a simple interface for document conversion, pipelines, structured extraction, form filling, and file managem…”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Extract structured data from a document using a JSON schema.”
   • [claimed-docs] “Segment a document into sections using a schema. Returns page ranges for each identified segment.”
   • [claimed-docs] “Configure webhooks to receive real-time notifications when Datalab jobs complete.”
   • [claimed-docs] “Use the Datalab CLI to convert documents from the command line.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://documentation.datalab.to/llms.txt # Datalab Documentation - [Welcome to Datalab](https://documentation.…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://documentation.datalab.to/openapi.json, https://documentation.datalab.to/swagger.json, https:…”
   • [probe] “official CLI documented at https://documentation.datalab.to/docs/welcome/sdk/cli”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Extend—none0/10

   Evidence only shows basic API-key authentication (extend-docs-4) and a separate test-vs-production API key for sandboxing (extend-docs-38), but nothing about issuing scoped, role/permission-limited, or least-privilege credentials for individual agents (e.g., granular scopes, RBAC, per-agent key restrictions).

   ⚑ flag

   Datalab—none0/10

   Datalab's docs cover API keys, 2FA, and BAA/DPA but there is no evidence of scoped or least-privilege API credential issuance (e.g., role-based keys, permission scopes, or agent-specific tokens) for delegating limited access to an agent.

   ⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Extend✓fullclaimed8/10

   Extend documents an official Python SDK (pip install extend-ai), a dedicated SDKs docs page, API quickstart, authentication docs, and API reference endpoints, giving AI-native developers a clear official SDK path alongside CLI and MCP integrations. missing for 10: independent/hands-on developer corroboration of SDK usage beyond first-party docs, and multi-language SDK coverage details.

   • [claimed-docs] “pip install extend-ai”
   • [claimed-docs] “SDKs | Extend Documentation”
   • [claimed-docs] “API Quickstart | Extend Documentation”
   • [claimed-docs] “Authenticate a request”
   • [claimed-docs] “This endpoint accepts file contents and registers them as a File in Extend, which can be used for running workflows, creating evaluation set…”

   proof ↗⚑ flag

   Datalab✓fullprobed8/10

   Datalab documents an official Python SDK covering conversion, extraction, pipelines, form filling, and file management, plus an official CLI, giving AI-native developers first-party programmatic access to build against. Missing for 10: independent/hands-on developer corroboration beyond vendor docs, and no public OpenAPI/SDKs for other languages confirmed (openapi probe 404s).

   • [claimed-docs] “The Datalab Python SDK provides a simple interface for document conversion, pipelines, structured extraction, form filling, and file managem…”
   • [claimed-docs] “Use the Datalab CLI to convert documents from the command line.”
   • [claimed-docs] “Pipelines chain processors (convert, extract, segment, custom) into reusable, versioned configurations.”
   • [claimed-docs] “Datalab provides file storage for documents you want to process with pipelines or reuse across multiple API calls.”
   • [probe] “official CLI documented at https://documentation.datalab.to/docs/welcome/sdk/cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://documentation.datalab.to/openapi.json, https://documentation.datalab.to/swagger.json, https:…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Datalab
   Extend✓fullclaimed7/10

   Extend has a dedicated 'Webhook Configuration' documentation page and separately confirms webhooks fire on production runs (and are suppressed in test mode), showing an established webhook subscription mechanism for async events. Missing for 10: specifics on supported event types, payload schema, and independent/hands-on verification of webhook reliability.

   • [claimed-docs] “Webhook Configuration | Extend Documentation”
   • [claimed-docs] “Runs made with a test API key never touch production data and never fire production webhooks”
   • [claimed-docs] “Async Processing | Extend Documentation”

   proof ↗⚑ flag

   Datalab✓fullclaimed8/10

   Datalab has clear first-party docs for webhooks: real-time job-completion notifications avoiding polling, plus per-request webhook_url override support, directly matching the story's intent for event-driven/agentic integration. Missing for 10: no documented signature verification/security scheme details or independent/hands-on confirmation of webhook delivery reliability.

   • [claimed-docs] “Webhooks provide real-time notifications when your document processing jobs complete, eliminating the need for continuous polling.”
   • [claimed-docs] “You can override the default webhook URL for specific API requests by including the webhook_url parameter”
   • [claimed-docs] “Configure webhooks to receive real-time notifications when Datalab jobs complete.”
   • [claimed-docs] “You can override the default webhook URL for specific API requests by including the `webhook_url` parameter”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Extend
   Extend~partialclaimed6/10

   Extend's core AI extraction/classification pipeline generates structured data, per-field confidence scores that suggest which values to trust vs. route to human review, and citations pointing back to source locations — a form of AI-generated insight/suggestion from document data. However, there's no evidence of broader analytical insights, trend/summary generation, or proactive suggestions beyond the extraction/review-routing use case. Missing for 10: dedicated 'insights' or summary-generation feature, evidence of proactive suggestions beyond confidence-based review routing, and independent corroboration of this specific capability.

   • [claimed-docs] “Use them to trust high-confidence values automatically and route the rest to human review.”
   • [claimed-docs] “plus per-field confidence scores and citations that point back to the exact spot on the page”
   • [claimed-docs] “Agentic OCR”
   • [claimed-docs] “Parse, extract, and split your hardest documents with unmatched accuracy. Ship reliable document agents in minutes, not months.”
   • [claimed-docs] “Confidence Scores | Extend Documentation”

   proof ↗⚑ flag

   Datalab~partialclaimed4/10

   Datalab offers some AI-assisted automation—auto-generating extraction schemas for a document (datalab-docs-41) and running 'agent processors' on documents (datalab-docs-40)—which could be seen as AI suggesting how to interpret/extract data. However, there's no evidence of broader analytical insights, summaries, trend detection, or proactive suggestions about data content beyond structured extraction. missing for 10: evidence of AI-generated summaries/insights beyond schema suggestion, evidence of in-product analytics or pattern detection, and any independent corroboration of these agentic features actually surfacing insights to users.

   • [claimed-docs] “Run a published agent processor on a document. Address it with processor=<id>, optionally pinned to a version as <id>@<version>”
   • [claimed-docs] “For a given file, generate potential extraction schemas.”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Extend
   Extend~partialclaimed6/10

   Extend's Workflows feature (versioned, deployable pipelines) combined with async processing and webhook callbacks lets document-processing tasks run without a user waiting live, which is the core of 'background automation' — evidenced by extend-docs-19, extend-docs-12, extend-docs-13, extend-docs-37, extend-docs-43. However there's no explicit mention of scheduling/triggers (e.g., cron, event subscriptions beyond webhooks) or autonomous multi-step agent loops running unattended over time, so the 'autonomous' framing is only partially substantiated. Missing for 10: explicit scheduling/trigger mechanisms, evidence of long-running unattended agent loops, and independent confirmation that workflows execute fully autonomously without manual intervention.

   • [claimed-docs] “Workflows”
   • [claimed-docs] “Webhook Configuration | Extend Documentation”
   • [claimed-docs] “Async Processing | Extend Documentation”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”
   • [claimed-docs] “A workflow has one editable draft and any number of immutable deployed versions.”

   proof ↗⚑ flag

   Datalab~partialclaimed5/10

   Datalab supports background, non-blocking automation via webhooks (eliminating polling) and 'Pipelines' that chain processors into versioned, reusable configurations deployable to production, plus a 'run document agent' endpoint for published agent processors — these together allow document workflows to run unattended once triggered. However there is no evidence of scheduling, event-based triggers, or a true autonomous loop that decides when/what to run without an external caller invoking the API. Missing for 10: scheduling/cron or event-trigger mechanisms, evidence of multi-step autonomous decision-making beyond a single processor call, and independent confirmation of pipelines running unattended in production.

   • [claimed-docs] “Webhooks provide real-time notifications when your document processing jobs complete, eliminating the need for continuous polling.”
   • [claimed-docs] “You can override the default webhook URL for specific API requests by including the webhook_url parameter”
   • [claimed-docs] “Pipelines — Chain processors into versioned, reusable configurations and deploy to production”
   • [claimed-docs] “Pipelines chain processors (convert, extract, segment, custom) into reusable, versioned configurations.”
   • [claimed-docs] “Run a published agent processor on a document. Address it with processor=<id>, optionally pinned to a version as <id>@<version>”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Extend
   Extend~partialclaimed5/10

   Extend markets built-in agentic features like "Composer & Review Agent," "Agentic OCR," and "Agent form filling," plus an "Agent Quickstart" guide, suggesting users can delegate document-processing tasks to built-in AI agents. However, there's no clear evidence of a general-purpose conversational AI assistant inside the product UI for delegating arbitrary tasks — the agentic features are narrowly scoped to document extraction/review workflows. Missing for 10: a documented chat/assistant interface, examples of delegating broader tasks beyond document processing, and independent hands-on confirmation of these agent features in use.

   • [claimed-docs] “Composer & Review Agent”
   • [claimed-docs] “Agentic OCR”
   • [claimed-docs] “Agent form filling”
   • [claimed-docs] “Agent Quickstart | Extend Documentation”
   • [claimed-docs] “Ship reliable document agents in minutes, not months.”

   proof ↗⚑ flag

   Datalab—none0/10

   Datalab is a document conversion/extraction API and SDK; the closest evidence is a 'document agent' processor endpoint for running pre-built document pipelines (datalab-docs-40), which is task automation on documents, not an interactive built-in assistant that a user can delegate open-ended tasks to. No docs describe a chat-based or conversational AI assistant embedded in the product for general task delegation.

   • [claimed-docs] “Run a published agent processor on a document. Address it with processor=<id>, optionally pinned to a version as <id>@<version>”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Extend
   Extend~partialprobed6/10

   Extend documents an official MCP server and Agent Quickstart, which allow AI agents/assistants to drive the platform via natural-language tool calls rather than raw API calls, and it also ships a CLI for programmatic control. However, there is no first-party example or independent corroboration showing an end-user issuing free-form natural-language commands and Extend interpreting/executing them directly. Missing for 10: concrete examples of natural-language command execution, independent/hands-on validation of the MCP/agent workflow.

   • [claimed-docs] “Using Extend via MCP | Extend Documentation”
   • [claimed-docs] “Agent Quickstart | Extend Documentation”
   • [probe] “official MCP server documented at https://docs.extend.ai/mcp”
   • [probe] “official CLI documented at https://docs.extend.ai/cli”
   • [claimed-docs] “CLI | Extend Documentation”

   proof ↗⚑ flag

   Datalab—none0/10

   Datalab's evidence only shows a structured REST API, Python SDK, and CLI for document conversion/extraction — all requiring code or CLI syntax, not natural-language commands. No chat-based interface, NL command layer, or agent-facing conversational control surface is documented anywhere in the evidence pack.

   • [claimed-docs] “The Datalab Python SDK provides a simple interface for document conversion, pipelines, structured extraction, form filling, and file managem…”
   • [claimed-docs] “Use the Datalab CLI to convert documents from the command line.”
   • [probe] “official CLI documented at https://documentation.datalab.to/docs/welcome/sdk/cli”
   • [claimed-docs] “Run a published agent processor on a document. Address it with processor=<id>, optionally pinned to a version as <id>@<version>”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Datalab
   Extend~partialclaimed4/10

   Extend has a documented API reference (authentication, endpoints like upload-file, quickstarts) and SDKs/CLI, but there's no evidence of an interactive 'try it' console or runnable code examples embedded in the docs. missing for 10: explicit interactive API playground, in-browser runnable examples, live request/response testing.

   • [claimed-docs] “Authenticate a request”
   • [claimed-docs] “API Quickstart | Extend Documentation”
   • [claimed-docs] “This endpoint accepts file contents and registers them as a File in Extend, which can be used for running workflows, creating evaluation set…”
   • [claimed-docs] “SDKs | Extend Documentation”
   • [claimed-docs] “CLI | Extend Documentation”

   proof ↗⚑ flag

   Datalab~partialprobed5/10

   Datalab publishes detailed API reference pages (convert-document, extract-structured-data, segment-document, create-document, run-document-agent, etc.) and offers a separate 'Forge' playground where users can upload documents and see results instantly without an API key, giving some interactive/try-it-now experience. However, a probe for a standard OpenAPI/Swagger spec (which typically powers runnable 'try it' examples embedded directly in API reference pages) returned 404s across all candidate paths, and no evidence shows executable code samples or a live 'run this request' widget within the API reference itself. Missing for 10: an OpenAPI/Swagger spec or embedded runnable request builder directly in the API reference docs, and confirmation that Forge is linked/integrated with the reference pages rather than a separate playground.

   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Extract structured data from a document using a JSON schema.”
   • [claimed-docs] “Segment a document into sections using a schema. Returns page ranges for each identified segment.”
   • [claimed-docs] “Want to try before writing code? Upload a document to Forge to see results instantly — no API key required.”
   • [claimed-docs] “Upload a document to Forge to see results instantly — no API key required.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://documentation.datalab.to/openapi.json, https://documentation.datalab.to/swagger.json, https:…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Extend—none0/10

   Extend documents a full API reference, authentication, and multiple endpoints, but no evidence pack item mentions a downloadable OpenAPI/Swagger spec or any machine-readable API definition file. missing for 10: OpenAPI/Swagger spec file, documented spec download link, machine-readable API schema.

   ⚑ flag

   Datalab—none0/10

   Datalab has a full REST API reference (convert, extract, segment, webhooks, etc.) but a direct probe for standard OpenAPI/Swagger spec locations (openapi.json, swagger.json, etc.) returned 404 across all checked paths, and no evidence of a downloadable machine-readable spec file was found anywhere in the docs.

   • [probe] “PROBE openapi: all candidate paths 404 (https://documentation.datalab.to/openapi.json, https://documentation.datalab.to/swagger.json, https:…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://documentation.datalab.to/llms.txt # Datalab Documentation - [Welcome to Datalab](https://documentation.…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Extend
   Extend✓fullclaimed8/10

   Extend explicitly documents a test environment where runs made with a test API key never touch production data and never fire production webhooks, directly matching the sandbox story. missing for 10: no independent/hands-on corroboration of the test-key isolation beyond first-party docs, and no detail on how thoroughly sandbox data mirrors production for realistic testing.

   • [claimed-docs] “Runs made with a test API key never touch production data and never fire production webhooks”

   proof ↗⚑ flag

   Datalab~partialclaimed4/10

   Datalab offers a free-tier Forge playground and a monthly usage allowance explicitly framed for running a 'proof of concept' without a credit card, letting users try conversions before committing to production workflows (datalab-docs-9, datalab-docs-10, datalab-docs-23, datalab-docs-42). However, there is no dedicated 'sandbox environment' concept, no separate test API keys/staging tier, and no mention of isolating test runs from production billing/data pipelines. Missing for 10: an explicit sandbox/staging mode, test-vs-production API key separation, and confirmation that sandbox usage doesn't touch production data stores or billing.

   • [claimed-docs] “Want to try before writing code? Upload a document to Forge to see results instantly — no API key required.”
   • [claimed-docs] “new accounts include a **free monthly usage allowance** (no credit card required), enough to run a full proof of concept on your own documen…”
   • [claimed-docs] “Upload a document to Forge to see results instantly — no API key required.”
   • [claimed-docs] “new accounts include a **free monthly usage allowance** (no credit card required)”
   • [claimed-docs] “In-app playground renamed from “Forge Playground” to **Forge** (`/app/playground`).”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Extend—none0/10

   Evidence shows versioning for internal artifacts (processors, workflows, base models) but no documentation of API endpoint versioning (e.g., v1/v2 paths) or any deprecation/sunset policy for the REST API/SDK itself.

   • [claimed-docs] “the thing you version and iterate on in Extend Studio, and the unit you evaluate and optimize”
   • [claimed-docs] “A workflow has one editable draft and any number of immutable deployed versions.”
   • [claimed-docs] “Base model versions are Extend's underlying model releases, selected with the baseVersion config field.”
   • [claimed-docs] “Authenticate a request”
   • [claimed-docs] “API Quickstart | Extend Documentation”

   proof ↗⚑ flag

   Datalab—none0/10

   While Datalab documents processor/pipeline versioning (e.g., pinning to id@version, versioned pipeline configs) and maintains a changelog, there is no evidence of a documented API versioning scheme (e.g., v1/v2 endpoints) or an explicit deprecation policy for its APIs.

   • [claimed-docs] “Run a published agent processor on a document. Address it with processor=<id>, optionally pinned to a version as <id>@<version>”
   • [claimed-docs] “Pipelines chain processors (convert, extract, segment, custom) into reusable, versioned configurations.”
   • [claimed-docs] “Track Changes is now available in the Playground — upload a DOCX, PDF, or image file to preview tracked changes extraction results directly …”
   • [claimed-docs] “In-app playground renamed from “Forge Playground” to **Forge** (`/app/playground`).”
   • [probe] “PROBE openapi: all candidate paths 404 (https://documentation.datalab.to/openapi.json, https://documentation.datalab.to/swagger.json, https:…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Extend
   Extend~partialclaimed6/10

   Extend supports batch-like operations via multifile extraction (run over a collection of files with shared context), async processing endpoints for extract/classify/split/parse/edit, and evaluation set runs that score a processor against every item in a set — all pointing to bulk/batch capability across many documents. However, there's no explicit documentation of a bulk API endpoint for arbitrary large-scale item batches, rate limits/throughput guarantees, or dedicated bulk-operations tooling beyond these features. missing for 10: dedicated bulk-operation API/endpoint documentation, throughput/scale guarantees, independent hands-on evidence of large-scale bulk runs.

   • [claimed-docs] “Multifile extraction lets you run a single extraction over a collection of files with a shared context.”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”
   • [claimed-docs] “An evaluation set run scores one processor version against every item in an evaluation set and returns aggregate metrics”
   • [claimed-docs] “Async Processing | Extend Documentation”

   proof ↗⚑ flag

   Datalab~partialclaimed5/10

   Datalab's SDK, CLI, and pipelines allow scripting repeated calls across many documents, and webhooks let jobs run asynchronously without polling, which supports processing many items programmatically. However, there is no explicit documented 'bulk' or 'batch' API endpoint that accepts multiple files/items in a single call — evidence only shows single-document convert/extract/segment endpoints and file storage for reuse. Missing for 10: a dedicated batch/bulk-submission endpoint, documented concurrency/throughput limits for large-scale runs, and any hands-on/community confirmation of successful large-batch processing.

   • [claimed-docs] “The Datalab Python SDK provides a simple interface for document conversion, pipelines, structured extraction, form filling, and file managem…”
   • [claimed-docs] “Use the Datalab CLI to convert documents from the command line.”
   • [claimed-docs] “Webhooks provide real-time notifications when your document processing jobs complete, eliminating the need for continuous polling.”
   • [claimed-docs] “Datalab provides file storage for documents you want to process with pipelines or reuse across multiple API calls.”
   • [claimed-docs] “Pipelines chain processors (convert, extract, segment, custom) into reusable, versioned configurations.”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Extend
   Extend~partialclaimed5/10

   Extend supports webhooks to fire on processing events and has a Workflows system with versioning, which lets users react to events (e.g., file processed, extraction complete) with automated actions, but there's no documented general-purpose rule engine for defining custom trigger-condition-action logic across arbitrary events. Missing for 10: an explicit rules/conditions builder beyond simple webhook firing, and evidence of triggering on non-document events.

   • [claimed-docs] “Webhook Configuration | Extend Documentation”
   • [claimed-docs] “Workflows”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”
   • [claimed-docs] “A workflow has one editable draft and any number of immutable deployed versions.”

   proof ↗⚑ flag

   Datalab~partialclaimed4/10

   Datalab supports webhooks that fire automatically when processing jobs complete, and pipelines let you chain processors into reusable workflows, giving some event-driven automation. However, there's no evidence of a genuine rules engine where users define arbitrary conditions/triggers (e.g., 'if field X extracted equals Y, then run Z') beyond job-completion notifications and static pipeline chains. Missing for 10: conditional rule definition (if/then logic), custom event types beyond job completion, and any UI/API for user-defined trigger conditions.

   • [claimed-docs] “Webhooks provide real-time notifications when your document processing jobs complete, eliminating the need for continuous polling.”
   • [claimed-docs] “You can override the default webhook URL for specific API requests by including the webhook_url parameter”
   • [claimed-docs] “Configure webhooks to receive real-time notifications when Datalab jobs complete.”
   • [claimed-docs] “Pipelines chain processors (convert, extract, segment, custom) into reusable, versioned configurations.”
   • [claimed-docs] “Chain processors into versioned, reusable configurations and deploy to production”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Extend—none0/10

   Extend documents workflows, webhooks, and async processing, but no evidence of a scheduling mechanism (cron-like triggers, recurring runs) for workflows or jobs. Missing for 10: any mention of scheduled/recurring workflow triggers, cron configuration, or time-based automation.

   • [claimed-docs] “Workflows”
   • [claimed-docs] “Webhook Configuration | Extend Documentation”
   • [claimed-docs] “Async Processing | Extend Documentation”
   • [claimed-docs] “A workflow has one editable draft and any number of immutable deployed versions.”

   proof ↗⚑ flag

   Datalab—none0/10

   Datalab is a document conversion/extraction API with webhooks, pipelines, and SDK/CLI, but no evidence exists of a scheduling or recurring-job/workflow trigger mechanism (e.g., cron-like scheduling, recurring pipeline execution). Users must invoke conversions/pipelines via API calls triggered externally, not natively scheduled.

   ⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Extend
   Extend~partialclaimed6/10

   Extend documents concrete versioning for workflows ("one editable draft and any number of immutable deployed versions"), processors ("the thing you version and iterate on in Extend Studio"), and evaluation sets scoring specific processor versions — this covers version and review well. However, there is no explicit evidence of a rollback mechanism (reverting a deployed workflow/processor to a prior version) or of review workflows like diffs/approval gates beyond the Composer & Review Agent mention. missing for 10: explicit rollback/revert capability, diff/audit view between versions, independent confirmation of these versioning features in practice.

   • [claimed-docs] “the thing you version and iterate on in Extend Studio, and the unit you evaluate and optimize”
   • [claimed-docs] “A workflow has one editable draft and any number of immutable deployed versions.”
   • [claimed-docs] “Evaluation sets let you test the accuracy of your document processors reliably and repeatedly.”
   • [claimed-docs] “An evaluation set run scores one processor version against every item in an evaluation set and returns aggregate metrics”
   • [claimed-docs] “you save that config once as a processor, give it a stable id, and reference it from then on”
   • [claimed-docs] “Composer & Review Agent”

   proof ↗⚑ flag

   Datalab~partialclaimed3/10

   Datalab's Pipelines feature is explicitly described as creating 'versioned, reusable configurations' for chaining processors, and agent processors can be pinned to a specific version (id@version), showing some versioning capability. However, there is no evidence of a review workflow (diffing/approving changes) or an explicit rollback mechanism to revert a pipeline to a prior version. Missing for 10: review/audit UI for pipeline changes, explicit rollback/revert functionality, version history browsing.

   • [claimed-docs] “Pipelines — Chain processors into versioned, reusable configurations and deploy to production”
   • [claimed-docs] “Chain processors into versioned, reusable configurations and deploy to production”
   • [claimed-docs] “Pipelines chain processors (convert, extract, segment, custom) into reusable, versioned configurations.”
   • [claimed-docs] “Run a published agent processor on a document. Address it with processor=<id>, optionally pinned to a version as <id>@<version>”

   proof ↗⚑ flag

Compliance

1. data engineerUploaded documents get zero-retention handling with SOC 2 and HIPAA options, so I can process contracts and medical records

   weight 3 · round to Extend
   Extend✓fullclaimed8/10

   Extend's docs explicitly document SOC 2 Type II alignment, HIPAA (with BAA add-on) and GDPR compliance, plus configurable zero data retention (including for AI subprocessors) at the workspace level, directly matching the data-engineer's need to process contracts and medical records securely. Missing for 10: independent third-party audit confirmation or hands-on customer verification of ZDR/HIPAA in production use beyond vendor docs.

   • [claimed-docs] “Compliance: "We maintain controls aligned with SOC 2 Type II requirements. Reports and security documentation are available in the Trust Cen…”
   • [claimed-docs] “Data handling, Zero Data retention: "We maintain automatic data-retention policies that vary in default length by billing tier and can be co…”
   • [claimed-docs] “Compliance | Extend Documentation”
   • [claimed-docs] “Data Handling | Extend Documentation”
   • [claimed-docs] “Zero data retention”
   • [claimed-docs] “HIPAA Compliance and BAA add-on”

   proof ↗⚑ flag

   Datalab~partialclaimed5/10

   Datalab documents privacy-oriented options — Team plan includes 'BAA/DPA', and Enterprise offers on-prem/air-gapped deployment for 'highly-regulated environments' — which implicitly supports HIPAA-related contract needs, but there is no explicit mention of a zero-retention data policy or SOC 2 certification anywhere in the evidence pack. Missing for 10: explicit zero-retention/data-deletion policy statement, explicit SOC 2 attestation/report, explicit HIPAA compliance language (only BAA is named).

   • [claimed-docs] “On-prem overview: "Customers can run our models on infrastructure they control with an Enterprise contract." The paid on-prem options target…”
   • [claimed-docs] “Pricing page: the Team plan ($400/mo) lists "BAA / DPA" as included, alongside 400 req/min rate limits; Enterprise adds running on your own …”
   • [claimed-docs] “Customers can run our models on infrastructure they control with an Enterprise contract.”
   • [claimed-docs] “A Helm chart is available for deploying the container on Kubernetes clusters.”

   proof ↗⚑ flag

Deployment

1. data engineerRun the extraction stack in my own VPC or fully self-hosted when documents can't leave my infrastructure

   weight 2 · round to Datalab
   Extend~partialclaimed5/10

   Pricing page explicitly lists 'BYOC (your VPC) and Hybrid deployments' as an offering, indicating self-hosted/VPC deployment options exist, but there is no dedicated documentation detailing setup, architecture, or infrastructure requirements for such deployments, and no independent/hands-on confirmation. missing for 10: detailed self-hosting/VPC deployment docs, architecture guides, independent confirmation of BYOC actually working, clarity on which components run in customer VPC vs SaaS.

   • [claimed-docs] “BYOC (your VPC) and Hybrid deployments”

   proof ↗⚑ flag

   Datalab✓fullclaimed7/10

   Datalab explicitly offers on-prem/self-hosted deployment via Enterprise contract, including a Helm chart for Kubernetes and air-gapped operation on customer infrastructure, plus BAA/DPA for compliance-sensitive plans. Missing for 10: independent/hands-on verification that self-hosted deployment works as documented, and more detail on VPC-specific deployment beyond 'air-gapped' Enterprise mention.

   • [claimed-docs] “Customers can run our models on infrastructure they control with an Enterprise contract.”
   • [claimed-docs] “On-prem overview: "Customers can run our models on infrastructure they control with an Enterprise contract." The paid on-prem options target…”
   • [claimed-docs] “Pricing page: the Team plan ($400/mo) lists "BAA / DPA" as included, alongside 400 req/min rate limits; Enterprise adds running on your own …”
   • [claimed-docs] “A Helm chart is available for deploying the container on Kubernetes clusters.”
   • [claimed-docs] “New surya-us on-premises container type — a lightweight Chandra-compatible container”

   proof ↗⚑ flag

Formats

1. developerOne API handles my whole document mix — PDF, DOCX, PPTX, XLSX, HTML, images, email — without per-format plumbing

   weight 2 · round drawn
   Extend~partialclaimed6/10

   Extend documents a single API surface (extract, classify, split, parse, edit) that ingests uploaded files and auto-converts Word/PowerPoint to PDF, and maintains a dedicated 'Supported File Types' doc, showing a unified pipeline for mixed document types. However, the evidence never explicitly confirms XLSX, HTML, or email format support, or shows a worked example spanning all these formats without extra plumbing. Missing for 10: explicit confirmation of XLSX/HTML/email support, and hands-on proof of one-call handling across all listed formats.

   • [claimed-docs] “Supported File Types | Extend Documentation”
   • [claimed-docs] “This endpoint accepts file contents and registers them as a File in Extend, which can be used for running workflows, creating evaluation set…”
   • [claimed-docs] “If an uploaded file is detected as a Word or PowerPoint document, it will be automatically converted to a PDF.”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”

   proof ↗⚑ flag

   Datalab~partialcommunity6/10

   Datalab's single convert/extract API explicitly covers PDFs, images, Word docs (DOCX) and spreadsheets (XLSX) through one endpoint (datalab-docs-17, datalab-docs-31), fitting the 'one API for document mix' story. However, the evidence never explicitly confirms PPTX, HTML-as-input, or email formats being handled by the same pipeline, and community evidence flags OCR round-trip limitations for at least one output type. Missing for 10: explicit PPTX support, HTML/email as input formats, and independent confirmation of true format-agnostic handling without per-format quirks.

   • [claimed-docs] “Parse PDFs, Word docs, and spreadsheets into Markdown, HTML, or JSON”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “The SDK provides a simple interface to convert documents to Markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “The Datalab Python SDK provides a simple interface for document conversion, pipelines, structured extraction, form filling, and file managem…”
   • [community] “On Datalab's Chandra-OCR: 'it doesn't follow what I consider to be a fundamental OCR rule: the input document type should also be a possible…”

   proof ↗⚑ flag

Scale limits

1. data engineerThousand-page documents and multi-gigabyte files process reliably without timeouts or silent truncation

   weight 2 · round to Extend
   Extend~partialclaimed6/10

   Extend explicitly advertises 2,000+ page support, async processing for all endpoints (to avoid timeouts on long jobs), and automatic Word/PPT-to-PDF conversion, plus a test environment guide—strong first-party evidence targeting large-document reliability. However, there's no explicit mention of multi-gigabyte file size limits, chunking/truncation safeguards for extremely large files, or independent/hands-on confirmation that thousand-page or multi-GB documents process without silent truncation. missing for 10: independent verification of large-file handling, explicit multi-GB file size limits/support, evidence of no silent truncation on very large inputs.

   • [claimed-docs] “2,000+ page support”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”
   • [claimed-docs] “If an uploaded file is detected as a Word or PowerPoint document, it will be automatically converted to a PDF.”
   • [claimed-docs] “Runs made with a test API key never touch production data and never fire production webhooks”
   • [claimed-docs] “Async Processing | Extend Documentation”

   proof ↗⚑ flag

   Datalab~partialclaimed5/10

   Datalab documents explicit size/page limits and instructs users to manually segment large documents using page_range, plus checkpoint/save_checkpoint features to avoid re-parsing — indicating large-file handling requires workarounds rather than being fully automatic and reliable out-of-the-box. Missing for 10: explicit evidence of automatic handling of thousand-page or multi-gigabyte files without truncation, documented timeout limits/behavior, and independent confirmation of reliability at scale.

   • [claimed-docs] “For documents exceeding these limits, use the page_range parameter to process in segments”
   • [claimed-docs] “Use save_checkpoint=true to save parsed state for later /extract or /segment calls.”
   • [claimed-docs] “Provide a file for end-to-end processing, or a checkpoint_id from a previous /convert call to skip re-parsing.”

   proof ↗⚑ flag

Languages

1. developerNon-English documents — including CJK and right-to-left scripts — parse with the same fidelity as English

   weight 2 · round drawn
   Extend—none0/10

   No evidence in the pack addresses multilingual or CJK/RTL document parsing fidelity; all citations cover general parsing, extraction, SDKs, compliance, and pricing without mentioning language coverage.

   ⚑ flag

   Datalab—none0/10

   The evidence pack covers Datalab's conversion, extraction, segmentation, and pipeline features but contains no mention of CJK, right-to-left scripts, or multilingual OCR fidelity at all. Since document parsing/OCR fairly raises the question of non-English script support, this is an applicable axis with no supporting evidence, not a category mismatch.

   ⚑ flag

Ocr

1. developerHandwritten fields and annotations are recognized and extracted, flagged with confidence when uncertain

   weight 1 · round to Extend
   Extend~partialclaimed6/10

   Extend explicitly advertises handwriting detection ('Detect tables, checkboxes, images, and handwriting') and 'Agentic OCR' as pricing features, plus a documented Confidence Scores mechanism that lets low-confidence extractions route to human review. However, there is no direct documentation showing handwritten field values are specifically flagged with lower confidence or examples of handwriting-specific extraction accuracy/behavior. Missing for 10: dedicated documentation or examples of handwriting-specific extraction accuracy, confidence flagging tied specifically to handwritten content, and independent/hands-on verification of handwriting OCR quality.

   • [claimed-docs] “Detect tables, checkboxes, images, and handwriting”
   • [claimed-docs] “Agentic OCR”
   • [claimed-docs] “Confidence Scores | Extend Documentation”
   • [claimed-docs] “Use them to trust high-confidence values automatically and route the rest to human review.”
   • [claimed-docs] “plus per-field confidence scores and citations that point back to the exact spot on the page”

   proof ↗⚑ flag

   Datalab—none0/10

   The evidence pack covers structured extraction, form filling, track changes, and bounding-box citations, but nowhere mentions handwriting recognition specifically or confidence scoring/flagging for uncertain extractions. Missing for 10: any documentation of handwritten text/field recognition, any confidence score or uncertainty flag in extraction output.

   ⚑ flag

2. developerScanned and photographed documents OCR accurately — skewed pages, stamps, low quality scans included

   weight 3 · round to Extend
   Extend~partialcommunity6/10

   Extend markets itself as handling 'your hardest documents with unmatched accuracy' with agentic OCR, handwriting/table/checkbox detection, and confidence-based routing to human review, and a year-long HN user reports being happy with extraction accuracy. However no evidence specifically addresses skewed pages, stamps, or low-quality scan handling — these document conditions are never explicitly mentioned in docs or community feedback. Missing for 10: explicit documentation or benchmarks on skew correction, stamp/seal recognition, and degraded scan quality performance, plus independent hands-on testing on such documents.

   • [claimed-docs] “Parse, extract, and split your hardest documents with unmatched accuracy. Ship reliable document agents in minutes, not months.”
   • [claimed-docs] “Detect tables, checkboxes, images, and handwriting”
   • [claimed-docs] “Agentic OCR”
   • [claimed-docs] “Use them to trust high-confidence values automatically and route the rest to human review.”
   • [claimed-docs] “plus per-field confidence scores and citations that point back to the exact spot on the page”
   • [community] “We've been using Extend for over a year and have been super happy with the product and accuracy of the data extraction.”

   proof ↗⚑ flag

   Datalab—none0/10

   Datalab's docs describe general document/image-to-markdown conversion (Marker, Surya, Chandra) but nowhere claim or demonstrate robustness on skewed pages, stamps, or low-quality/photographed scans specifically. The only community evidence found (HN comment on Chandra-OCR) criticizes a different limitation (lack of PDF-to-PDF round-tripping), not scan-quality accuracy, so it neither confirms nor disputes this specific axis. Missing for 10: any benchmark, docs section, or hands-on report addressing accuracy on skewed/rotated pages, stamped documents, or noisy photographed scans.

   • [claimed-docs] “Get started with Datalab to convert PDFs, images, and documents into Markdown, HTML, or JSON in minutes.”
   • [claimed-docs] “Parse PDFs, Word docs, and spreadsheets into Markdown, HTML, or JSON”
   • [community] “On Datalab's Chandra-OCR: 'it doesn't follow what I consider to be a fundamental OCR rule: the input document type should also be a possible…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Datalab
   Extend~partialclaimed6/10

   Extend documents a broad API/SDK/CLI/MCP surface covering the same core objects seen in its UI (processors, workflows with versioning, evaluation sets, extraction/classification/splitting, file upload) suggesting close UI-API parity, but there is no explicit statement of full parity and UI-centric tools like Studio's interactive testing and the Composer & Review Agent (human-in-the-loop) are not shown to have a documented equivalent API path. missing for 10: explicit parity claim/documentation, API equivalents for Studio interactive iteration and Composer/Review Agent workflows, independent confirmation of full coverage.

   • [claimed-docs] “CLI | Extend Documentation”
   • [claimed-docs] “Using Extend via MCP | Extend Documentation”
   • [claimed-docs] “SDKs | Extend Documentation”
   • [claimed-docs] “API Quickstart | Extend Documentation”
   • [claimed-docs] “Agent Quickstart | Extend Documentation”
   • [claimed-docs] “you save that config once as a processor, give it a stable id, and reference it from then on”
   • [claimed-docs] “the thing you version and iterate on in Extend Studio, and the unit you evaluate and optimize”
   • [claimed-docs] “Evaluation sets let you test the accuracy of your document processors reliably and repeatedly.”
   • [claimed-docs] “A workflow has one editable draft and any number of immutable deployed versions.”
   • [claimed-docs] “Composer & Review Agent”

   proof ↗⚑ flag

   Datalab✓fullprobed8/10

   Datalab UI (Forge/Playground) is explicitly a preview layer for the same processors (convert, extract, segment, pipelines, form filling, track changes) that are fully documented as API and SDK endpoints, with no UI-only feature lacking an API path. Missing for 10: a discoverable OpenAPI/swagger spec (probe found 404s) and an explicit vendor statement guaranteeing full UI/API parity.

   • [claimed-docs] “Want to try before writing code? Upload a document to Forge to see results instantly — no API key required.”
   • [claimed-docs] “Track Changes is now available in the Playground — upload a DOCX, PDF, or image file to preview tracked changes extraction results directly …”
   • [claimed-docs] “The Datalab Python SDK provides a simple interface for document conversion, pipelines, structured extraction, form filling, and file managem…”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Extract structured data from a document using a JSON schema.”
   • [claimed-docs] “Segment a document into sections using a schema. Returns page ranges for each identified segment.”
   • [claimed-docs] “Pipelines chain processors (convert, extract, segment, custom) into reusable, versioned configurations.”
   • [claimed-docs] “Create a DOCX document from markdown with track changes support. Supports <ins>, <del>, and <comment> tags.”
   • [claimed-docs] “Run a published agent processor on a document. Address it with processor=<id>, optionally pinned to a version as <id>@<version>”
   • [probe] “PROBE openapi: all candidate paths 404 (https://documentation.datalab.to/openapi.json, https://documentation.datalab.to/swagger.json, https:…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Datalab
   Extend—none0/10

   Extend is a SaaS document-processing platform holding workflows, processors, evaluation sets and extracted data, so data-portability/export is a fair question, but the evidence pack contains no mention of a bulk data-export feature, open-format export of processed data/configs, or account-closure data dump — only retention/ZDR policies which describe deletion, not export.

   • [claimed-docs] “Data handling, Zero Data retention: "We maintain automatic data-retention policies that vary in default length by billing tier and can be co…”
   • [claimed-docs] “Data Handling | Extend Documentation”

   proof ↗⚑ flag

   Datalab~partialclaimed6/10

   Datalab's core function is converting documents into open, non-proprietary formats (Markdown, HTML, JSON) and its underlying models (Marker, Surya, Chandra) remain open source, and file/pipeline management APIs let users manage and retrieve their processed data. However, there is no explicit documentation of a bulk 'export all account data' or account-closure data-portability feature—only per-document conversion outputs and file storage APIs. Missing for 10: explicit account-level data export/deletion tooling, evidence of exporting stored pipeline configs/history, and independent confirmation of full data portability.

   • [claimed-docs] “Get started with Datalab to convert PDFs, images, and documents into Markdown, HTML, or JSON in minutes.”
   • [claimed-docs] “Parse PDFs, Word docs, and spreadsheets into Markdown, HTML, or JSON”
   • [claimed-docs] “The SDK provides a simple interface to convert documents to Markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Datalab provides file storage for documents you want to process with pipelines or reuse across multiple API calls.”
   • [claimed-docs] “On-prem overview: "Customers can run our models on infrastructure they control with an Enterprise contract." The paid on-prem options target…”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Datalab
   Extend~partialclaimed3/10

   Extend is a closed SaaS platform; the only evidence bearing on self-hosting is a pricing-page bullet mentioning 'BYOC (your VPC) and Hybrid deployments' as an enterprise add-on, with no documentation of installation, source availability, or a true self-managed deployment path. Missing for 10: open-source or downloadable core product, self-hosting setup docs, infrastructure requirements, and independent confirmation that customers can run it fully outside Extend's cloud.

   • [claimed-docs] “BYOC (your VPC) and Hybrid deployments”

   proof ↗⚑ flag

   Datalab~partialclaimed5/10

   Datalab documents genuine on-prem deployment (Helm chart for Kubernetes, on-prem containers, air-gapped Enterprise option) confirming self-hosting is technically possible, and the underlying models (Chandra, Marker, Surya) are free open source. However, running the full core product on your own infrastructure is explicitly gated behind an Enterprise sales contract rather than being freely self-hostable by any AI-native user. Missing for 10: evidence of an accessible/self-serve self-hosted deployment path (e.g., public Docker image with docs, license terms) without requiring a sales contract, and independent confirmation of successful self-hosted setups.

   • [claimed-docs] “Customers can run our models on infrastructure they control with an Enterprise contract.”
   • [claimed-docs] “On-prem overview: "Customers can run our models on infrastructure they control with an Enterprise contract." The paid on-prem options target…”
   • [claimed-docs] “Pricing page: the Team plan ($400/mo) lists "BAA / DPA" as included, alongside 400 req/min rate limits; Enterprise adds running on your own …”
   • [claimed-docs] “A Helm chart is available for deploying the container on Kubernetes clusters.”
   • [claimed-docs] “New surya-us on-premises container type — a lightweight Chandra-compatible container”

   proof ↗⚑ flag

Evals

1. ml engineerThe vendor publishes reproducible accuracy benchmarks and I can run my own evals before committing

   weight 1 · round to Extend
   Extend~partialcommunity5/10

   Extend documents a full self-serve evaluation framework (evaluation sets, processors, versioning, aggregate metrics from evaluation-set runs) that lets an ML engineer run their own accuracy evals before committing, and community testimony corroborates strong extraction accuracy in practice. However there is no evidence of the vendor publishing its own reproducible benchmark numbers/datasets or accuracy reports for independent verification. Missing for 10: vendor-published benchmark results/methodology, third-party benchmark validation, public accuracy leaderboards or comparable datasets.

   • [claimed-docs] “Evaluation sets let you test the accuracy of your document processors reliably and repeatedly.”
   • [claimed-docs] “An evaluation set run scores one processor version against every item in an evaluation set and returns aggregate metrics”
   • [claimed-docs] “you save that config once as a processor, give it a stable id, and reference it from then on”
   • [claimed-docs] “the thing you version and iterate on in Extend Studio, and the unit you evaluate and optimize”
   • [community] “We've been using Extend for over a year and have been super happy with the product and accuracy of the data extraction.”

   proof ↗⚑ flag

   Datalab—none0/10

   Evidence shows only that users can try the product via free allowance/Forge to run their own proof-of-concept (datalab-docs-9, datalab-docs-10, datalab-docs-23, datalab-docs-42), but there is no evidence of vendor-published reproducible accuracy benchmarks (e.g., against ground-truth datasets, competitor comparisons, or accuracy metrics). A community comment even flags difficulty in groundtruthing Datalab's OCR output (datalab-comm-1), reinforcing the absence of published benchmark data.

   • [claimed-docs] “Want to try before writing code? Upload a document to Forge to see results instantly — no API key required.”
   • [claimed-docs] “new accounts include a **free monthly usage allowance** (no credit card required), enough to run a full proof of concept on your own documen…”
   • [claimed-docs] “Upload a document to Forge to see results instantly — no API key required.”
   • [claimed-docs] “new accounts include a **free monthly usage allowance** (no credit card required)”
   • [community] “On Datalab's Chandra-OCR: 'it doesn't follow what I consider to be a fundamental OCR rule: the input document type should also be a possible…”

   proof ↗⚑ flag

Figures

1. ml engineerFigures and charts are extracted or described (VLM summaries, image crops) with positions traceable back to the source page

   weight 2 · round to Extend
   Extend~partialclaimed5/10

   Extend documents citations/provenance pointing extracted field values back to exact page locations and detects tables/images/handwriting, but evidence never explicitly describes VLM-generated summaries of figures/charts or image crop extraction with bounding-box positions for visual elements specifically — citations are framed around extracted field values, not figure/chart description. missing for 10: explicit VLM-based figure/chart summarization, image crop extraction as an output artifact, and confirmation that citations/positions apply to figures/charts (not just text fields).

   • [claimed-docs] “Detect tables, checkboxes, images, and handwriting”
   • [claimed-docs] “Citations”
   • [claimed-docs] “plus per-field confidence scores and citations that point back to the exact spot on the page”
   • [claimed-docs] “Multifile extraction lets you run a single extraction over a collection of files with a shared context.”
   • [claimed-docs] “Confidence Scores | Extend Documentation”

   proof ↗⚑ flag

   Datalab—none0/10

   Evidence covers document-to-markdown conversion and field-level bounding-box citations, but nothing in the pack specifically addresses figure/chart extraction, VLM-generated image summaries, or image crop outputs with page-position traceability. Missing for 10: any documentation of figure/image detection, VLM-based figure description, image crop output, or bounding boxes tied specifically to charts/figures.

   • [claimed-docs] “Parse PDFs, Word docs, and spreadsheets into Markdown, HTML, or JSON”
   • [claimed-docs] “Extract specific fields with citations back to source bounding boxes for auditability”

   proof ↗⚑ flag

Layout

1. developerThe API parses complex real-world PDFs — multi-column layouts, headers, footers, footnotes — into clean, correctly ordered content

   weight 3 · round to Extend
   Extend~partialcommunity5/10

   Extend markets parsing as high-accuracy for 'hardest documents' with features like agentic OCR, table/checkbox/handwriting detection, and citations pointing to exact page locations, and one community user praises extraction accuracy over a year of use. However, no evidence specifically addresses multi-column layouts, headers/footers, or footnote handling/ordering. Missing for 10: explicit documentation or examples showing correct handling of multi-column reading order, header/footer exclusion, and footnote placement; independent benchmark or hands-on test of these specific layout challenges.

   • [claimed-docs] “Parse, extract, and split your hardest documents with unmatched accuracy. Ship reliable document agents in minutes, not months.”
   • [claimed-docs] “Detect tables, checkboxes, images, and handwriting”
   • [claimed-docs] “Agentic OCR”
   • [claimed-docs] “plus per-field confidence scores and citations that point back to the exact spot on the page”
   • [community] “We've been using Extend for over a year and have been super happy with the product and accuracy of the data extraction.”

   proof ↗⚑ flag

   Datalab~partialclaimed3/10

   Docs confirm Datalab converts PDFs (and other documents) into Markdown/HTML/JSON, which is the baseline capability needed for this story, but the evidence pack contains no specific claims or examples about handling multi-column layouts, headers/footers, or footnote ordering/accuracy. missing for 10: explicit documentation or benchmarks on multi-column layout handling, header/footer suppression, footnote placement, and any independent accuracy evidence for complex real-world PDFs.

   • [claimed-docs] “Parse PDFs, Word docs, and spreadsheets into Markdown, HTML, or JSON”
   • [claimed-docs] “Get started with Datalab to convert PDFs, images, and documents into Markdown, HTML, or JSON in minutes.”
   • [claimed-docs] “The SDK provides a simple interface to convert documents to Markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”

   proof ↗⚑ flag

2. ml engineerParsed output preserves document hierarchy — headings, sections, reading order — so downstream LLMs see structure, not soup

   weight 2 · round to Datalab
   Extend—none0/10

   The evidence pack confirms Extend parses documents and extracts structured data (chunks, metadata) but contains no specific claim or demonstration that parsed output preserves heading hierarchy, section structure, or reading order for downstream LLM consumption.

   • [claimed-docs] “Parse runs now include a **`metadata`** object on `output`, alongside `chunks`”
   • [claimed-docs] “Detect tables, checkboxes, images, and handwriting”

   proof ↗⚑ flag

   Datalab~partialcommunity5/10

   Datalab's core conversion outputs (Markdown, HTML, JSON) inherently carry some structural information (headings, sections) and its segmentation feature splits documents into logical sections, implying hierarchy-awareness, but the evidence never explicitly describes preservation of heading levels or reading order fidelity. A community comment on Datalab's Chandra-OCR notes a structural fidelity gap (PDF-in should allow PDF-out for groundtruthing), suggesting output structure isn't fully faithful to source layout in all cases. missing for 10: explicit documentation of heading/section hierarchy retention, reading-order guarantees, and independent benchmarks confirming structural accuracy.

   • [claimed-docs] “Parse PDFs, Word docs, and spreadsheets into Markdown, HTML, or JSON”
   • [claimed-docs] “The SDK provides a simple interface to convert documents to Markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Document Segmentation — Split multi-document PDFs into separate logical sections”
   • [claimed-docs] “Segment a document into sections using a schema. Returns page ranges for each identified segment.”
   • [community] “On Datalab's Chandra-OCR: 'it doesn't follow what I consider to be a fundamental OCR rule: the input document type should also be a possible…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Datalab
   Extend—none0/10

   Evidence covers compliance (SOC2, HIPAA, GDPR), data retention/ZDR, and BYOC/Hybrid deployment options, but nowhere mentions region selection or data residency choice for storage location. missing for 10: explicit region/residency selection controls, documentation naming specific data center regions, evidence of a residency configuration option.

   • [claimed-docs] “Compliance: "We maintain controls aligned with SOC 2 Type II requirements. Reports and security documentation are available in the Trust Cen…”
   • [claimed-docs] “Data handling, Zero Data retention: "We maintain automatic data-retention policies that vary in default length by billing tier and can be co…”
   • [claimed-docs] “BYOC (your VPC) and Hybrid deployments”

   proof ↗⚑ flag

   Datalab~partialclaimed5/10

   Datalab offers Enterprise on-prem/air-gapped deployment so customers can run models on infrastructure they control (implying residency control), and Team plan includes BAA/DPA for compliance, but there is no documented cloud-tier region-selection feature (e.g., choosing US/EU data center) for standard SaaS usage. missing for 10: explicit region/data-residency selector for standard cloud accounts, independent confirmation of on-prem residency guarantees.

   • [claimed-docs] “On-prem overview: "Customers can run our models on infrastructure they control with an Enterprise contract." The paid on-prem options target…”
   • [claimed-docs] “Pricing page: the Team plan ($400/mo) lists "BAA / DPA" as included, alongside 400 req/min rate limits; Enterprise adds running on your own …”
   • [claimed-docs] “Customers can run our models on infrastructure they control with an Enterprise contract.”
   • [claimed-docs] “A Helm chart is available for deploying the container on Kubernetes clusters.”

   proof ↗⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round to Extend
   Extend~partialclaimed6/10

   Extend documents zero data retention (ZDR) options including for AI subprocessors, configurable at workspace level, plus SOC2/HIPAA/GDPR compliance controls, which addresses training-data concerns for enterprise customers. However, there's no explicit statement that customer data is never used to train Extend's own models by default, nor independent verification of this policy. Missing for 10: explicit default no-training-on-customer-data policy statement, independent audit/confirmation, and clarity on whether ZDR is opt-in/paid-tier only.

   • [claimed-docs] “Zero data retention”
   • [claimed-docs] “Data handling, Zero Data retention: "We maintain automatic data-retention policies that vary in default length by billing tier and can be co…”
   • [claimed-docs] “Compliance | Extend Documentation”
   • [claimed-docs] “Compliance: "We maintain controls aligned with SOC 2 Type II requirements. Reports and security documentation are available in the Trust Cen…”

   proof ↗⚑ flag

   Datalab~partialclaimed4/10

   Datalab offers an Enterprise on-prem option explicitly aimed at customers needing data privacy/regulated environments, and the Team plan includes a DPA/BAA which typically constrains data use, implying customer data isn't used for training. However, there is no explicit first-party statement that customer documents are excluded from model training or fine-tuning, and no independent confirmation of this policy. Missing for 10: an explicit no-training-on-customer-data clause/policy statement, independent verification, and any UI/API opt-out toggle for AI training.

   • [claimed-docs] “On-prem overview: "Customers can run our models on infrastructure they control with an Enterprise contract." The paid on-prem options target…”
   • [claimed-docs] “Pricing page: the Team plan ($400/mo) lists "BAA / DPA" as included, alongside 400 req/min rate limits; Enterprise adds running on your own …”
   • [claimed-docs] “Customers can run our models on infrastructure they control with an Enterprise contract.”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Extend
   Extend✓fullclaimed8/10

   Extend's official docs explicitly describe configurable automatic data-retention policies and zero data retention (ZDR) options, settable at the workspace level, plus GDPR-related compliance documentation; the pricing page also advertises 'Zero data retention' as a feature tier. This directly addresses retention and deletion control for AI-native users. Missing for 10: no independent/hands-on confirmation that deletion requests are actually honored, and no explicit self-service deletion API/UI documented beyond retention policy configuration.

   • [claimed-docs] “Data handling, Zero Data retention: "We maintain automatic data-retention policies that vary in default length by billing tier and can be co…”
   • [claimed-docs] “Zero data retention”
   • [claimed-docs] “Compliance | Extend Documentation”
   • [claimed-docs] “Data Handling | Extend Documentation”

   proof ↗⚑ flag

   Datalab~partialclaimed4/10

   Datalab offers BAA/DPA on Team plan and on-prem/air-gapped Enterprise options implying data control, plus file storage/checkpoint features, but there is no explicit documentation of user-facing data retention windows, deletion controls/APIs, or a way for a self-serve user to purge stored documents/checkpoints. missing for 10: explicit retention period disclosure, self-service deletion/purge API or dashboard control, documentation of default data lifecycle for uploaded files and checkpoints.

   • [claimed-docs] “Pricing page: the Team plan ($400/mo) lists "BAA / DPA" as included, alongside 400 req/min rate limits; Enterprise adds running on your own …”
   • [claimed-docs] “On-prem overview: "Customers can run our models on infrastructure they control with an Enterprise contract." The paid on-prem options target…”
   • [claimed-docs] “Datalab provides file storage for documents you want to process with pipelines or reuse across multiple API calls.”
   • [claimed-docs] “Use save_checkpoint=true to save parsed state for later /extract or /segment calls.”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Extend—none0/10

   Extend documents data retention/ZDR and compliance policies, but there is no mention of telemetry or usage-tracking opt-out settings for the product itself (e.g., CLI/SDK analytics telemetry). missing for 10: any documentation of telemetry collection or an opt-out/disable-tracking mechanism.

   ⚑ flag

   Datalab—none0/10

   No evidence in the pack mentions telemetry, usage tracking, analytics collection, or an opt-out mechanism; the docs cover product features, security (2FA), billing, and on-prem options but nothing about telemetry opt-out. Missing for 10: any mention of telemetry/analytics collection practices, an opt-out setting or flag, or privacy policy language addressing usage tracking.

   ⚑ flag

Chunking

1. ai-native userOutput comes pre-chunked for RAG — semantic boundaries, metadata, embedding-ready segments — not a wall of text

   weight 3 · round to Datalab
   Extend~partialclaimed6/10

   Extend's Parse API outputs both `chunks` and a `metadata` object, and there's a dedicated Splitting feature for breaking documents into semantic segments, which aligns with the RAG-chunking need. However, there's no explicit documentation framing this as embedding-ready or optimized for RAG pipelines, nor independent corroboration of chunk quality for downstream embedding use. Missing for 10: explicit embedding-ready format specs, RAG-specific use-case documentation, and independent/hands-on validation of chunk semantic quality.

   • [claimed-docs] “Parse runs now include a **`metadata`** object on `output`, alongside `chunks`”
   • [claimed-docs] “Splitting Overview | Extend Documentation”
   • [claimed-docs] “plus per-field confidence scores and citations that point back to the exact spot on the page”

   proof ↗⚑ flag

   Datalab✓fullclaimed7/10

   Datalab's API/SDK explicitly supports converting documents to 'chunks' as an output format alongside Markdown/HTML/JSON, and has a dedicated Segment endpoint that splits documents into logical sections via a schema with page ranges, plus structured extraction with citations to bounding boxes for metadata/auditability - directly matching the semantic-boundary, metadata, embedding-ready segment requirements of RAG pipelines. Missing for 10: explicit documentation of chunk metadata schema (e.g., embeddings, token counts, overlap settings) and independent/hands-on validation that chunk output is embedding-ready rather than just logically segmented.

   • [claimed-docs] “The SDK provides a simple interface to convert documents to Markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Segment a document into sections using a schema. Returns page ranges for each identified segment.”
   • [claimed-docs] “Document Segmentation — Split multi-document PDFs into separate logical sections”
   • [claimed-docs] “Split multi-document PDFs into separate logical sections”
   • [claimed-docs] “Extract specific fields with citations back to source bounding boxes for auditability”

   proof ↗⚑ flag

Output

1. ai-native userI get clean markdown/JSON designed for LLM consumption, with noise like repeated headers and page furniture stripped

   weight 2 · round to Datalab
   Extend~partialclaimed3/10

   Extend's Parse feature outputs structured chunks plus a metadata object (extend-docs-3, extend-docs-9), suggesting some design toward LLM/RAG-ready output, but there is no explicit documentation claiming markdown/JSON output has repeated headers or page furniture stripped for clean LLM consumption. missing for 10: explicit claim/documentation of noise removal (headers, footers, page furniture) in parse output, and independent verification of clean output quality.

   • [claimed-docs] “Parse runs now include a **`metadata`** object on `output`, alongside `chunks`”
   • [claimed-docs] “Splitting Overview | Extend Documentation”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”

   proof ↗⚑ flag

   Datalab~partialcommunity6/10

   Datalab's Marker-based pipeline is documented to convert PDFs/images/docs into Markdown, HTML, JSON, or LLM-ready chunks (datalab-docs-22, datalab-docs-31), which is the core RAG-chunking use case. However, no evidence explicitly describes removal of repeated headers/footers or other page furniture noise, and there's no independent hands-on validation of output cleanliness (the one community mention, datalab-comm-1, concerns PDF-to-PDF fidelity for OCR groundtruthing, not markdown noise-stripping). Missing for 10: explicit documentation of header/footer/page-furniture stripping logic, and independent benchmarks or user reports confirming clean, low-noise markdown output for LLM ingestion.

   • [claimed-docs] “The SDK provides a simple interface to convert documents to Markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Parse PDFs, Word docs, and spreadsheets into Markdown, HTML, or JSON”
   • [community] “On Datalab's Chandra-OCR: 'it doesn't follow what I consider to be a fundamental OCR rule: the input document type should also be a possible…”

   proof ↗⚑ flag

Async

1. developerLong parses run as async jobs with status polling and completion webhooks, so my pipeline never blocks

   weight 3 · round to Extend
   Extend✓fullclaimed7/10

   Extend's docs explicitly state every processing endpoint including parse supports both sync and async modes, and separate docs cover webhook configuration for completion notifications, matching the async-job + webhook pipeline pattern. Missing for 10: explicit mention of a status-polling endpoint/job-id retrieval flow and independent/hands-on confirmation that async+webhook flow works reliably in production.

   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”
   • [claimed-docs] “Async Processing | Extend Documentation”
   • [claimed-docs] “Webhook Configuration | Extend Documentation”

   proof ↗⚑ flag

   Datalab~partialclaimed6/10

   Docs confirm webhooks for job completion notifications with overridable webhook_url, and async checkpoint-based processing (save_checkpoint, checkpoint_id) that avoids re-parsing, supporting a non-blocking pipeline pattern. However, evidence doesn't explicitly describe a status-polling endpoint for job state or detail async queue/job semantics beyond webhooks. missing for 10: explicit job-status/polling API documentation, independent/hands-on confirmation that webhooks reliably fire for long-running jobs at scale, and details on job queuing/retry behavior.

   • [claimed-docs] “Webhooks provide real-time notifications when your document processing jobs complete, eliminating the need for continuous polling.”
   • [claimed-docs] “You can override the default webhook URL for specific API requests by including the webhook_url parameter”
   • [claimed-docs] “Configure webhooks to receive real-time notifications when Datalab jobs complete.”
   • [claimed-docs] “You can override the default webhook URL for specific API requests by including the `webhook_url` parameter”
   • [claimed-docs] “Use save_checkpoint=true to save parsed state for later /extract or /segment calls.”
   • [claimed-docs] “Provide a file for end-to-end processing, or a checkpoint_id from a previous /convert call to skip re-parsing.”

   proof ↗⚑ flag

Latency

1. developerA fast synchronous mode returns results in seconds for interactive apps, with latency documented per mode

   weight 2 · round to Extend
   Extend~partialclaimed4/10

   Docs confirm every processing endpoint supports both sync and async modes (extend-docs-37) and pricing page lists a 'Fast mode' option (extend-docs-25), implying a fast synchronous path exists, but no evidence quantifies actual latency (e.g., 'returns in X seconds') for either mode. Missing for 10: documented latency benchmarks per mode, explicit performance numbers for sync/fast mode, independent confirmation of response times.

   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”
   • [claimed-docs] “Async Processing | Extend Documentation”
   • [claimed-docs] “Fast mode”

   proof ↗⚑ flag

   Datalab—none0/10

   No evidence documents a synchronous/fast processing mode with per-mode latency benchmarks; the API appears async (webhooks, checkpoints, job completion notifications) with no mention of a sync mode or documented latency numbers. Missing for 10: any mention of a synchronous/interactive mode, latency figures per mode, or benchmarks for seconds-level response.

   • [claimed-docs] “Webhooks provide real-time notifications when your document processing jobs complete, eliminating the need for continuous polling.”
   • [claimed-docs] “Provide a file for end-to-end processing, or a checkpoint_id from a previous /convert call to skip re-parsing.”
   • [claimed-docs] “Use save_checkpoint=true to save parsed state for later /extract or /segment calls.”

   proof ↗⚑ flag

Scale

1. data engineerI push high-volume batches — millions of pages — with documented rate limits and predictable throughput

   weight 2 · round to Datalab
   Extend~partialclaimed4/10

   Extend documents async processing for all endpoints and a credit-based pricing model, which supports high-volume batch workflows, but there is no evidence of documented rate limits, throughput benchmarks, or guidance for processing millions of pages at scale. Missing for 10: explicit rate-limit documentation, throughput/SLA numbers, and batch-scale case studies or guarantees.

   • [claimed-docs] “Async Processing | Extend Documentation”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”
   • [claimed-docs] “How Credits Work | Extend Documentation”
   • [claimed-docs] “2,000+ page support”

   proof ↗⚑ flag

   Datalab~partialclaimed6/10

   Datalab documents page-level limits with a workaround (page_range) for large documents, per-processor billing, and Team-tier rate limits (400 req/min per datalab-supp-2), plus an Enterprise option explicitly targeting 'extremely high volume' customers (datalab-supp-1). However there's no dedicated bulk/batch ingestion API, no documented throughput benchmarks for millions of pages, and no independent evidence of sustained high-volume performance. Missing for 10: explicit batch-processing endpoint for large-scale jobs, published throughput/SLA numbers at millions-of-pages scale, and independent corroboration of predictable performance under heavy load.

   • [claimed-docs] “For documents exceeding these limits, use the page_range parameter to process in segments”
   • [claimed-docs] “On-prem overview: "Customers can run our models on infrastructure they control with an Enterprise contract." The paid on-prem options target…”
   • [claimed-docs] “Pricing page: the Team plan ($400/mo) lists "BAA / DPA" as included, alongside 400 req/min rate limits; Enterprise adds running on your own …”
   • [claimed-docs] “Datalab bills for the processors and add-ons you run. Most have per-page rates; some also use measured compute costs.”
   • [claimed-docs] “Webhooks provide real-time notifications when your document processing jobs complete, eliminating the need for continuous polling.”

   proof ↗⚑ flag

Playground

1. developerI drag a document into a web playground and see parse/extract results before writing any code

   weight 1 · round to Datalab
   Extend~partialclaimed4/10

   Extend references a web-based "Studio" for iterating on processors (extend-docs-18, extend-docs-40) which implies a no-code interface for testing parse/extract, but no evidence describes a drag-and-drop upload flow or explicitly shows results appearing before any code is written. Missing for 10: explicit description or screenshot of drag-and-drop file upload in Studio, confirmation that parse/extract results appear instantly without any coding, and independent/hands-on confirmation of this playground UX.

   • [claimed-docs] “Studio and Evals”
   • [claimed-docs] “the thing you version and iterate on in Extend Studio, and the unit you evaluate and optimize”
   • [claimed-docs] “you save that config once as a processor, give it a stable id, and reference it from then on”

   proof ↗⚑ flag

   Datalab✓fullclaimed8/10

   Datalab docs explicitly describe 'Forge', a web playground where you upload a document and see parse/extract results instantly with no API key or code, and the changelog confirms structured extraction/track-changes results are previewable directly in the UI. This directly matches the story's drag-and-drop, no-code preview experience. Missing for 10: independent/hands-on confirmation of the playground UX (e.g. third-party walkthrough or screenshots) beyond vendor docs.

   • [claimed-docs] “Want to try before writing code? Upload a document to Forge to see results instantly — no API key required.”
   • [claimed-docs] “Upload a document to Forge to see results instantly — no API key required.”
   • [claimed-docs] “Track Changes is now available in the Playground — upload a DOCX, PDF, or image file to preview tracked changes extraction results directly …”
   • [claimed-docs] “In-app playground renamed from “Forge Playground” to **Forge** (`/app/playground`).”

   proof ↗⚑ flag

Sdks

1. developerOfficial typed SDKs for Python and TypeScript cover the full API — parse, extract, jobs — with sensible defaults

   weight 3 · round to Extend
   Extend~partialclaimed6/10

   Extend has a dedicated SDKs docs page and a Python package (pip install extend-ai) referenced, plus full API coverage across parse/extract/split/classify/jobs implied by endpoint docs, suggesting SDKs wrap the full API. However, there's no explicit confirmation of a TypeScript SDK, no code samples showing typed usage or sensible defaults, and no independent/community corroboration of SDK quality or completeness. Missing for 10: explicit TypeScript SDK evidence, typed code examples demonstrating parse/extract/jobs coverage, and independent developer confirmation of SDK ergonomics/defaults.

   • [claimed-docs] “SDKs | Extend Documentation”
   • [claimed-docs] “pip install extend-ai”
   • [claimed-docs] “API Quickstart | Extend Documentation”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”

   proof ↗⚑ flag

   Datalab~partialclaimed4/10

   Datalab documents a robust Python SDK covering convert/parse, structured extraction, segmentation, pipelines, form filling, and file management with API reference endpoints, plus a CLI — but there is no evidence anywhere in the pack of an official TypeScript/JS SDK, only Python. missing for 10: TypeScript SDK existence/docs, evidence of typed interfaces/type definitions, and independent confirmation of SDK quality or default configs.

   • [claimed-docs] “The Datalab Python SDK provides a simple interface for document conversion, pipelines, structured extraction, form filling, and file managem…”
   • [claimed-docs] “The SDK provides a simple interface to convert documents to Markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Extract structured data from a document using a JSON schema.”
   • [claimed-docs] “Segment a document into sections using a schema. Returns page ranges for each identified segment.”
   • [claimed-docs] “Pipelines chain processors (convert, extract, segment, custom) into reusable, versioned configurations.”
   • [claimed-docs] “Fill PDF and image forms with structured field data using the Datalab SDK.”
   • [claimed-docs] “Datalab provides file storage for documents you want to process with pipelines or reuse across multiple API calls.”
   • [claimed-docs] “Use the Datalab CLI to convert documents from the command line.”

   proof ↗⚑ flag

Grounding

1. ai-native userEvery extracted field carries provenance — page number, bounding box, source snippet — so agents can cite and humans can verify

   weight 2 · round to Extend
   Extend✓fullclaimed8/10

   Docs explicitly describe per-field citations pointing back to the exact spot on the page, confidence scores for trust/routing decisions, and multifile citations/file provenance, directly matching the provenance story (page/location + source snippet). missing for 10: no explicit mention of bounding-box coordinates format, and no independent/hands-on verification of citation accuracy beyond vendor docs.

   • [claimed-docs] “plus per-field confidence scores and citations that point back to the exact spot on the page”
   • [claimed-docs] “Use them to trust high-confidence values automatically and route the rest to human review.”
   • [claimed-docs] “Multifile extraction lets you run a single extraction over a collection of files with a shared context.”
   • [claimed-docs] “Confidence Scores | Extend Documentation”

   proof ↗⚑ flag

   Datalab~partialclaimed6/10

   Datalab's docs explicitly claim structured extraction returns 'citations back to source bounding boxes for auditability' (datalab-docs-18) and the extract-structured-data API lets you supply a schema and get filled values with provenance-related metadata (datalab-docs-3, datalab-docs-32, datalab-docs-16). Segmentation also returns page ranges (datalab-docs-33), reinforcing page-level references. However, no example response schema or independent/hands-on confirmation is given showing per-field page number + bounding box + source snippet together. Missing for 10: a concrete sample JSON output demonstrating page number, bounding box, and snippet fields together, plus third-party validation that citations are reliable/accurate.

   • [claimed-docs] “Extract specific fields with citations back to source bounding boxes for auditability”
   • [claimed-docs] “Extract specific fields from documents by providing a JSON schema. Marker parses the document and fills in your schema with extracted values…”
   • [claimed-docs] “Extract structured data from a document using a JSON schema.”
   • [claimed-docs] “Segment a document into sections using a schema. Returns page ranges for each identified segment.”
   • [claimed-docs] “Provide a file for end-to-end processing, or a checkpoint_id from a previous /convert call to skip re-parsing.”

   proof ↗⚑ flag

Review

1. data engineerExtractions carry calibrated confidence scores with a human-in-the-loop review path for low-confidence fields

   weight 2 · round to Extend
   Extend✓fullclaimed8/10

   Extend has a dedicated Confidence Scores doc explicitly stating per-field confidence values let users 'trust high-confidence values automatically and route the rest to human review,' plus a Composer & Review Agent product feature and citations pointing to exact source locations for verification. This directly matches the calibrated confidence + human-in-the-loop review story. Missing for 10: independent/hands-on evidence validating that confidence scores are well-calibrated in practice and more detail on the review workflow UI itself.

   • [claimed-docs] “Confidence Scores | Extend Documentation”
   • [claimed-docs] “Use them to trust high-confidence values automatically and route the rest to human review.”
   • [claimed-docs] “plus per-field confidence scores and citations that point back to the exact spot on the page”
   • [claimed-docs] “Composer & Review Agent”

   proof ↗⚑ flag

   Datalab—none0/10

   Evidence covers structured extraction, schema-based field extraction, and citation to bounding boxes for auditability, but nowhere mentions confidence scores on extracted fields or any human-in-the-loop review workflow for low-confidence outputs. Missing for 10: calibrated per-field confidence scores, a review/approval UI or workflow for flagged low-confidence fields, any documentation of human-in-the-loop correction loop.

   • [claimed-docs] “Extract specific fields from documents by providing a JSON schema. Marker parses the document and fills in your schema with extracted values…”
   • [claimed-docs] “Extract specific fields with citations back to source bounding boxes for auditability”
   • [claimed-docs] “Extract structured data from a document using a JSON schema.”

   proof ↗⚑ flag

Schemas

1. developerI supply a JSON schema and get back validated structured fields extracted from the document

   weight 3 · round to Extend
   Extend✓fullcommunity9/10

   Extend has dedicated docs for defining an Extraction Schema, returns structured fields with per-field confidence scores and citations pointing to source location, and supports sync/async extraction endpoints; community feedback corroborates strong extraction accuracy. Missing for 10: independent third-party benchmarking of schema-conformance accuracy beyond a single HN endorsement.

   • [claimed-docs] “Extraction Schema | Extend Documentation”
   • [claimed-docs] “Confidence Scores | Extend Documentation”
   • [claimed-docs] “Use them to trust high-confidence values automatically and route the rest to human review.”
   • [claimed-docs] “plus per-field confidence scores and citations that point back to the exact spot on the page”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”
   • [community] “We've been using Extend for over a year and have been super happy with the product and accuracy of the data extraction.”

   proof ↗⚑ flag

   Datalab✓fullclaimed8/10

   Datalab has a dedicated structured-extraction API/recipe where developers supply a JSON schema and Marker fills it with extracted values, with an explicit API reference endpoint (extract-structured-data) supporting checkpointed input and even schema auto-generation. Missing for 10: independent/hands-on validation of extraction accuracy and no example of actual JSON output demonstrating field-level correctness.

   • [claimed-docs] “Extract specific fields from documents by providing a JSON schema. Marker parses the document and fills in your schema with extracted values…”
   • [claimed-docs] “Provide a file for end-to-end processing, or a checkpoint_id from a previous /convert call to skip re-parsing.”
   • [claimed-docs] “Extract structured data from a document using a JSON schema.”
   • [claimed-docs] “For a given file, generate potential extraction schemas.”
   • [claimed-docs] “Extract specific fields with citations back to source bounding boxes for auditability”

   proof ↗⚑ flag

Splitting

1. data engineerMulti-document packets are classified and split automatically — one upload, per-document results

   weight 2 · round to Extend
   Extend✓fullcommunity8/10

   Extend has dedicated Classification and Splitting overview docs plus async processing that applies to every processing endpoint (extract, classify, split, parse), and supports file upload with automatic conversion, indicating a workflow where a single multi-document upload can be classified/split into per-document outputs. Community feedback confirms satisfaction with extraction accuracy over a year of production use. Missing for 10: an explicit end-to-end worked example combining classification+splitting on one upload with per-document result output shown in a single doc, and independent hands-on verification of this exact multi-doc splitting workflow.

   • [claimed-docs] “Classification Overview | Extend Documentation”
   • [claimed-docs] “Splitting Overview | Extend Documentation”
   • [claimed-docs] “Every processing endpoint in Extend (extract, classify, split, parse, and edit) supports both a synchronous and asynchronous mode.”
   • [claimed-docs] “This endpoint accepts file contents and registers them as a File in Extend, which can be used for running workflows, creating evaluation set…”
   • [claimed-docs] “If an uploaded file is detected as a Word or PowerPoint document, it will be automatically converted to a PDF.”
   • [community] “We've been using Extend for over a year and have been super happy with the product and accuracy of the data extraction.”

   proof ↗⚑ flag

   Datalab✓fullclaimed7/10

   Datalab's Document Segmentation feature and /segment API explicitly split multi-document PDFs into logical sections and return page ranges per identified segment from a single uploaded file, directly matching the classify-and-split-per-document story (datalab-docs-5, datalab-docs-20, datalab-docs-33). Pipelines can chain convert→segment→extract into a single automated workflow producing per-document structured results (datalab-docs-38). Missing for 10: independent/hands-on validation of segmentation accuracy and a concrete example showing distinct classification labels/output structure per split document.

   • [claimed-docs] “Document Segmentation — Split multi-document PDFs into separate logical sections”
   • [claimed-docs] “Split multi-document PDFs into separate logical sections”
   • [claimed-docs] “Segment a document into sections using a schema. Returns page ranges for each identified segment.”
   • [claimed-docs] “Pipelines chain processors (convert, extract, segment, custom) into reusable, versioned configurations.”

   proof ↗⚑ flag

Tables

1. data engineerComplex tables — merged cells, nested headers, multi-page spans — come out as faithful HTML/markdown structure

   weight 3 · round to Extend
   Extend~partialclaimed3/10

   Extend's pricing page claims it can 'Detect tables, checkboxes, images, and handwriting' and offers Agentic OCR/parsing, suggesting table-aware extraction, but there is no documentation addressing merged cells, nested headers, or multi-page table spans, nor evidence of faithful HTML/markdown structural output. Missing for 10: explicit handling of merged cells, nested headers, multi-page table continuity, and documented HTML/markdown fidelity examples.

   • [claimed-docs] “Detect tables, checkboxes, images, and handwriting”
   • [claimed-docs] “Agentic OCR”

   proof ↗⚑ flag

   Datalab—none0/10

   Datalab's docs describe general PDF/Word/spreadsheet conversion to Markdown/HTML/JSON and structured extraction, but nothing in the evidence pack specifically addresses fidelity for merged cells, nested headers, or tables spanning multiple pages. Missing for 10: any documentation or example demonstrating complex table structure preservation, nested header handling, or multi-page table stitching.

   • [claimed-docs] “Parse PDFs, Word docs, and spreadsheets into Markdown, HTML, or JSON”
   • [claimed-docs] “The SDK provides a simple interface to convert documents to Markdown, HTML, JSON, or chunks.”
   • [claimed-docs] “Convert a PDF, image, or document to markdown, HTML, JSON, or chunks.”

   proof ↗⚑ flag

2. data engineerI turn extracted tables into typed rows/JSON I can load into a database without manual cleanup

   weight 2 · round to Datalab
   Extend~partialcommunity6/10

   Extend documents schema-based extraction that outputs structured JSON with per-field confidence scores and citations, and explicitly advertises table detection, which supports turning extracted tables into typed data with less manual cleanup; community feedback also praises extraction accuracy. However, there is no explicit documentation of table-specific row/column typing, CSV/DB-ready output formats, or direct database load integrations. Missing for 10: table-to-row schema examples, explicit typed-row/CSV export, and direct DB-loading integration guidance.

   • [claimed-docs] “Extraction Schema | Extend Documentation”
   • [claimed-docs] “Confidence Scores | Extend Documentation”
   • [claimed-docs] “Detect tables, checkboxes, images, and handwriting”
   • [claimed-docs] “plus per-field confidence scores and citations that point back to the exact spot on the page”
   • [community] “We've been using Extend for over a year and have been super happy with the product and accuracy of the data extraction.”

   proof ↗⚑ flag

   Datalab✓fullclaimed8/10

   Datalab's structured extraction lets users define a JSON schema and get back typed field values (with bounding-box citations for auditability), plus schema auto-generation and checkpointing to reuse parsed state across calls, which maps directly to producing clean typed JSON for downstream DB loading. Missing for 10: independent/hands-on validation of extraction accuracy on real-world tables and any explicit DB-loading connector or schema-validation guarantees beyond docs.

   • [claimed-docs] “Extract specific fields from documents by providing a JSON schema. Marker parses the document and fills in your schema with extracted values…”
   • [claimed-docs] “Provide a file for end-to-end processing, or a checkpoint_id from a previous /convert call to skip re-parsing.”
   • [claimed-docs] “Extract specific fields with citations back to source bounding boxes for auditability”
   • [claimed-docs] “Extract structured data from a document using a JSON schema.”
   • [claimed-docs] “For a given file, generate potential extraction schemas.”
   • [claimed-docs] “Use save_checkpoint=true to save parsed state for later /extract or /segment calls.”
   • [claimed-docs] “The SDK provides a simple interface to convert documents to Markdown, HTML, JSON, or chunks.”

   proof ↗⚑ flag