Airbyte vs Dagster

Agent access

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

   weight 2 · round drawn
   Airbyte✓fullprobed9/10

   Airbyte hosts a live llms.txt at docs.airbyte.com/llms.txt (confirmed via HTTP 200 probe) providing a concise agent-oriented summary, and it also documents/serves an MCP server for agentic docs/tool discovery, showing deliberate agent-oriented documentation surfaces. Missing for 10: no independent third-party confirmation that agents actually consume llms.txt effectively in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.airbyte.com/llms.txt # docs.airbyte.com llms.txt > Airbyte is an open source platform designed for…”
   • [claimed-docs] “Connect MCP-capable agents like Claude, Cursor, VS Code, ChatGPT, and Codex to your data through Airbyte Agents.”
   • [probe] “official MCP server documented at https://docs.airbyte.com/community/mcp-servers”

   proof ↗⚑ flag

   Dagster✓fullprobed9/10

   Dagster confirms a live llms.txt file (probe returned HTTP 200 with structured doc links) and also publishes agent-oriented docs like a dedicated AI skill for coding agents and an MCP server for Dagster+. missing for 10: no independent/community corroboration that agents successfully use the llms.txt file in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.dagster.io/llms.txt # Dagster Docs ## Docs - [Changelog](about/changelog): Review detailed update…”
   • [claimed-docs] “Dagster maintains an AI skill that gives coding agents better context and patterns for building Dagster projects.”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Airbyte✓fullprobed8/10

   Airbyte offers multiple headless/CI-friendly automation paths: a documented, auth-gated REST API for programmatic control (verified live via probe), Terraform provider for infra-as-code, abctl/Docker/Kubernetes deployment for CI environments, and PyAirbyte which installs and imports cleanly in a scriptable Python environment (verified via runtime probe). These together clearly support running/automating Airbyte without a UI. Missing for 10: no direct evidence of a CLI purpose-built for CI pipelines or documented CI/CD recipe (e.g., GitHub Actions example) beyond API/Terraform/PyAirbyte usage.

   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “Most programmatic interactions with Airbyte require an access token.”
   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code.”
   • [claimed-docs] “abctl makes it easy to run Airbyte anywhere Docker is running.”
   • [claimed-docs] “This installation guide walks through how to deploy Airbyte into any kubernetes cluster.”
   • [claimed-docs] “PyAirbyte brings the power of Airbyte to every Python and AI developer.”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte installed keylessly from pypi into a throwaway venv (uv pip install airbyte) and imported cle…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”

   proof ↗⚑ flag

   Dagster✓fullprobed8/10

   Dagster ships a CLI (dg, dagster) and Docker deployment options with a webserver/daemon architecture designed for scheduled, sensor-driven, or CI-triggered runs, and probe evidence confirms the CLI installs and scaffolds/runs projects keylessly end-to-end. missing for 10: no first-party doc excerpt specifically describing a CI/CD pipeline integration (e.g. GitHub Actions example) or headless-run flags beyond dev server, and no independent report of running Dagster fully headless in a CI pipeline.

   • [claimed-docs] “A typical Dagster Docker deployment includes a several long-running containers: one for the webserver, one for the daemon, and one for each …”
   • [claimed-docs] “Schedules enable automated execution of jobs at specified intervals.”
   • [claimed-docs] “Sensors enable you to take action in response to events that occur either internally within Dagster or in external systems.”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official dagster CLI installed keylessly from pypi via uvx and printed 'dagster, version 1.13.21'.”
   • [probe] “official CLI documented at https://docs.dagster.io/api/clis/dg-cli/dg-cli-configuration”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Airbyte—none0/10

   All evidence describes Airbyte in the reverse role: it ships an MCP *server* (airbyte-mcp) so external MCP-capable agents like Claude, Cursor, and ChatGPT can pull tools/data from Airbyte — not Airbyte acting as an MCP *client* that consumes other tools' MCP servers. No documentation, API, or probe shows Airbyte's AI Assistant or Connector Builder importing/plugging in external MCP servers to expand its own tool use. missing for 10: any evidence of Airbyte consuming external MCP servers, an MCP-client configuration surface, or AI Assistant tool-use extended via third-party MCP servers.

   • [claimed-docs] “Connect MCP-capable agents like Claude, Cursor, VS Code, ChatGPT, and Codex to your data through Airbyte Agents.”
   • [probe] “official MCP server documented at https://docs.airbyte.com/community/mcp-servers”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte ships a first-party MCP server binary — piping a JSON-RPC initialize into the bundled `airbyt…”
   • [claimed-docs] “AI Assistant can automatically prefill and configure a number of fields and sections in the Airbyte Connector Builder, drastically reducing …”

   proof ↗⚑ flag

   Dagster—none0/10

   Evidence only shows Dagster exposing itself as an MCP server (Dagster+ MCP server, dagster-docs-14/probe-3) so external AI agents can call Dagster's tools — the opposite direction of the story, which asks whether a user can plug external MCP servers into Dagster so Dagster can use their tools. No evidence shows Dagster acting as an MCP client consuming other servers' tools.

   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [probe] “official MCP server documented at https://docs.dagster.io/getting-started/ai-tools/dagster-mcp”
   • [claimed-docs] “Dagster maintains an AI skill that gives coding agents better context and patterns for building Dagster projects.”

   proof ↗⚑ flag

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

   weight 3 · round to Airbyte
   Airbyte✓fullprobed9/10

   Airbyte documents an official MCP server ('Airbyte Agents') that connects MCP-capable agents like Claude, Cursor, VS Code, ChatGPT, and Codex to Airbyte data, and this is corroborated by a runtime probe showing the bundled airbyte-mcp binary completing a full keyless stdio JSON-RPC handshake. Missing for 10: independent (non-vendor) hands-on report using the MCP server in a real agent workflow.

   • [claimed-docs] “Connect MCP-capable agents like Claude, Cursor, VS Code, ChatGPT, and Codex to your data through Airbyte Agents.”
   • [probe] “official MCP server documented at https://docs.airbyte.com/community/mcp-servers”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte ships a first-party MCP server binary — piping a JSON-RPC initialize into the bundled `airbyt…”

   proof ↗⚑ flag

   Dagster✓fullprobed7/10

   Dagster is not itself an agent but a data orchestration platform, so an official MCP server is a valid axis; Dagster documents a first-party 'Dagster+ MCP server' that lets AI sessions access and act on a Dagster+ deployment, confirmed by both docs and a probe hit. Missing for 10: independent/hands-on verification of the MCP server working, and clarity on whether it covers OSS Dagster or only the paid Dagster+ tier.

   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [probe] “official MCP server documented at https://docs.dagster.io/getting-started/ai-tools/dagster-mcp”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Dagster
   Airbyte~partialprobed4/10

   Airbyte ships an official CLI, abctl, for deploying/running Airbyte anywhere Docker runs (airbyte-docs-13), and PyAirbyte is explicitly positioned for AI/Python developers (airbyte-docs-1, airbyte-probe-rt-1), showing some official CLI-adjacent tooling usable by AI-native users. However, none of these are framed or documented as an AI-native CLI for agentic pipeline management—abctl is deployment-only, PyAirbyte is a Python library not a CLI, and the AI-agent integration path is the MCP server (a different axis), not a CLI. Missing for 10: a dedicated, documented CLI tool explicitly designed for AI-native/agentic workflows (e.g., triggering syncs, managing connections) beyond deployment tooling.

   • [claimed-docs] “abctl makes it easy to run Airbyte anywhere Docker is running.”
   • [claimed-docs] “PyAirbyte brings the power of Airbyte to every Python and AI developer.”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte installed keylessly from pypi into a throwaway venv (uv pip install airbyte) and imported cle…”
   • [claimed-docs] “Connect MCP-capable agents like Claude, Cursor, VS Code, ChatGPT, and Codex to your data through Airbyte Agents.”

   proof ↗⚑ flag

   Dagster✓fullprobed9/10

   Dagster ships official CLIs (`dagster`, `create-dagster`, `dg`) documented and verified to work keylessly end-to-end via runtime probes, including scaffolding, project dev server, and CLI version output — directly supporting agentic/CLI-driven workflows, further reinforced by a dedicated AI skill and MCP server for agent integration. Missing for 10: no independent third-party review specifically praising CLI usability for AI-native/agentic workflows beyond Dagster's own docs and probes.

   • [claimed-docs] “you can scaffold a new project with the create-dagster CLI (recommended)”
   • [claimed-docs] “Dagster maintains an AI skill that gives coding agents better context and patterns for building Dagster projects.”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [claimed-docs] “uvx create-dagster@latest project my-project”
   • [probe] “official CLI documented at https://docs.dagster.io/api/clis/dg-cli/dg-cli-configuration”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official dagster CLI installed keylessly from pypi via uvx and printed 'dagster, version 1.13.21'.”

   proof ↗⚑ flag

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

   weight 3 · round to Airbyte
   Airbyte✓fullprobed9/10

   Airbyte publishes a documented public REST API with configuration-driven access token auth, and runtime probes confirm the hosted API is live and properly OAuth-gated (401 with auth metadata) rather than absent or broken. This is complemented by a Terraform provider and PyAirbyte SDK for programmatic/AI-native control, giving multiple documented paths to drive Airbyte programmatically. Missing for 10: a publicly discoverable OpenAPI/swagger spec at the docs domain (probe found 404s on standard paths), so full spec-level self-discovery isn't independently verified.

   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “Most programmatic interactions with Airbyte require an access token.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte.”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”
   • [claimed-docs] “PyAirbyte brings the power of Airbyte to every Python and AI developer.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.airbyte.com/openapi.json, https://docs.airbyte.com/swagger.json, https://docs.airbyte.c…”

   proof ↗⚑ flag

   Dagster~partialprobed6/10

   Dagster exposes a documented CLI (dg/dagster CLI, verified runtime-installable) and Python API for defining/running assets, plus a Dagster+ GraphQL/MCP surface for AI agents, and even a first-party AI skill for coding agents. However, there is no evidence of a general documented public REST/OpenAPI API (probe found only 404s for openapi/swagger endpoints), so 'driving the product' programmatically is limited to CLI/Python SDK and Dagster+-specific interfaces rather than a universal documented public API. missing for 10: a documented REST/OpenAPI-style public API, independent confirmation of API stability/coverage, and evidence of non-Dagster+ users driving core OSS orchestration purely via API without UI.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.dagster.io/openapi.json, https://docs.dagster.io/swagger.json, https://docs.dagster.io/…”
   • [probe] “official MCP server documented at https://docs.dagster.io/getting-started/ai-tools/dagster-mcp”
   • [probe] “official CLI documented at https://docs.dagster.io/api/clis/dg-cli/dg-cli-configuration”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official dagster CLI installed keylessly from pypi via uvx and printed 'dagster, version 1.13.21'.”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [claimed-docs] “Dagster maintains an AI skill that gives coding agents better context and patterns for building Dagster projects.”

   proof ↗⚑ flag

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

   weight 2 · round to Airbyte
   Airbyte~partialprobed4/10

   Airbyte documents that API access requires an access token and offers RBAC/SSO on paid plans, and the hosted API is OAuth-protected (401 with WWW-Authenticate/resource metadata), suggesting some capacity for scoped, non-human-agent credentials. However, there is no explicit documentation of issuing narrowly-scoped or least-privilege API keys/tokens specifically for an AI agent (e.g., per-connector or per-action scopes). Missing for 10: explicit scoped/least-privilege token creation workflow, documentation of granular permission scopes for agent use, and independent verification that RBAC can restrict an agent's token to specific resources.

   • [claimed-docs] “Most programmatic interactions with Airbyte require an access token.”
   • [claimed-docs] “Multiple Workspaces SSO, RBAC”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”

   proof ↗⚑ flag

   Dagster—none0/10

   No evidence of scoped or least-privilege API credential/token issuance for agents; the MCP server and CLI docs describe access/action capabilities but not credential scoping or permission management. Missing for 10: any mention of API tokens, scoped credentials, RBAC for agent access, or least-privilege key issuance mechanisms.

   ⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Airbyte✓fullprobed8/10

   Airbyte offers PyAirbyte as an official Python SDK (verified installable and importable via runtime probe), plus a documented, auth-gated REST API and Terraform provider for programmatic/AI-native workflows. missing for 10: no official SDKs beyond Python (e.g., no first-party JS/TS or other language SDK evidenced), and no independent third-party corroboration of SDK quality beyond Airbyte's own docs and the runtime probe.

   • [claimed-docs] “PyAirbyte brings the power of Airbyte to every Python and AI developer.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code.”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte installed keylessly from pypi into a throwaway venv (uv pip install airbyte) and imported cle…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”

   proof ↗⚑ flag

   Dagster✓fullprobed8/10

   Dagster ships a well-documented Python SDK (`dagster`/`dg` CLI, asset/job/schedule APIs) plus AI-specific tooling — a dedicated AI skill for coding agents and an official MCP server — and runtime probes confirm the SDK/CLI actually installs and scaffolds/runs projects keylessly end-to-end. Missing for 10: independent third-party corroboration of SDK ergonomics for AI agents specifically, and no documented OpenAPI/REST spec (probe found only 404s) to complement the Python SDK.

   • [claimed-docs] “Dagster maintains an AI skill that gives coding agents better context and patterns for building Dagster projects.”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [claimed-docs] “You can scaffold Dagster Component definitions in your project from the command line with the dg scaffold defs command”
   • [claimed-docs] “import dagster as dg@dg.assetdef hello(context: dg.AssetExecutionContext): context.log.info("Hello!")@dg.asset(deps=[hello])”
   • [claimed-docs] “uvx create-dagster@latest project my-project”
   • [probe] “official MCP server documented at https://docs.dagster.io/getting-started/ai-tools/dagster-mcp”
   • [probe] “official CLI documented at https://docs.dagster.io/api/clis/dg-cli/dg-cli-configuration”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official dagster CLI installed keylessly from pypi via uvx and printed 'dagster, version 1.13.21'.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.dagster.io/openapi.json, https://docs.dagster.io/swagger.json, https://docs.dagster.io/…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Airbyte
   Airbyte~partialclaimed5/10

   Airbyte Cloud docs confirm it can send notifications for connection events to a webhook endpoint, satisfying the basic 'subscribe to events via webhook' capability, though this is a general ops/notification feature rather than something framed or extended for AI-native/agentic consumption (e.g., no mention of structured event payloads for agent workflows or webhook management via API/MCP). Missing for 10: documentation tying webhooks to AI-agent workflows, configurable event types beyond sync success/failure, and independent/hands-on verification of the webhook feature working in practice.

   • [claimed-docs] “Airbyte can send notifications to an email address, webhook, or both.”
   • [claimed-docs] “Airbyte Cloud can send notifications to an email or webhook.”

   proof ↗⚑ flag

   Dagster—none0/10

   Dagster documents sensors (event-driven triggers) and Dagster+ alerts, but no evidence describes an actual webhook subscription mechanism for external systems to receive event notifications from Dagster. This is a fair capability to expect from an orchestration platform aiming for agentic integrations, so absence of evidence yields 'none' rather than 'na'.

   • [claimed-docs] “Sensors enable you to take action in response to events that occur either internally within Dagster or in external systems.”
   • [claimed-docs] “Dagster+ alerts can notify you of critical events occurring in your deployment so you can catch potential issues early”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round drawn
   Airbyte—none0/10

   Airbyte's AI features (AI Assistant, PyAirbyte, MCP servers) all help configure connectors, move data, or let external agents query data — none of the evidence shows Airbyte itself generating insights, summaries, or suggestions about the user's data inside its own UI. This is a fair question for a modern data platform, but no evidence shows an in-product insight/analytics-generation feature.

   • [claimed-docs] “AI Assistant can automatically prefill and configure a number of fields and sections in the Airbyte Connector Builder, drastically reducing …”
   • [claimed-docs] “AI Assistant can automatically prefill and configure a number of fields and sections in the Airbyte Connector Builder.”
   • [claimed-docs] “Connect MCP-capable agents like Claude, Cursor, VS Code, ChatGPT, and Codex to your data through Airbyte Agents.”

   proof ↗⚑ flag

   Dagster—none0/10

   Dagster's AI features are aimed at helping coding agents build and manage pipelines (an AI skill for context, a Dagster+ MCP server for accessing deployment info) rather than generating insights or suggestions from the underlying data assets themselves. No evidence shows in-product AI analyzing data content, flagging anomalies, or suggesting insights to end users. missing for 10: any evidence of AI-generated insights/suggestions about data content, in-product analytics copilot, or anomaly detection surfaced to users.

   • [claimed-docs] “Dagster maintains an AI skill that gives coding agents better context and patterns for building Dagster projects.”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [probe] “official MCP server documented at https://docs.dagster.io/getting-started/ai-tools/dagster-mcp”

   proof ↗⚑ flag

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

   weight 2 · round to Dagster
   Airbyte✓fullcommunity7/10

   Airbyte connections can be configured with cron/scheduled sync modes that run without manual intervention, backed by webhook/email notifications and a timeline for monitoring, plus API/Terraform hooks for orchestrating automation as code — all core to unattended background pipelines. Community evidence (e.g., comm-4, comm-5) confirms real-world use of Airbyte running syncs autonomously, though comm-4 notes a manual workaround was needed for one edge case (large table sync). Missing for 10: independent benchmarks of long-running unattended reliability at scale, and clearer first-party documentation of failure/retry handling for fully autonomous operation.

   • [claimed-docs] “For each connection, you can select between three options that allow a sync to run.”
   • [claimed-docs] “Airbyte can send notifications to an email address, webhook, or both.”
   • [claimed-docs] “The Connection Timeline displays historical information about relevant connection events.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code.”
   • [community] “Airbyte is a godsend for us. It works really well for most use cases. Unfortunately, we had to write our custom thing for a large table (8 b…”
   • [community] “For me right now, Airbyte is that tool I wish we had at my last startup. We were pulling data from a lot of weird places... writing a lot of…”

   proof ↗⚑ flag

   Dagster✓fullprobed8/10

   Dagster natively supports autonomous background automation via Schedules, Sensors, and Declarative Automation, which trigger asset materializations without manual intervention, backed by a long-running daemon/webserver deployment model; this is corroborated by runtime probes confirming the platform actually runs (dagster dev, daemon container). This directly satisfies the 'AI-native user sets up automations that run autonomously in the background' story, and is further extended by an AI skill and MCP server for agent-driven setup. missing for 10: independent hands-on validation specifically of sensors/schedules firing unattended over time, and more detail on failure/retry handling for long-running autonomous automations.

   • [claimed-docs] “Schedules enable automated execution of jobs at specified intervals.”
   • [claimed-docs] “Sensors enable you to take action in response to events that occur either internally within Dagster or in external systems.”
   • [claimed-docs] “Declarative Automation is a framework that uses information about the status of your assets and their dependencies to launch executions of y…”
   • [claimed-docs] “A typical Dagster Docker deployment includes a several long-running containers: one for the webserver, one for the daemon, and one for each …”
   • [claimed-docs] “Dagster maintains an AI skill that gives coding agents better context and patterns for building Dagster projects.”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”

   proof ↗⚑ flag

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

   weight 3 · round to Airbyte
   Airbyte~partialclaimed5/10

   Airbyte ships a built-in 'AI Assistant' inside the Connector Builder UI that autofills and configures connector fields, which is a genuine in-product AI delegation feature, but it is scoped narrowly to connector building rather than general task delegation across the platform (e.g., pipeline creation, troubleshooting, monitoring). Missing for 10: evidence of a general-purpose in-app assistant beyond Connector Builder, hands-on/independent validation of the AI Assistant's real-world reliability.

   • [claimed-docs] “AI Assistant can automatically prefill and configure a number of fields and sections in the Airbyte Connector Builder, drastically reducing …”
   • [claimed-docs] “Connector Builder is a no-code tool that’s part of the Airbyte UI... letting you develop a connector to use in data syncs without ever needi…”
   • [claimed-docs] “AI Assistant can automatically prefill and configure a number of fields and sections in the Airbyte Connector Builder.”

   proof ↗⚑ flag

   Dagster—none0/10

   Evidence shows Dagster ships an AI skill and an MCP server so that external coding agents (e.g., Claude, Copilot) can build/manage Dagster projects, but this is the inverse of the story — it makes Dagster controllable by agents, not a built-in assistant living inside Dagster's own UI/product that a user can delegate tasks to. No evidence of an embedded chat/assistant feature within Dagster's webserver or CLI.

   • [claimed-docs] “Dagster maintains an AI skill that gives coding agents better context and patterns for building Dagster projects.”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [probe] “official MCP server documented at https://docs.dagster.io/getting-started/ai-tools/dagster-mcp”

   proof ↗⚑ flag

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

   weight 2 · round to Airbyte
   Airbyte~partialprobed7/10

   Airbyte ships an official MCP server (airbyte-mcp) letting MCP-capable agents like Claude, Cursor, ChatGPT, and Codex operate Airbyte via natural language, and this was confirmed via a live runtime handshake describing PyAirbyte connector management. Additionally, an AI Assistant auto-configures Connector Builder fields, showing some natural-language-adjacent tooling. Missing for 10: evidence of natural-language control over broader platform operations (syncs, schedules, monitoring) beyond connector/data management, and independent user testimony confirming NL-driven workflows in practice.

   • [claimed-docs] “Connect MCP-capable agents like Claude, Cursor, VS Code, ChatGPT, and Codex to your data through Airbyte Agents.”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte ships a first-party MCP server binary — piping a JSON-RPC initialize into the bundled `airbyt…”
   • [claimed-docs] “AI Assistant can automatically prefill and configure a number of fields and sections in the Airbyte Connector Builder, drastically reducing …”
   • [probe] “official MCP server documented at https://docs.airbyte.com/community/mcp-servers”

   proof ↗⚑ flag

   Dagster~partialprobed6/10

   Dagster ships an official Dagster+ MCP server and a maintained AI skill giving coding agents context/patterns for building Dagster projects, and hands-on probes confirm agent-driven scaffolding/running of projects works end-to-end. However, this is agent-assisted development (via CLI/MCP tools), not evidence of a natural-language command interface within Dagster itself (e.g., chat-driven asset creation or NL-to-pipeline translation). Missing for 10: direct evidence of natural-language command execution inside the product UI/runtime, broader independent validation of the MCP server's NL capabilities beyond docs.

   • [claimed-docs] “Dagster maintains an AI skill that gives coding agents better context and patterns for building Dagster projects.”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [probe] “official MCP server documented at https://docs.dagster.io/getting-started/ai-tools/dagster-mcp”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Airbyte—none0/10

   Airbyte publishes API documentation (airbyte-docs-3/17/18) but there is no evidence of an interactive reference with runnable/try-it examples; a probe for a standard OpenAPI/Swagger spec at expected paths returned all 404s (airbyte-probe-2), and no docs mention live sandbox or code-execution widgets.

   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “Most programmatic interactions with Airbyte require an access token.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.airbyte.com/openapi.json, https://docs.airbyte.com/swagger.json, https://docs.airbyte.c…”

   proof ↗⚑ flag

   Dagster—none0/10

   Evidence shows only static documentation with code snippets and an llms.txt for LLM consumption, but explicit probes for an OpenAPI/interactive API reference (Swagger UI, runnable playground) all returned 404, and no evidence of runnable in-browser examples exists.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.dagster.io/openapi.json, https://docs.dagster.io/swagger.json, https://docs.dagster.io/…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.dagster.io/llms.txt # Dagster Docs ## Docs - [Changelog](about/changelog): Review detailed update…”
   • [claimed-docs] “import dagster as dg@dg.assetdef hello(context: dg.AssetExecutionContext): context.log.info("Hello!")@dg.asset(deps=[hello])”

   proof ↗⚑ flag

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

   weight 2 · round to Airbyte
   Airbyte~partialprobed4/10

   Airbyte documents and exposes a live, auth-gated REST API (airbyte-docs-3/17/18, airbyte-probe-rt-3), which is the kind of API that is normally backed by an OpenAPI spec, but the evidence pack contains an explicit probe showing that common OpenAPI/Swagger spec paths on docs.airbyte.com all return 404, and no citation confirms a working downloadable machine-readable spec URL. Missing for 10: a confirmed, reachable OpenAPI/Swagger JSON file link and independent corroboration that AI agents can programmatically fetch it.

   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “Most programmatic interactions with Airbyte require an access token.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.airbyte.com/openapi.json, https://docs.airbyte.com/swagger.json, https://docs.airbyte.c…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”

   proof ↗⚑ flag

   Dagster—none0/10

   A direct probe for OpenAPI/Swagger spec files at docs.dagster.io returned 404 on all candidate paths, and no other evidence shows a downloadable machine-readable API spec (Dagster exposes a GraphQL API but no documented OpenAPI equivalent).

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.dagster.io/openapi.json, https://docs.dagster.io/swagger.json, https://docs.dagster.io/…”

   proof ↗⚑ flag

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

   weight 1 · round to Dagster
   Airbyte~partialprobed5/10

   Airbyte supports spinning up fully separate local/self-hosted instances (abctl, OSS quickstart) and multiple workspaces (with RBAC/SSO) which can serve as an isolated test environment, and PyAirbyte can be installed and run in a throwaway Python venv without touching a production Airbyte deployment. However, there is no explicit 'sandbox mode' or documented test-vs-production data isolation feature, connector-level dry-run, or first-party guidance on safely testing against non-production data — missing for 10: dedicated sandbox/test-mode documentation, explicit guidance on preventing production data writes during testing, and independent confirmation that workspace isolation prevents cross-contamination.

   • [claimed-docs] “This quickstart guides you through deploying a local instance of Airbyte Core, Airbyte's open source product. Setup only takes a few minutes…”
   • [claimed-docs] “abctl makes it easy to run Airbyte anywhere Docker is running.”
   • [claimed-docs] “Multiple Workspaces SSO, RBAC”
   • [claimed-docs] “PyAirbyte brings the power of Airbyte to every Python and AI developer.”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte installed keylessly from pypi into a throwaway venv (uv pip install airbyte) and imported cle…”

   proof ↗⚑ flag

   Dagster~partialprobed6/10

   Dagster's architecture supports separating business logic from environment via resource mocking and a distinct local dev workflow ('laptop to CI to dev to prod'), and the runtime probe confirms `dagster dev` boots a fully local, self-contained instance with no external/production dependencies. However, there's no dedicated documentation of a formal 'sandbox mode' or built-in production-data isolation guarantees (e.g., explicit dev/prod resource configs, data masking) beyond the general resource-abstraction pattern. Missing for 10: explicit sandbox/staging environment docs, first-party guidance on isolating production data access, and independent confirmation of safe separation in real deployments.

   • [community] “Dagster team response: goals include (1) Local development - seamless end-to-end dev experience from laptop to CI to dev to prod, (2) managi…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”
   • [claimed-docs] “Ensure a particular column doesn't contain null values * Verify that a tabular asset adheres to a specified schema * Check if an asset's…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Airbyte—none0/10

   The evidence shows Airbyte has a documented API (airbyte-docs-3, airbyte-docs-17, airbyte-docs-18) and even a live auth-gated endpoint (airbyte-probe-rt-3), but nothing in the pack describes API versioning conventions or a documented deprecation policy for breaking changes. The openapi spec probe (airbyte-probe-2) even 404s on standard paths, suggesting no easily discoverable machine-readable version contract.

   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “Most programmatic interactions with Airbyte require an access token.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.airbyte.com/openapi.json, https://docs.airbyte.com/swagger.json, https://docs.airbyte.c…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”

   proof ↗⚑ flag

   Dagster—none0/10

   Evidence shows Dagster has versioned releases (e.g., 1.13.21) and a changelog of feature updates, but no documentation of an explicit API deprecation policy, versioning guarantees, or migration/support timelines is present in the evidence pack.

   • [claimed-docs] “Automation condition evaluations now explain history-dependent conditions (since, newly_true, newly_missing) by showing the remembered value…”
   • [claimed-docs] “wiping and deleting dynamic partitions in a single action now also supports multi-partitioned assets that use the dynamic partitions definit…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official dagster CLI installed keylessly from pypi via uvx and printed 'dagster, version 1.13.21'.”

   proof ↗⚑ flag

Ai build

1. ai-native userA coding agent can scaffold, configure, and run a complete pipeline headlessly through the CLI or API

   weight 3 · round drawn
   Airbyte✓fullprobed8/10

   Airbyte exposes multiple headless surfaces suited to agentic use: PyAirbyte (Python library for AI/dev workflows), a public API (auth-gated, live per probe), a Terraform provider for config-as-code, and a documented first-party MCP server (airbyte-mcp) explicitly for connecting agents like Claude/Cursor/Codex to data. Runtime probes confirm PyAirbyte installs and imports cleanly, the MCP server completes a full keyless JSON-RPC handshake with connector-management instructions, and the API is live and properly OAuth-gated — together enabling an agent to scaffold, configure, and run pipelines without UI interaction. Missing for 10: a documented end-to-end example of an agent using the CLI (abctl) specifically to scaffold+run a full pipeline in one flow, and independent (non-vendor) confirmation of a complete run beyond install/handshake-level probes.

   • [claimed-docs] “PyAirbyte brings the power of Airbyte to every Python and AI developer.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “Connect MCP-capable agents like Claude, Cursor, VS Code, ChatGPT, and Codex to your data through Airbyte Agents.”
   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code.”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte installed keylessly from pypi into a throwaway venv (uv pip install airbyte) and imported cle…”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte ships a first-party MCP server binary — piping a JSON-RPC initialize into the bundled `airbyt…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”
   • [probe] “official MCP server documented at https://docs.airbyte.com/community/mcp-servers”

   proof ↗⚑ flag

   Dagster✓fullprobed8/10

   Dagster provides an official CLI (create-dagster, dg) to scaffold a project, define assets/jobs, and run them headlessly (`uv run dagster dev`), and this was independently verified end-to-end by a runtime probe that scaffolded a project, booted the webserver, and confirmed version info — plus a documented AI skill and MCP server specifically for coding agents. missing for 10: deeper evidence of a first-class programmatic/GraphQL API run path (vs CLI) and independent third-party confirmation beyond the single runtime probe.

   • [claimed-docs] “you can scaffold a new project with the create-dagster CLI (recommended)”
   • [claimed-docs] “uvx create-dagster@latest project my-project”
   • [claimed-docs] “You can scaffold Dagster Component definitions in your project from the command line with the dg scaffold defs command”
   • [claimed-docs] “Dagster maintains an AI skill that gives coding agents better context and patterns for building Dagster projects.”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official dagster CLI installed keylessly from pypi via uvx and printed 'dagster, version 1.13.21'.”
   • [probe] “official CLI documented at https://docs.dagster.io/api/clis/dg-cli/dg-cli-configuration”

   proof ↗⚑ flag

2. ai-native userAI drafts a working connector from API documentation — auth, pagination, streams — that I review and ship

   weight 3 · round to Airbyte
   Airbyte~partialclaimed5/10

   Airbyte's Connector Builder has an AI Assistant that can 'automatically prefill and configure a number of fields and sections' based on API documentation, covering parts of auth/pagination/stream setup, and the builder is designed for human review before shipping. However, evidence does not show the AI drafting a complete working connector end-to-end (auth + pagination + streams) autonomously — it's described as partial prefill assistance within a no-code builder, not full autonomous drafting. missing for 10: evidence of full end-to-end AI-drafted connector from raw API docs, independent/hands-on validation of AI Assistant accuracy on complex pagination/auth schemes, and confirmation of review-and-ship workflow success in practice.

   • [claimed-docs] “Connector Builder is a no-code tool that’s part of the Airbyte UI... letting you develop a connector to use in data syncs without ever needi…”
   • [claimed-docs] “AI Assistant can automatically prefill and configure a number of fields and sections in the Airbyte Connector Builder, drastically reducing …”
   • [claimed-docs] “Connector Builder is a no-code tool that’s part of the Airbyte UI.”
   • [claimed-docs] “AI Assistant can automatically prefill and configure a number of fields and sections in the Airbyte Connector Builder.”

   proof ↗⚑ flag

   Dagster—none0/10

   Dagster's evidence shows AI coding-agent skills, an MCP server, and CLI scaffolding for generic Dagster projects/components, plus integrations with connector tools (Airbyte, Fivetran, dlt), but there is no evidence of an AI feature that drafts a working connector (auth, pagination, streams) directly from API documentation for review and shipping.

   • [claimed-docs] “Dagster maintains an AI skill that gives coding agents better context and patterns for building Dagster projects.”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [claimed-docs] “provides a FivetranAccountComponent which can be used to easily represent Fivetran connectors as assets in Dagster”
   • [claimed-docs] “provides a DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster”

   proof ↗⚑ flag

Ai destinations

1. ai-native userPipelines load into vector stores and LLM-ready formats so my agents can retrieve what was synced

   weight 1 · round to Airbyte
   Airbyte~partialprobed5/10

   Community evidence confirms Airbyte ships at least one vector-store destination (Pinecone) used for AI/LLM pipelines, and PyAirbyte plus the first-party MCP server (airbyte-mcp) let agents retrieve synced data programmatically, but there's no first-party doc citation enumerating vector-store destinations or LLM-ready chunking/embedding formats, and community requests (pgvector, FOSS vector DBs) show coverage is limited. Missing for 10: documented list of supported vector-store destinations/LLM-ready output formats, first-party docs on embedding/chunking pipeline, broader vector DB support beyond Pinecone.

   • [community] “When there are so many awesome FOSS vector databases available, I wonder what motivated the airbyte team to use Pinecone, the one database t…”
   • [community] “hi folks, when will you have pgvector as a destination? we work with a lot of enterprises and they would not move away from using redis or p…”
   • [claimed-docs] “PyAirbyte brings the power of Airbyte to every Python and AI developer.”
   • [claimed-docs] “Connect MCP-capable agents like Claude, Cursor, VS Code, ChatGPT, and Codex to your data through Airbyte Agents.”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte ships a first-party MCP server binary — piping a JSON-RPC initialize into the bundled `airbyt…”

   proof ↗⚑ flag

   Dagster—none0/10

   Dagster orchestrates data pipelines and has integrations for dbt, Airbyte, Fivetran, dlt, etc., but there is no evidence of any built-in or documented capability to load data into vector stores or LLM-ready formats (e.g., embeddings, chunking, vector DB connectors) for agent retrieval. The evidence pack covers general orchestration, automation, and AI-agent-assist tooling (MCP server, AI skill for coding agents) but nothing about vector store integration or LLM-ready output formats.

   ⚑ flag

Ai operate

1. ai-native userAn agent can check sync status, diagnose a failed run, and re-trigger it through an API or MCP server

   weight 2 · round to Dagster
   Airbyte~partialprobed5/10

   Airbyte exposes a documented, auth-gated REST API for programmatic control (including orchestration use cases) and ships a first-party MCP server (airbyte-mcp) that was confirmed via a live handshake, plus a Connection Timeline and notification system that could support diagnosing failed runs. However, no evidence explicitly confirms the API/MCP expose sync-status queries, failure diagnostics, or a re-trigger endpoint as a connected workflow for an agent. Missing for 10: explicit API/MCP documentation of a 'get sync status' or 'get job/run details' endpoint, explicit failure diagnostic output, and a documented re-trigger/retry endpoint tied to the MCP server.

   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “Connect MCP-capable agents like Claude, Cursor, VS Code, ChatGPT, and Codex to your data through Airbyte Agents.”
   • [claimed-docs] “The Connection Timeline displays historical information about relevant connection events.”
   • [claimed-docs] “Airbyte can send notifications to an email address, webhook, or both.”
   • [claimed-docs] “Most programmatic interactions with Airbyte require an access token.”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte ships a first-party MCP server binary — piping a JSON-RPC initialize into the bundled `airbyt…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”

   proof ↗⚑ flag

   Dagster~partialprobed6/10

   Dagster documents an official Dagster+ MCP server explicitly for accessing deployment info and taking actions within an AI session, which plausibly covers checking status and re-triggering runs, and Dagster's core APIs/CLI (dg, dagster) provide programmatic run inspection and re-execution. However, no evidence specifically documents diagnosing a *failed run* or granular sync-status checks via the MCP server, nor is there hands-on confirmation of this exact workflow. Missing for 10: documented MCP tool list showing failed-run diagnostics, hands-on example of re-triggering a run via MCP/API, independent corroboration of the MCP server's action scope.

   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [probe] “official MCP server documented at https://docs.dagster.io/getting-started/ai-tools/dagster-mcp”
   • [claimed-docs] “Dagster+ alerts can notify you of critical events occurring in your deployment so you can catch potential issues early”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Airbyte~partialprobed5/10

   Airbyte exposes a full API, Terraform provider, and PyAirbyte SDK that let an AI-native user programmatically manage many connections/syncs/connectors as code rather than clicking through a UI one at a time, and the API is confirmed live and auth-gated at runtime. However, there's no explicit documentation of a dedicated bulk/batch endpoint (e.g., bulk-create or bulk-trigger for many connections simultaneously) — automation is implied via looping API/Terraform calls rather than a first-class bulk operation feature. Missing for 10: explicit bulk/batch API operations, documented multi-item bulk actions in the UI, and independent hands-on evidence of managing many items at once.

   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code.”
   • [claimed-docs] “PyAirbyte brings the power of Airbyte to every Python and AI developer.”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte installed keylessly from pypi into a throwaway venv (uv pip install airbyte) and imported cle…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”

   proof ↗⚑ flag

   Dagster~partialprobed5/10

   Dagster supports some bulk operations natively — e.g. backfills/subsetting dbt models across many assets at once (dagster-docs-7), and bulk wiping/deleting of dynamic partitions across multi-partitioned assets in a single action (dagster-docs-25) — and these can be triggered programmatically or via AI-agent tooling (MCP server, CLI). However, there is no dedicated documentation of a general-purpose bulk API/operation framework for arbitrary bulk actions across items (e.g. bulk asset materialization, bulk run cancellation, bulk metadata edits) accessible to AI agents specifically. Missing for 10: comprehensive bulk-operation API docs, AI-agent-specific bulk action examples, independent corroboration of bulk workflows at scale.

   • [claimed-docs] “Use Dagster's UI or APIs to run subsets of your dbt models, seeds, and snapshots.”
   • [claimed-docs] “wiping and deleting dynamic partitions in a single action now also supports multi-partitioned assets that use the dynamic partitions definit…”
   • [probe] “official MCP server documented at https://docs.dagster.io/getting-started/ai-tools/dagster-mcp”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”

   proof ↗⚑ flag

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

   weight 3 · round to Dagster
   Airbyte~partialclaimed4/10

   Airbyte supports event-based notifications (webhooks on sync success/failure) and a programmatic API that can be wired into external orchestrators like Airflow to build custom automation, but it has no native rules-engine for defining arbitrary 'on event X do action Y' logic inside the product itself — schedules are time-based and webhooks only cover a fixed set of connection events. Missing for 10: a first-party conditional rules/trigger builder, support for arbitrary event types beyond sync status, and evidence of AI-driven or user-configurable action chains.

   • [claimed-docs] “Airbyte can send notifications to an email address, webhook, or both.”
   • [claimed-docs] “Airbyte Cloud can send notifications to an email or webhook.”
   • [claimed-docs] “For each connection, you can select between three options that allow a sync to run.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte.”
   • [claimed-docs] “The Connection Timeline displays historical information about relevant connection events.”

   proof ↗⚑ flag

   Dagster✓fullprobed8/10

   Dagster provides Sensors (event-driven triggers from internal/external systems), Schedules (time-based triggers), and Declarative Automation conditions to automatically launch asset executions based on state/dependency changes — directly matching the 'rules that trigger actions on events' story. This is corroborated by runtime probes confirming the platform actually runs, and changelog entries showing active refinement of automation conditions. Missing for 10: no independent hands-on evidence specifically exercising sensors/declarative-automation end-to-end (only docs+general runtime probes), and no AI-native-specific example combining automation rules with agent-driven triggers.

   • [claimed-docs] “Schedules enable automated execution of jobs at specified intervals.”
   • [claimed-docs] “Sensors enable you to take action in response to events that occur either internally within Dagster or in external systems.”
   • [claimed-docs] “Declarative Automation is a framework that uses information about the status of your assets and their dependencies to launch executions of y…”
   • [claimed-docs] “Automation condition evaluations now explain history-dependent conditions (since, newly_true, newly_missing) by showing the remembered value…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Dagster
   Airbyte✓fullprobed7/10

   Airbyte natively supports recurring sync schedules (cron/manual/scheduled) per connection, and exposes this via API and Terraform provider for programmatic/automated workflow management, which an AI-native user could drive alongside orchestrators like Airflow. Missing for 10: explicit AI-agent-triggered scheduling examples, and independent hands-on confirmation of schedule reliability at scale.

   • [claimed-docs] “For each connection, you can select between three options that allow a sync to run.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte.”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”

   proof ↗⚑ flag

   Dagster✓fullprobed8/10

   Dagster's Schedules feature explicitly enables automated execution of jobs at specified intervals, complemented by Sensors and Declarative Automation for event-driven triggers, all backed by first-party docs and confirmed runnable via probe evidence of a working local deployment. Missing for 10: no independent/hands-on confirmation specifically of schedule-based (cron-style) recurring execution in production, and no community corroboration of scheduling reliability at scale.

   • [claimed-docs] “Schedules enable automated execution of jobs at specified intervals.”
   • [claimed-docs] “Sensors enable you to take action in response to events that occur either internally within Dagster or in external systems.”
   • [claimed-docs] “Declarative Automation is a framework that uses information about the status of your assets and their dependencies to launch executions of y…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”

   proof ↗⚑ flag

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

   weight 1 · round to Airbyte
   Airbyte~partialclaimed6/10

   Airbyte supports config-as-code versioning via its Terraform provider (docs-2/19) and offers a Connection Timeline for reviewing historical sync/connection events (docs-10), giving real support for the 'version' and 'review' parts of the story. Rollback is only indirectly implied (reverting Terraform state to a prior version) with no dedicated rollback/undo feature documented for connections themselves. Missing for 10: an explicit rollback/undo mechanism for connection or automation state, and independent evidence of Terraform-based revert working in practice.

   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code”
   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code.”
   • [claimed-docs] “The Connection Timeline displays historical information about relevant connection events.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte.”

   proof ↗⚑ flag

   Dagster~partialcommunity4/10

   Dagster's automations are defined as code (asset/job definitions), which implicitly supports versioning and rollback via standard git workflows, and community evidence notes Dagster has figured out 'development branches' for review workflows; the changelog also shows automation condition evaluations exposing history-dependent state for review. However, there is no first-party documentation of a built-in version-history UI, diff/review workflow, or one-click rollback mechanism specific to automations. missing for 10: explicit built-in versioning/audit UI for automation definitions, a documented review/approval workflow, and a documented rollback mechanism beyond generic git revert.

   • [claimed-docs] “An asset definition is a description, in code, of an asset that should exist and how to produce and update that asset.”
   • [claimed-docs] “Automation condition evaluations now explain history-dependent conditions (since, newly_true, newly_missing) by showing the remembered value…”
   • [community] “I believe Dagster is hitting the right chord: they focus on the pain points in DX for Airflow and similar solutions, they have figured out h…”

   proof ↗⚑ flag

Code first

1. data engineerMy pipelines are plain code and config in my own repository — versioned, reviewed, and portable like any software

   weight 2 · round to Dagster
   Airbyte~partialprobed6/10

   Airbyte supports code-first workflows via the Terraform provider (config-as-code, version-controllable) and PyAirbyte (Python-native pipelines), plus a REST API for programmatic control, all confirmed by docs and a runtime probe showing PyAirbyte installs and imports cleanly. However, Airbyte's default and primary experience is a UI-driven workspace with connections stored in its backend, not native git-committed pipeline files, so 'plain code/config in your own repo' requires bolting on Terraform or PyAirbyte rather than being the core paradigm. Missing for 10: evidence of a native repo-first pipeline definition format (e.g., YAML pipelines checked into git as the default deploy path), independent/hands-on confirmation that Terraform-managed Airbyte configs are commonly reviewed via PR workflows, and clarity on how much of the connector/sync logic still lives only in the UI.

   • [claimed-docs] “PyAirbyte brings the power of Airbyte to every Python and AI developer.”
   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code.”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte installed keylessly from pypi into a throwaway venv (uv pip install airbyte) and imported cle…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”

   proof ↗⚑ flag

   Dagster✓fullprobed8/10

   Dagster pipelines are defined as plain Python code (asset definitions, `dg.asset` decorators) scaffolded via CLI into a standard project structure (pyproject.toml, src, tests) that lives in a normal repo, confirmed by hands-on probes showing the CLI scaffolds and runs a project end-to-end. This is inherently version-controllable, code-reviewable, and portable across environments (local, CI, Docker deployment docs confirm portability). missing for 10: no explicit documentation/discussion of git-based review workflows or portability testimonials from independent/community sources beyond docs and CLI probes.

   • [claimed-docs] “An asset definition is a description, in code, of an asset that should exist and how to produce and update that asset.”
   • [claimed-docs] “you can scaffold a new project with the create-dagster CLI (recommended)”
   • [claimed-docs] “import dagster as dg@dg.assetdef hello(context: dg.AssetExecutionContext): context.log.info("Hello!")@dg.asset(deps=[hello])”
   • [claimed-docs] “uvx create-dagster@latest project my-project”
   • [claimed-docs] “A typical Dagster Docker deployment includes a several long-running containers: one for the webserver, one for the daemon, and one for each …”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official dagster CLI installed keylessly from pypi via uvx and printed 'dagster, version 1.13.21'.”

   proof ↗⚑ flag

Destinations

1. data engineerI load to the major warehouses and lakes — Snowflake, BigQuery, Databricks, Postgres, object storage — without changing pipelines

   weight 2 · round to Airbyte
   Airbyte✓fullclaimed7/10

   Airbyte's core value proposition is a large connector catalog (600+) spanning databases, warehouses, and data lakes, with sync modes, schema-change handling, and typing/deduping designed to work uniformly across destinations, letting pipelines be re-pointed to different warehouses without redesign. Evidence doesn't explicitly enumerate Snowflake/BigQuery/Databricks/Postgres/object-storage connector pages, only the general catalog claim and destination-agnostic sync/typing mechanics. Missing for 10: explicit named connector docs for each major warehouse/lake, and independent confirmation of pipeline portability across them without reconfiguration.

   • [github] “Airbyte provides a catalog of 600+ connectors for APIs, databases, data warehouses, data lakes”
   • [claimed-docs] “A sync mode is a combination of a source and destination mode together.”
   • [claimed-docs] “A sync mode governs how Airbyte reads from a source and writes to a destination.”
   • [claimed-docs] “One-to-one table mapping: Data in one stream will always be mapped to one table in your data warehouse. No more sub-tables.”
   • [claimed-docs] “You can specify for each connection how Airbyte should handle any change of schema in the source.”

   proof ↗⚑ flag

   Dagster~partialclaimed4/10

   Dagster's asset framework and its dbt/Airbyte/Fivetran/dlt integrations imply pipelines can load into various warehouses/lakes via pluggable tooling, but the evidence pack has no direct mention of first-class I/O managers or connectors for Snowflake, BigQuery, Databricks, Postgres, or object storage, nor documentation of the 'swap destination without changing pipeline code' abstraction the story requires. missing for 10: explicit warehouse/lake connector docs (Snowflake, BigQuery, Databricks, Postgres, S3), evidence of I/O-manager-based portability across these targets, and any hands-on confirmation of switching destinations without code changes.

   • [claimed-docs] “Use Dagster's UI or APIs to run subsets of your dbt models, seeds, and snapshots.”
   • [claimed-docs] “Using this integration, you can trigger Airbyte syncs and orchestrate your Airbyte connections from within Dagster”
   • [claimed-docs] “provides a FivetranAccountComponent which can be used to easily represent Fivetran connectors as assets in Dagster”
   • [claimed-docs] “provides a DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster”
   • [claimed-docs] “An asset definition is a description, in code, of an asset that should exist and how to produce and update that asset.”

   proof ↗⚑ flag

Catalog

1. data engineerI pick from a broad catalog of maintained connectors for the SaaS APIs, databases, and files my company actually uses

   weight 3 · round to Airbyte
   Airbyte✓fullcommunity9/10

   Airbyte's core value proposition is a catalog of 600+ maintained connectors spanning APIs, databases, warehouses, and data lakes, backed by docs on sync modes, CDC, schema change handling, and incremental sync that demonstrate connector maturity. Community evidence corroborates real-world use across varied sources (custom large-table workarounds, self-hosted production use) though some gaps are noted (hard-delete sync questions, requests for specific destinations like pgvector). Missing for 10: independent connector-count audits or freshness/maintenance-quality benchmarks beyond vendor claims.

   • [github] “Airbyte provides a catalog of 600+ connectors for APIs, databases, data warehouses, data lakes”
   • [claimed-docs] “A sync mode is a combination of a source and destination mode together.”
   • [claimed-docs] “You can specify for each connection how Airbyte should handle any change of schema in the source.”
   • [claimed-docs] “A consumer of these log files (such as Airbyte) can read these logs while keeping track of the current position within the logs in order to …”
   • [claimed-docs] “An incremental sync is a sync which pulls only the data that has changed since the previous sync”
   • [community] “Airbyte is a godsend for us. It works really well for most use cases. Unfortunately, we had to write our custom thing for a large table (8 b…”
   • [community] “For me right now, Airbyte is that tool I wish we had at my last startup. We were pulling data from a lot of weird places... writing a lot of…”
   • [community] “hi folks, when will you have pgvector as a destination? we work with a lot of enterprises and they would not move away from using redis or p…”

   proof ↗⚑ flag

   Dagster~partialcommunity6/10

   Dagster documents integrations for several major ingestion tools (dbt, Airbyte, Fivetran, dlt) with components that represent connectors as assets, giving a real but narrow catalog rather than a broad marketplace of SaaS/database/file connectors. Community evidence even notes Airflow has a maturity/integrations advantage over Dagster, suggesting the catalog breadth is a known gap. Missing for 10: a large enumerated catalog of maintained SaaS/API/database connectors (e.g. hundreds like Fivetran/Airbyte offer natively), evidence of connector maintenance/versioning cadence, and independent confirmation of catalog breadth beyond a handful of named integrations.

   • [claimed-docs] “Use Dagster's UI or APIs to run subsets of your dbt models, seeds, and snapshots.”
   • [claimed-docs] “Using this integration, you can trigger Airbyte syncs and orchestrate your Airbyte connections from within Dagster”
   • [claimed-docs] “provides a FivetranAccountComponent which can be used to easily represent Fivetran connectors as assets in Dagster”
   • [claimed-docs] “provides a DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster”
   • [community] “Dagster natively isolates tasks in the DAG into separate Kubernetes pods... I find Dagster's approach is more Pythonic than Airflow's standa…”

   proof ↗⚑ flag

2. data engineerThe catalog tells me each connector's maturity, support level, and maintainer before I depend on it

   weight 1 · round drawn
   Airbyte—none0/10

   The evidence shows Airbyte has a large connector catalog (600+ connectors) but contains no documentation of per-connector maturity tiers, support levels, or maintainer attribution that a data engineer could check before depending on a connector.

   • [github] “Airbyte provides a catalog of 600+ connectors for APIs, databases, data warehouses, data lakes”

   proof ↗⚑ flag

   Dagster—none0/10

   Evidence shows Dagster has an integrations library (dbt, Airbyte, Fivetran, dlt, etc.) but none of the docs pages cite maturity labels, support tiers, or maintainer attribution for these connectors — no catalog page or metadata addressing this story's specific asks is shown.

   • [claimed-docs] “Use Dagster's UI or APIs to run subsets of your dbt models, seeds, and snapshots.”
   • [claimed-docs] “Using this integration, you can trigger Airbyte syncs and orchestrate your Airbyte connections from within Dagster”
   • [claimed-docs] “provides a FivetranAccountComponent which can be used to easily represent Fivetran connectors as assets in Dagster”
   • [claimed-docs] “provides a DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster”

   proof ↗⚑ flag

Custom connectors

1. data engineerI build a custom connector for a long-tail API with a supported framework or low-code builder, not a fork

   weight 2 · round to Airbyte
   Airbyte✓fullclaimed8/10

   Airbyte ships a documented no-code/low-code Connector Builder UI (with AI Assist to prefill config) specifically designed for building custom connectors for long-tail APIs without forking the codebase, plus CDK-based frameworks referenced via docs. This directly satisfies the story. missing for 10: independent hands-on validation of building a full working custom connector via the Builder for a long-tail API, and details on limitations/edge cases of the low-code builder for complex auth or pagination schemes.

   • [claimed-docs] “Connector Builder is a no-code tool that’s part of the Airbyte UI... letting you develop a connector to use in data syncs without ever needi…”
   • [claimed-docs] “AI Assistant can automatically prefill and configure a number of fields and sections in the Airbyte Connector Builder, drastically reducing …”
   • [claimed-docs] “Connector Builder is a no-code tool that’s part of the Airbyte UI.”
   • [claimed-docs] “AI Assistant can automatically prefill and configure a number of fields and sections in the Airbyte Connector Builder.”

   proof ↗⚑ flag

   Dagster~partialclaimed6/10

   Dagster's core primitives (asset definitions, resources, IO managers) let engineers write plain Python code to hit any long-tail API, and the dlt integration explicitly exposes a supported framework (DltLoadCollectionComponent) for building custom connectors/sources as Dagster assets — not a fork of existing connector code. However, there's no dedicated 'build a custom connector' guide or low-code builder in the evidence, and the featured integrations (Airbyte, Fivetran, dbt) are pre-built connectors rather than a long-tail custom-connector workflow. Missing for 10: an explicit tutorial/guide for authoring a new API connector via dlt or resources, and independent/hands-on corroboration of someone building a long-tail custom connector this way.

   • [claimed-docs] “An asset definition is a description, in code, of an asset that should exist and how to produce and update that asset.”
   • [claimed-docs] “provides a DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster”
   • [claimed-docs] “DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster.”
   • [claimed-docs] “import dagster as dg@dg.assetdef hello(context: dg.AssetExecutionContext): context.log.info("Hello!")@dg.asset(deps=[hello])”
   • [claimed-docs] “You can scaffold Dagster Component definitions in your project from the command line with the dg scaffold defs command”

   proof ↗⚑ flag

Freshness

1. analytics engineerTell how fresh each destination table is and get warned when a pipeline misses its expected cadence

   weight 1 · round to Dagster
   Airbyte~partialclaimed5/10

   Airbyte provides sync schedules, a Connection Timeline showing historical sync events, and email/webhook notifications, which together let an analytics engineer infer freshness and get alerted on sync failures. However, there's no documented feature that explicitly tracks 'table freshness' or proactively warns when a pipeline misses its expected cadence (e.g., an SLA/staleness alert) — engineers would need to build that on top of the timeline/notification primitives. Missing for 10: a dedicated freshness/SLA monitoring feature, explicit 'missed schedule' alerting (vs. just failure notifications), and any per-table freshness dashboard.

   • [claimed-docs] “For each connection, you can select between three options that allow a sync to run.”
   • [claimed-docs] “Airbyte can send notifications to an email address, webhook, or both.”
   • [claimed-docs] “The Connection Timeline displays historical information about relevant connection events.”
   • [claimed-docs] “Airbyte Cloud can send notifications to an email or webhook.”

   proof ↗⚑ flag

   Dagster~partialclaimed6/10

   Dagster's asset checks and freshness-check features directly support telling how fresh a destination table is, and Declarative Automation/schedules/sensors combined with Dagster+ alerts can flag when a pipeline misses expected cadence. However, evidence doesn't show a dedicated, end-to-end 'freshness SLA' dashboard or explicit cadence-miss alerting workflow tied specifically to destination tables, only generic building blocks. missing for 10: explicit freshness-policy/SLA UI documentation, concrete example of cadence-miss alert configuration, independent/hands-on confirmation that these features work together as described.

   • [claimed-docs] “Ensure a particular column doesn't contain null values * Verify that a tabular asset adheres to a specified schema * Check if an asset's…”
   • [claimed-docs] “Ensure a particular column doesn't contain null values”
   • [claimed-docs] “Declarative Automation is a framework that uses information about the status of your assets and their dependencies to launch executions of y…”
   • [claimed-docs] “Schedules enable automated execution of jobs at specified intervals.”
   • [claimed-docs] “Sensors enable you to take action in response to events that occur either internally within Dagster or in external systems.”
   • [claimed-docs] “Dagster+ alerts can notify you of critical events occurring in your deployment so you can catch potential issues early”
   • [claimed-docs] “Automation condition evaluations now explain history-dependent conditions (since, newly_true, newly_missing) by showing the remembered value…”

   proof ↗⚑ flag

Monitoring

1. data engineerI see run status, logs, and row counts per sync, and failures alert me in Slack, email, or a webhook

   weight 3 · round to Airbyte
   Airbyte~partialclaimed6/10

   Docs confirm Connection Timeline for run history, email/webhook notifications for failures, and sync mode/schedule concepts, which cover most of the story. However, Slack alerting is not explicitly documented (only email/webhook), and per-sync row-count reporting and detailed log viewing are not directly evidenced beyond generic timeline mentions, with no independent/hands-on confirmation of alerting reliability. missing for 10: explicit Slack notification support, documented per-sync row-count display, direct evidence of log viewing UI, independent confirmation that alerts fire reliably in practice.

   • [claimed-docs] “Airbyte can send notifications to an email address, webhook, or both.”
   • [claimed-docs] “Airbyte Cloud can send notifications to an email or webhook.”
   • [claimed-docs] “The Connection Timeline displays historical information about relevant connection events.”
   • [claimed-docs] “For each connection, you can select between three options that allow a sync to run.”
   • [claimed-docs] “A sync mode is a combination of a source and destination mode together.”

   proof ↗⚑ flag

   Dagster~partialclaimed4/10

   Dagster provides run status/logs via its webserver UI (dagster-docs-12) and a Dagster+ alerting feature for critical events (dagster-docs-11), plus asset checks that can validate data quality (dagster-docs-3/20). However, the evidence never specifies that alerts can be routed to Slack, email, or webhook, nor does it show row-count-per-sync reporting. missing for 10: explicit documentation of Slack/email/webhook alert channels, and evidence of row-count metrics per sync.

   • [claimed-docs] “Dagster+ alerts can notify you of critical events occurring in your deployment so you can catch potential issues early”
   • [claimed-docs] “A typical Dagster Docker deployment includes a several long-running containers: one for the webserver, one for the daemon, and one for each …”
   • [claimed-docs] “Ensure a particular column doesn't contain null values * Verify that a tabular asset adheres to a specified schema * Check if an asset's…”
   • [claimed-docs] “Ensure a particular column doesn't contain null values”

   proof ↗⚑ flag

Recovery

1. data engineerTransient failures retry automatically and interrupted syncs resume from checkpoints instead of restarting

   weight 2 · round drawn
   Airbyte—none0/10

   Evidence shows Airbyte's sync-mode and incremental-sync concepts (docs-22, docs-23) which imply some notion of state tracking, and a Connection Timeline (docs-10) for viewing sync history, but nothing explicitly documents automatic retry on transient failures or resuming an interrupted sync from a checkpoint rather than restarting. Community evidence (comm-4) even shows a user manually 'tricking' Airbyte into thinking a large sync had completed, suggesting no built-in resume-from-checkpoint mechanism for interrupted large syncs.

   • [claimed-docs] “An incremental sync is a sync which pulls only the data that has changed since the previous sync”
   • [claimed-docs] “A sync mode governs how Airbyte reads from a source and writes to a destination.”
   • [claimed-docs] “The Connection Timeline displays historical information about relevant connection events.”
   • [community] “Airbyte is a godsend for us. It works really well for most use cases. Unfortunately, we had to write our custom thing for a large table (8 b…”

   proof ↗⚑ flag

   Dagster—none0/10

   The evidence pack contains no mention of retry policies, automatic retry-on-failure, checkpointing, or resuming interrupted runs from partial state — topics like assets, schedules, sensors, and integrations are covered, but reliability/retry mechanics are absent. Missing for 10: any documentation or example of RetryPolicy/op retries, run re-execution from failure, or checkpoint-based resume behavior.

   ⚑ flag

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

   weight 2 · round to Airbyte
   Airbyte~partialprobed6/10

   Airbyte documents a full REST API for programmatic control of connections/sources/destinations (with token auth, confirmed live and auth-gated at runtime), plus Terraform provider and PyAirbyte for developer/AI workflows. However, some capabilities are explicitly framed as UI-only (e.g. the no-code Connector Builder and AI Assistant 'part of the Airbyte UI'), and no OpenAPI spec was discoverable at expected endpoints, leaving parity between UI and API features unverified for things like Connection Timeline and notification management. missing for 10: explicit API-parity documentation for Connector Builder/AI Assistant workflows, discoverable OpenAPI spec, and confirmation that all UI-configurable settings (timeline, notifications) are API-exposed.

   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “Most programmatic interactions with Airbyte require an access token.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte.”
   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code.”
   • [claimed-docs] “Connector Builder is a no-code tool that’s part of the Airbyte UI... letting you develop a connector to use in data syncs without ever needi…”
   • [claimed-docs] “Connector Builder is a no-code tool that’s part of the Airbyte UI.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.airbyte.com/openapi.json, https://docs.airbyte.com/swagger.json, https://docs.airbyte.c…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the hosted Airbyte API is live and cleanly auth-gated — a keyless GET https://api.airbyte.com/v1/connec…”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte installed keylessly from pypi into a throwaway venv (uv pip install airbyte) and imported cle…”

   proof ↗⚑ flag

   Dagster~partialprobed5/10

   Dagster exposes a CLI (dg), a Dagster+ MCP server for taking actions, and mentions using 'UI or APIs' to run dbt subsets, suggesting some parity between UI and programmatic control, but there is no documented comprehensive REST/GraphQL API spec (an OpenAPI probe returned 404 on all candidate endpoints) confirming full feature parity with the UI. missing for 10: an explicit comprehensive API reference (OpenAPI/GraphQL schema) enumerating all UI capabilities, and evidence that every UI action (scheduling, sensors, asset catalog browsing, alerts, etc.) is achievable purely via API/CLI without the UI.

   • [claimed-docs] “Use Dagster's UI or APIs to run subsets of your dbt models, seeds, and snapshots.”
   • [claimed-docs] “The Dagster+ MCP server allows you to access information and take actions in your Dagster+ deployment within an AI session.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.dagster.io/openapi.json, https://docs.dagster.io/swagger.json, https://docs.dagster.io/…”
   • [probe] “official MCP server documented at https://docs.dagster.io/getting-started/ai-tools/dagster-mcp”
   • [probe] “official CLI documented at https://docs.dagster.io/api/clis/dg-cli/dg-cli-configuration”

   proof ↗⚑ flag

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

   weight 3 · round to Airbyte
   Airbyte~partialcommunity5/10

   Airbyte's open-source core (self-hosted via abctl/Kubernetes), 600+ connector catalog, and API/Terraform access let users extract and route their data to destinations they control, which implies data portability without vendor lock-in. However, there is no explicit documentation of exporting data into standard open formats (CSV/Parquet/JSON) for a clean 'export and leave' workflow, and community feedback notes Airbyte is not fully open source ('freemium... non-free parts you are not allowed to use'), tempering the openness claim. Missing for 10: explicit open-format export/download feature, clear data-export-and-migrate documentation, and resolution of the freemium/paywall concern.

   • [claimed-docs] “This quickstart guides you through deploying a local instance of Airbyte Core, Airbyte's open source product. Setup only takes a few minutes…”
   • [claimed-docs] “abctl makes it easy to run Airbyte anywhere Docker is running.”
   • [github] “Airbyte provides a catalog of 600+ connectors for APIs, databases, data warehouses, data lakes”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [community] “Just to clarify, this is not a fully open source project. More like freemium... If you want security, you have to pay. There are non-free pa…”

   proof ↗⚑ flag

   Dagster~partialclaimed4/10

   Dagster's pipelines are defined as plain Python code (asset definitions, dg CLI scaffolding) and can be self-hosted via Docker, so pipeline logic itself isn't locked into a proprietary format and can be moved off the platform. However, there is no explicit documentation on exporting run history, metadata, or lineage data from Dagster+ (the hosted product) in an open format, and Dagster+ pricing/plan structure implies some cloud-side data may not be portable. Missing for 10: explicit data/metadata export tooling or docs, and evidence on exporting Dagster+ hosted run/lineage history rather than just code definitions.

   • [claimed-docs] “An asset definition is a description, in code, of an asset that should exist and how to produce and update that asset.”
   • [claimed-docs] “A typical Dagster Docker deployment includes a several long-running containers: one for the webserver, one for the daemon, and one for each …”
   • [claimed-docs] “uvx create-dagster@latest project my-project”
   • [claimed-docs] “Solo Plan $10 per month Personal projects and simple pipelines ... 30-day free trial”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Airbyte
   Airbyte!disputedcontradicted5/10

   Airbyte publishes its code on GitHub with 600+ connectors and docs describe 'Airbyte Core' as an 'open source product' (airbyte-gh-1, airbyte-docs-12/16), supporting readable source. However a hands-on community report explicitly disputes the claim of full openness, stating 'this is not a fully open source project... there are non-free parts to it that you are not allowed to use' (airbyte-comm-7), indicating some components (e.g. enterprise features) are source-available/licensed rather than fully open. Missing for 10: a clear statement of the actual license(s) used (e.g. MIT vs Elv2) and independent confirmation resolving the freemium/open-source tension.

   • [github] “Airbyte provides a catalog of 600+ connectors for APIs, databases, data warehouses, data lakes”
   • [claimed-docs] “This quickstart guides you through deploying a local instance of Airbyte Core, Airbyte's open source product. Setup only takes a few minutes…”
   • [claimed-docs] “This quickstart guides you through deploying a local instance of Airbyte Core, Airbyte's open source product. Setup only takes a few minutes”
   • [community] “Just to clarify, this is not a fully open source project. More like freemium... If you want security, you have to pay. There are non-free pa…”

   proof ↗⚑ flag

   Dagster—none0/10

   The evidence pack contains no mention of Dagster's source code repository, license, or any statement about open-source availability; all citations are docs, community discussion, or CLI/MCP probes unrelated to code licensing.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Dagster
   Airbyte✓fullcommunity8/10

   Airbyte Core is explicitly documented as open-source and self-hostable via Docker/abctl or Kubernetes, with dedicated quickstart guides, and community evidence confirms real-world self-hosted usage ('we use airbyte at my company, although we self-host it'). Missing for 10: independent verification that self-host setup is friction-free (one community report describes a failed docker-compose install) and clarity on which enterprise features are excluded from the open-source edition.

   • [claimed-docs] “This quickstart guides you through deploying a local instance of Airbyte Core, Airbyte's open source product. Setup only takes a few minutes…”
   • [claimed-docs] “abctl makes it easy to run Airbyte anywhere Docker is running.”
   • [claimed-docs] “This quickstart guides you through deploying a local instance of Airbyte Core, Airbyte's open source product. Setup only takes a few minutes”
   • [claimed-docs] “This installation guide walks through how to deploy Airbyte into any kubernetes cluster.”
   • [community] “(We use airbyte at my company, although we self-host it.) This is such a great direction airbyte is taking... given your reputable brand and…”
   • [community] “Even a simple installation of airbyte on my local machine fails :( I tried docker-compose up! ... I simply wanna know why a basic example is…”
   • [community] “Just to clarify, this is not a fully open source project. More like freemium... If you want security, you have to pay. There are non-free pa…”

   proof ↗⚑ flag

   Dagster✓fullprobed9/10

   Dagster is open-source and explicitly documents Docker-based self-hosted deployment (webserver, daemon, code location containers), and a runtime probe confirms an agent can scaffold and run a full local Dagster instance end-to-end without any vendor keys. This directly satisfies self-hosting the core product. Missing for 10: no independent third-party audit of production self-hosted deployments at scale beyond docs/probe.

   • [claimed-docs] “A typical Dagster Docker deployment includes a several long-running containers: one for the webserver, one for the daemon, and one for each …”
   • [claimed-docs] “uvx create-dagster@latest project my-project”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the official dagster CLI installed keylessly from pypi via uvx and printed 'dagster, version 1.13.21'.”

   proof ↗⚑ flag

Dev loop

1. data engineerI run and test a pipeline locally against a lightweight destination before it touches production

   weight 2 · round to Dagster
   Airbyte~partialprobed6/10

   Airbyte documents multiple ways to run pipelines locally before production — OSS quickstart and abctl for local Docker deployments, and PyAirbyte for local Python-based pipeline testing (verified installable and importable in the runtime probe). However, the evidence never names a specific lightweight local destination (e.g., DuckDB/local file) as the recommended pre-production target, and one community report describes a basic local docker-compose install failing outright, raising some doubt about smoothness of the local workflow. missing for 10: explicit lightweight-destination guidance for local testing, more recent/independent confirmation that local setup reliably works end-to-end.

   • [claimed-docs] “This quickstart guides you through deploying a local instance of Airbyte Core, Airbyte's open source product. Setup only takes a few minutes…”
   • [claimed-docs] “abctl makes it easy to run Airbyte anywhere Docker is running.”
   • [claimed-docs] “PyAirbyte brings the power of Airbyte to every Python and AI developer.”
   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte installed keylessly from pypi into a throwaway venv (uv pip install airbyte) and imported cle…”
   • [community] “Even a simple installation of airbyte on my local machine fails :( I tried docker-compose up! ... I simply wanna know why a basic example is…”

   proof ↗⚑ flag

   Dagster✓fullprobed7/10

   Dagster explicitly supports a full local dev loop: `uvx create-dagster` scaffolds a project and `dagster dev`/`uv run dagster dev` boots a local webserver, verified in a live runtime probe, and asset checks let engineers validate data before promotion. Community evidence also confirms real-world local dev-to-prod use with lightweight destinations like DuckDB (Dagster+dbt+DuckDB stack) and Dagster's own stated goal of 'seamless end-to-end dev experience from laptop to CI to dev to prod.' Missing for 10: explicit first-party documentation on swapping resources/IO managers between a lightweight local destination and production, and independent hands-on confirmation of that specific swap pattern.

   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”
   • [claimed-docs] “Ensure a particular column doesn't contain null values * Verify that a tabular asset adheres to a specified schema * Check if an asset's…”
   • [claimed-docs] “Ensure a particular column doesn't contain null values”
   • [community] “I've been working with this stack (Dagster, dbt, DuckDB) for a few months and am super happy with how well everything plays together.”
   • [community] “Dagster team response: goals include (1) Local development - seamless end-to-end dev experience from laptop to CI to dev to prod, (2) managi…”
   • [claimed-docs] “uvx create-dagster@latest project my-project”

   proof ↗⚑ flag

Lineage

1. data engineerI see end-to-end lineage of my datasets — which sources, steps, and transformations produced each table

   weight 2 · round to Dagster
   Airbyte—none0/10

   Evidence shows sync scheduling, notifications, dbt integration, and a Connection Timeline of sync events, but nothing describing an actual lineage graph tracing which sources/steps/transformations produced a given table — no lineage UI, OpenLineage/dbt lineage integration, or column-level lineage is documented.

   • [claimed-docs] “The Connection Timeline displays historical information about relevant connection events.”
   • [claimed-docs] “By using the dbt Cloud integration, you can create and run dbt transformations immediately following syncs in Airbyte Cloud.”
   • [claimed-docs] “you can create and run dbt transformations immediately following syncs in Airbyte Cloud.”

   proof ↗⚑ flag

   Dagster~partialclaimed6/10

   Dagster's asset-based model explicitly encodes dependencies between assets (dagster-docs-1, dagster-docs-17 show deps=[hello]) and integrations (dbt, Airbyte, Fivetran, dlt) represent upstream data sources as assets in the same graph (dagster-docs-7/8/9/10), which together constitute an end-to-end lineage graph from source to transformation. However, the evidence pack never explicitly names or shows the Asset Graph/lineage UI itself, nor independent confirmation that lineage visualization works well in practice. Missing for 10: explicit documentation/screenshot of the lineage/asset-graph visualization UI, and independent/hands-on corroboration of viewing end-to-end lineage across tools.

   • [claimed-docs] “An asset definition is a description, in code, of an asset that should exist and how to produce and update that asset.”
   • [claimed-docs] “import dagster as dg@dg.assetdef hello(context: dg.AssetExecutionContext): context.log.info("Hello!")@dg.asset(deps=[hello])”
   • [claimed-docs] “Use Dagster's UI or APIs to run subsets of your dbt models, seeds, and snapshots.”
   • [claimed-docs] “Using this integration, you can trigger Airbyte syncs and orchestrate your Airbyte connections from within Dagster”
   • [claimed-docs] “provides a FivetranAccountComponent which can be used to easily represent Fivetran connectors as assets in Dagster”
   • [claimed-docs] “provides a DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster”

   proof ↗⚑ flag

Orchestration

1. data engineerI define dependencies between pipeline steps and datasets, and the platform orchestrates runs in the right order

   weight 2 · round to Dagster
   Airbyte~partialclaimed4/10

   Airbyte supports basic sequencing—sync schedules to trigger connections and dbt Cloud transformations that run immediately after a sync—which is a simple two-step dependency, and its API is explicitly positioned to be called by external orchestrators like Airflow for more complex sequencing. However, there's no evidence of a native DAG/dependency-graph feature where a data engineer can define multi-step, multi-dataset dependencies purely within Airbyte itself; the docs point to pairing with Airflow rather than Airbyte doing the orchestration natively. Missing for 10: native cross-connection dependency graphs, conditional/multi-step DAG definition within Airbyte UI, and evidence of complex dependency chains beyond sync-then-dbt.

   • [claimed-docs] “For each connection, you can select between three options that allow a sync to run.”
   • [claimed-docs] “By using the dbt Cloud integration, you can create and run dbt transformations immediately following syncs in Airbyte Cloud.”
   • [claimed-docs] “you can create and run dbt transformations immediately following syncs in Airbyte Cloud.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte.”

   proof ↗⚑ flag

   Dagster✓fullprobed9/10

   Dagster's core model is asset/job definitions with explicit dependencies (deps=[...]) that the platform resolves into execution order, backed by schedules/sensors/declarative automation for orchestrating runs, and this is corroborated by hands-on runtime probes confirming a working project actually runs (dagster dev boots, webserver responds). Community feedback also affirms the asset-dependency approach as a core differentiator vs task-based tools. Missing for 10: independent large-scale production case study detailing complex DAG ordering at scale.

   • [claimed-docs] “An asset definition is a description, in code, of an asset that should exist and how to produce and update that asset.”
   • [claimed-docs] “import dagster as dg@dg.assetdef hello(context: dg.AssetExecutionContext): context.log.info("Hello!")@dg.asset(deps=[hello])”
   • [claimed-docs] “Schedules enable automated execution of jobs at specified intervals.”
   • [claimed-docs] “Sensors enable you to take action in response to events that occur either internally within Dagster or in external systems.”
   • [claimed-docs] “Declarative Automation is a framework that uses information about the status of your assets and their dependencies to launch executions of y…”
   • [community] “Dagster natively isolates tasks in the DAG into separate Kubernetes pods... I find Dagster's approach is more Pythonic than Airflow's standa…”
   • [community] “I believe Dagster is hitting the right chord: they focus on the pain points in DX for Airflow and similar solutions, they have figured out h…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”

   proof ↗⚑ flag

Pricing

1. data platform leadThe pricing model is published and predictable — I can estimate what a new source costs before connecting it

   weight 2 · round drawn
   Airbyte—none0/10

   The evidence pack shows only a generic pricing page listing feature tiers (Multiple Workspaces, SSO, RBAC) with no per-connector or per-source cost breakdown, and no documentation letting a buyer estimate cost before connecting a new source. Community evidence instead surfaces billing opacity (unresponsive billing support, confusion over what's free vs paid), which is the opposite of a clearly published, predictable pricing model.

   • [claimed-docs] “Multiple Workspaces SSO, RBAC”
   • [community] “Just to clarify, this is not a fully open source project. More like freemium... If you want security, you have to pay. There are non-free pa…”
   • [community] “Your billing support email forwards to a google group which rejects the email entirely. So i embedded my question inside the website's sales…”

   proof ↗⚑ flag

   Dagster—none0/10

   The only pricing evidence is a generic plan listing (Solo Plan $10/month) with no unit economics tied to data sources, connectors, or compute usage that would let a platform lead estimate the cost impact of connecting a new source before doing so. Missing for 10: any documented cost driver (e.g., per-asset, per-run, or per-source pricing), usage calculator, or worked example showing how adding a new connector/source changes the bill.

   • [claimed-docs] “Solo Plan $10 per month Personal projects and simple pipelines ... 30-day free trial”

   proof ↗⚑ flag

1. ai-native userControl data retention and deletion

   weight 2 · round to Dagster
   Airbyte—none0/10

   The evidence pack shows no documentation of data retention policies, deletion controls, or PII/GDPR compliance features in Airbyte's platform; the only related community comment (airbyte-comm-2) actually raises unresolved concerns about handling hard deletions from sources rather than confirming a retention/deletion control feature.

   • [community] “I had a read through your docs but was unable to find any info on how you handle the sync of hard deletions from sources. We use Stitch at t…”

   proof ↗⚑ flag

   Dagster~partialclaimed3/10

   Dagster docs mention a feature for 'wiping and deleting dynamic partitions in a single action,' which gives some control over deleting specific partition data, but there is no documentation of broader data-retention policies (e.g., run history/log retention, PII deletion, GDPR controls) that an AI-native user could configure. missing for 10: retention policy configuration for run/event logs, documented data-deletion/export workflows, compliance-oriented retention settings, independent corroboration of these controls in practice.

   • [claimed-docs] “wiping and deleting dynamic partitions in a single action now also supports multi-partitioned assets that use the dynamic partitions definit…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Airbyte—none0/10

   Evidence confirms Airbyte/PyAirbyte collects anonymous telemetry by default (airbyte-probe-rt-1), but there is no documentation or evidence of any opt-out mechanism, environment variable, or setting to disable this tracking.

   • [probe] “PROBE runtime (recorded 2026-09-08): PyAirbyte installed keylessly from pypi into a throwaway venv (uv pip install airbyte) and imported cle…”

   proof ↗⚑ flag

   Dagster—none0/10

   No evidence pack item mentions telemetry, usage tracking, or opt-out settings for Dagster; this is an applicable axis for a data orchestration platform but no documentation or community evidence addresses it.

   ⚑ flag

Reverse etl

1. analytics engineerI sync modeled warehouse data back into SaaS tools (CRM, ads, support) to activate it where teams work

   weight 2 · round drawn
   Airbyte—none0/10

   The evidence pack documents Airbyte's connector catalog, sync modes, CDC, scheduling, and API/Terraform tooling, but nothing addresses syncing modeled warehouse data back out to SaaS tools like CRM, ads, or support platforms (reverse ETL). Airbyte is framed throughout as ingesting into warehouses/lakes, not activating data out to SaaS destinations.

   • [github] “Airbyte provides a catalog of 600+ connectors for APIs, databases, data warehouses, data lakes”
   • [claimed-docs] “A sync mode is a combination of a source and destination mode together.”
   • [claimed-docs] “A sync mode governs how Airbyte reads from a source and writes to a destination.”

   proof ↗⚑ flag

   Dagster—none0/10

   Dagster's integrations documented here (dbt, Airbyte, Fivetran, dlt) are for ingesting/transforming warehouse data, not for syncing modeled data back out to CRM/ads/support SaaS tools; no reverse-ETL connector or activation-specific capability (e.g., Census/Hightouch equivalent, Salesforce/HubSpot writers) appears anywhere in the evidence pack.

   ⚑ flag

Evolution

1. data engineerUpstream schema changes are detected and propagated by a policy I choose, instead of silently breaking loads

   weight 3 · round to Airbyte
   Airbyte✓fullclaimed7/10

   Airbyte's docs explicitly describe a dedicated schema-change-management feature letting engineers specify per-connection how to handle source schema changes (e.g., propagate, pause, ignore) rather than fail silently, backed by related core-concept docs on sync modes and connection timeline history for tracking changes. Missing for 10: detailed enumeration of the actual policy options/behavior, and independent/hands-on confirmation that schema-change detection works reliably in production (community evidence only touches on unrelated deletion-sync gaps).

   • [claimed-docs] “You can specify for each connection how Airbyte should handle any change of schema in the source.”
   • [claimed-docs] “A sync mode is a combination of a source and destination mode together.”
   • [claimed-docs] “The Connection Timeline displays historical information about relevant connection events.”

   proof ↗⚑ flag

   Dagster~partialclaimed5/10

   Dagster provides generic primitives that could be composed into a schema-change policy: asset checks can 'verify that a tabular asset adheres to a specified schema' (dagster-docs-3, dagster-docs-20), sensors can react to internal/external events (dagster-docs-5), and Declarative Automation can launch downstream runs based on asset/dependency status (dagster-docs-6). However, there is no first-party feature specifically for detecting upstream schema drift and applying a chosen propagation policy (e.g., automatic column mapping, contract versioning, or schema-diff alerts) — engineers would need to hand-build this from checks+sensors themselves. missing for 10: a dedicated schema-change-detection/propagation feature, docs showing schema diffing across runs, and independent/hands-on confirmation that this composed approach reliably prevents silent breakage.

   • [claimed-docs] “Ensure a particular column doesn't contain null values * Verify that a tabular asset adheres to a specified schema * Check if an asset's…”
   • [claimed-docs] “Ensure a particular column doesn't contain null values”
   • [claimed-docs] “Sensors enable you to take action in response to events that occur either internally within Dagster or in external systems.”
   • [claimed-docs] “Declarative Automation is a framework that uses information about the status of your assets and their dependencies to launch executions of y…”

   proof ↗⚑ flag

Normalization

1. analytics engineerLoaded data lands as typed, deduplicated destination tables ready to query, not raw JSON blobs

   weight 1 · round to Airbyte
   Airbyte✓fullclaimed8/10

   Airbyte's typing-and-deduping feature documents exactly this story: one-to-one stream-to-table mapping ('No more sub-tables'), typed destination schemas, and dedup handling, combined with CDC support for capturing deletes/updates and schema-change management for evolving sources. missing for 10: independent/hands-on confirmation that destination tables are fully typed and deduped in practice (only vendor docs cited), and no evidence addressing edge cases like large-table or complex nested JSON typing fidelity.

   • [claimed-docs] “One-to-one table mapping: Data in one stream will always be mapped to one table in your data warehouse. No more sub-tables.”
   • [claimed-docs] “You can specify for each connection how Airbyte should handle any change of schema in the source.”
   • [claimed-docs] “A consumer of these log files (such as Airbyte) can read these logs while keeping track of the current position within the logs in order to …”
   • [claimed-docs] “Many common databases support writing all record changes to log files for the purpose of replication.”
   • [claimed-docs] “An incremental sync is a sync which pulls only the data that has changed since the previous sync”

   proof ↗⚑ flag

   Dagster~partialclaimed5/10

   Dagster provides asset checks to validate schema and null constraints on tabular assets, and integrates with dbt/Fivetran/Airbyte/dlt which perform the actual typing/deduplication of loaded data, but Dagster itself is an orchestrator, not the engine producing typed/deduplicated destination tables. Missing for 10: direct evidence of Dagster performing deduplication logic, native typed-table materialization, and hands-on confirmation that end-to-end loaded tables are clean and query-ready rather than requiring the coupled dbt/Fivetran/dlt tooling to do the real work.

   • [claimed-docs] “Ensure a particular column doesn't contain null values * Verify that a tabular asset adheres to a specified schema * Check if an asset's…”
   • [claimed-docs] “Use Dagster's UI or APIs to run subsets of your dbt models, seeds, and snapshots.”
   • [claimed-docs] “provides a FivetranAccountComponent which can be used to easily represent Fivetran connectors as assets in Dagster”
   • [claimed-docs] “provides a DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster”
   • [claimed-docs] “Ensure a particular column doesn't contain null values”

   proof ↗⚑ flag

Backfill

1. data engineerBackfill history or resync a single table without rebuilding the whole pipeline

   weight 2 · round drawn
   Airbyte~partialcommunity6/10

   Airbyte's connection model lets you configure sync mode (full refresh vs incremental) per stream/table and manage schema changes per stream, which supports selectively backfilling or resyncing individual tables without touching the rest of the connection (airbyte-docs-7, airbyte-docs-22, airbyte-docs-23, airbyte-docs-14). However, the evidence pack never explicitly documents a 'reset/resync single stream' UI action or CLI/API call, and one community report shows a data engineer having to 'trick' Airbyte for a large-table resync rather than using a built-in single-table resync workflow (airbyte-comm-4), indicating real-world friction. Missing for 10: explicit docs on a per-stream reset/backfill button or API endpoint, and independent confirmation that single-table resync works smoothly at scale.

   • [claimed-docs] “A sync mode is a combination of a source and destination mode together.”
   • [claimed-docs] “An incremental sync is a sync which pulls only the data that has changed since the previous sync”
   • [claimed-docs] “A sync mode governs how Airbyte reads from a source and writes to a destination.”
   • [claimed-docs] “You can specify for each connection how Airbyte should handle any change of schema in the source.”
   • [community] “Airbyte is a godsend for us. It works really well for most use cases. Unfortunately, we had to write our custom thing for a large table (8 b…”

   proof ↗⚑ flag

   Dagster~partialclaimed6/10

   Dagster's asset-based model supports partitioned assets and explicitly supports wiping/deleting dynamic partitions (including multi-partitioned assets) for re-materialization, and asset checks can detect if an asset needs refreshing — both enabling backfill/resync of a single table without rerunning the whole pipeline. However, evidence doesn't show a dedicated 'backfill single partition/table' UI walkthrough or hands-on confirmation of partition-level backfill workflows in practice. missing for 10: explicit documentation/example of the backfill UI/CLI workflow for a single partition or asset, independent/hands-on validation of backfill behavior in production use.

   • [claimed-docs] “wiping and deleting dynamic partitions in a single action now also supports multi-partitioned assets that use the dynamic partitions definit…”
   • [claimed-docs] “Ensure a particular column doesn't contain null values * Verify that a tabular asset adheres to a specified schema * Check if an asset's…”
   • [claimed-docs] “Ensure a particular column doesn't contain null values”
   • [claimed-docs] “An asset definition is a description, in code, of an asset that should exist and how to produce and update that asset.”

   proof ↗⚑ flag

Cdc

1. data engineerI replicate databases with log-based CDC (binlog/WAL) so I capture updates and deletes without hammering the source

   weight 3 · round to Airbyte
   Airbyte✓fullcommunity8/10

   Airbyte's docs explicitly describe CDC via reading source binlog/WAL logs to capture INSERT/UPDATE/DELETE changes without full-table scans, directly matching the story (airbyte-docs-15, airbyte-docs-25). Missing for 10: independent/hands-on confirmation of CDC performance under load and per-connector CDC support details are not shown, and one old community comment raises hard-delete concerns without a concrete documented failure, so it doesn't rise to 'disputed'.

   • [claimed-docs] “A consumer of these log files (such as Airbyte) can read these logs while keeping track of the current position within the logs in order to …”
   • [claimed-docs] “Many common databases support writing all record changes to log files for the purpose of replication.”
   • [community] “I had a read through your docs but was unable to find any info on how you handle the sync of hard deletions from sources. We use Stitch at t…”

   proof ↗⚑ flag

   Dagster—none0/10

   Dagster's evidence shows it orchestrates and triggers syncs via Airbyte/Fivetran/dlt integrations, but nothing in the pack describes Dagster itself (or these integrations, as documented) performing log-based CDC (binlog/WAL) capture of inserts/updates/deletes. The story's specific mechanism—low-impact log-based replication—is unaddressed; Dagster is positioned as an orchestrator that calls out to these tools, not as the CDC engine itself.

   • [claimed-docs] “Using this integration, you can trigger Airbyte syncs and orchestrate your Airbyte connections from within Dagster”
   • [claimed-docs] “provides a FivetranAccountComponent which can be used to easily represent Fivetran connectors as assets in Dagster”
   • [claimed-docs] “FivetranAccountComponent can be used to easily represent Fivetran connectors as assets in Dagster.”
   • [claimed-docs] “provides a DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster”
   • [claimed-docs] “DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster.”

   proof ↗⚑ flag

Incremental

1. data engineerSyncs move only new and changed records — cursor and state management handled for me, not full reloads

   weight 3 · round to Airbyte
   Airbyte~partialcommunity7/10

   Airbyte's docs explicitly define incremental sync as pulling only changed data since the last sync, backed by sync-mode and CDC (log-based, position-tracked) documentation that implies automated cursor/state handling (airbyte-docs-22, airbyte-docs-7/23, airbyte-docs-15/25). However, community reports show real friction: one engineer notes unclear handling of hard deletions without CDC and another had to manually 'trick' Airbyte's state for an 8-billion-row table to avoid a full reload, indicating state management isn't always seamless in practice (airbyte-comm-2, airbyte-comm-4). Missing for 10: independent verification of cursor/state robustness across all sources, clearer documentation on hard-delete handling, and evidence of large-table incremental sync working without manual workarounds.

   • [claimed-docs] “An incremental sync is a sync which pulls only the data that has changed since the previous sync”
   • [claimed-docs] “A sync mode is a combination of a source and destination mode together.”
   • [claimed-docs] “A sync mode governs how Airbyte reads from a source and writes to a destination.”
   • [claimed-docs] “A consumer of these log files (such as Airbyte) can read these logs while keeping track of the current position within the logs in order to …”
   • [claimed-docs] “Many common databases support writing all record changes to log files for the purpose of replication.”
   • [community] “I had a read through your docs but was unable to find any info on how you handle the sync of hard deletions from sources. We use Stitch at t…”
   • [community] “Airbyte is a godsend for us. It works really well for most use cases. Unfortunately, we had to write our custom thing for a large table (8 b…”

   proof ↗⚑ flag

   Dagster—none0/10

   Dagster orchestrates external sync tools (Fivetran, Airbyte, dlt) and represents their connectors as assets, but the evidence never shows Dagster itself managing cursors/incremental-state for syncs — that logic lives in the underlying EL tools, not in Dagster's own asset/partition framework. No documentation shows Dagster performing incremental-only data movement or state tracking on its own.

   • [claimed-docs] “Using this integration, you can trigger Airbyte syncs and orchestrate your Airbyte connections from within Dagster”
   • [claimed-docs] “provides a FivetranAccountComponent which can be used to easily represent Fivetran connectors as assets in Dagster”
   • [claimed-docs] “provides a DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster”
   • [claimed-docs] “FivetranAccountComponent can be used to easily represent Fivetran connectors as assets in Dagster.”
   • [claimed-docs] “DltLoadCollectionComponent which can be used to easily represent a collection of dlt sources and pipelines as assets in Dagster.”

   proof ↗⚑ flag

Scheduling

1. data engineerI control sync frequency per pipeline — from sub-hour schedules to cron expressions and manual triggers

   weight 2 · round drawn
   Airbyte✓fullclaimed8/10

   Airbyte's sync-schedules docs explicitly state connections can be run on three options — cron expressions, scheduled cadence, or manual triggers — which directly matches the story's requirement for flexible per-pipeline scheduling, and this is reinforced by API/Terraform docs enabling programmatic control of scheduling. Missing for 10: no explicit documentation of true sub-hour minimum interval limits or independent hands-on confirmation of scheduling granularity in production.

   • [claimed-docs] “For each connection, you can select between three options that allow a sync to run.”
   • [claimed-docs] “A sync mode is a combination of a source and destination mode together.”
   • [claimed-docs] “Use the Airbyte API to programmatically interact with Airbyte. For example, you can control Airbyte in conjunction with orchestration tools …”
   • [claimed-docs] “you can use Airbyte's Terraform provider to automate and version control your Airbyte configuration as code.”

   proof ↗⚑ flag

   Dagster✓fullprobed8/10

   Dagster natively supports cron-based schedules for sub-hour or any interval, event-driven sensors, declarative automation conditions, and manual/ad-hoc job runs, giving fine-grained per-pipeline sync control; this is corroborated by docs and a runtime probe confirming the platform actually runs. missing for 10: no independent case study specifically demonstrating sub-hour scheduling in production or explicit per-asset frequency override examples.

   • [claimed-docs] “Schedules enable automated execution of jobs at specified intervals.”
   • [claimed-docs] “Sensors enable you to take action in response to events that occur either internally within Dagster or in external systems.”
   • [claimed-docs] “Declarative Automation is a framework that uses information about the status of your assets and their dependencies to launch executions of y…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the full agent-builds-a-project path ran keylessly end to end — `uvx create-dagster@latest project pa-p…”

   proof ↗⚑ flag

Dbt

1. analytics engineerDbt transformations run against freshly loaded data as part of the pipeline, not on a blind timer

   weight 2 · round to Dagster
   Airbyte✓fullclaimed7/10

   Airbyte Cloud's dbt Cloud integration explicitly triggers dbt transformations immediately following a sync, meaning dbt runs are event-driven on fresh data rather than a blind timer. This is documented specifically as post-sync triggering, matching the story precisely for Airbyte Cloud users. Missing for 10: equivalent documented support for self-hosted/OSS Airbyte (non-Cloud) triggering dbt runs, technical detail on the trigger mechanism (e.g., webhook vs polling), and independent/hands-on confirmation beyond vendor docs.

   • [claimed-docs] “By using the dbt Cloud integration, you can create and run dbt transformations immediately following syncs in Airbyte Cloud.”
   • [claimed-docs] “you can create and run dbt transformations immediately following syncs in Airbyte Cloud.”

   proof ↗⚑ flag

   Dagster✓fullcommunity8/10

   Dagster models dbt models as assets with explicit dependencies, and provides Declarative Automation and sensors that launch asset executions based on upstream data/asset status rather than only fixed schedules, directly enabling dbt runs triggered by fresh data arrival. The dbt integration lets you run models/seeds/snapshots via the UI/API tied to asset dependency graphs, and asset checks can verify if data needs refreshing before/after transformation. missing for 10: independent or hands-on evidence specifically showing a dbt-on-freshness (event-driven, not timer) pipeline in production use; community evidence only confirms Dagster+dbt+DuckDB works well generally, not the freshness-trigger mechanic specifically.

   • [claimed-docs] “Declarative Automation is a framework that uses information about the status of your assets and their dependencies to launch executions of y…”
   • [claimed-docs] “Sensors enable you to take action in response to events that occur either internally within Dagster or in external systems.”
   • [claimed-docs] “Use Dagster's UI or APIs to run subsets of your dbt models, seeds, and snapshots.”
   • [claimed-docs] “Ensure a particular column doesn't contain null values * Verify that a tabular asset adheres to a specified schema * Check if an asset's…”
   • [community] “I've been working with this stack (Dagster, dbt, DuckDB) for a few months and am super happy with how well everything plays together.”

   proof ↗⚑ flag