You're on Great Expectations: GX Core Is the Test. Data Workers Fixes What Fails It
GX Core runs your Expectation Suites and stops bad data. Data Workers diagnoses each failed Checkpoint, fixes it behind approvals, verifies it and leaves a receipt.
Your data engineers write Expectations. They group them into Expectation Suites, bind them to Batch Definitions, wrap them in Checkpoints and run those Checkpoints inside Airflow tasks, Dagster assets, Prefect flows or a plain Python job next to dbt. When a Checkpoint fails, its Actions post to Slack and refresh Data Docs, and with the Airflow provider's GXValidateCheckpointOperator the task fails and the bad batch goes no further. That is exactly what Great Expectations is for, and it has been one of the most widely used open-source data quality frameworks for years. This year its home changed: FICO acquired GX Cloud, which has not been publicly available since June 1, 2026, and Fivetran became the steward of GX Core and its community. GX Core stays Apache 2.0, and releases keep shipping from the Fivetran-hosted repository (1.23.2 on September 28, 2026).
A failed Checkpoint tells you order_ref is null on 41% of last night's rows and stops the DAG. Somebody still has to find the upstream change, decide what the fix touches, get it approved, rerun the right tasks and confirm the dashboards. Great Expectations is the test. Data Workers fixes what fails it: it diagnoses, fixes and verifies behind approvals, and leaves a receipt.
Key takeaways
- •Your suites stay yours. Expectation Suites, Checkpoints, Actions and Data Docs keep running where they run today, as code your team owns.
- •A failed Checkpoint becomes a work item with a diagnosis. Data Workers reads the failed DAG run through its Airflow connector, re-checks the data in the warehouse, traces lineage and proposes the full fix with its blast radius.
- •A named owner approves; Data Workers verifies. The data owner approves in Spellbook, Data Workers queues the rerun through Airflow, checks volume and quality downstream, and files the receipt.
- •Teams coming off GX Cloud keep the semantics. Data Workers' own quality checks use the same
mostlythresholds and BOOLEAN_ONLY, BASIC, SUMMARY and COMPLETE result formats your Expectations use, and its Great Expectations connector reads GX Cloud validation results and monitors through the GX Cloud API wherever that access remains. - •Autonomy per domain. Each data domain climbs from L0 manual to L4 autonomous at the pace your team sets.
Great Expectations is the test. Data Workers is the fix.
GX is the inspection you wrote yourself, test by test. Data Workers is the repair crew. Here is a Tuesday with both in place, across a logistics partner's file drop to S3, Airflow, Snowflake, GX Core, dbt Core and a Tableau workbook the operations team opens at its 8 a.m. standup. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| Mon 23:40 | 3PL partner (SFTP to S3) | The west warehouse upgrades its export tool; the shipments CSV header order_ref becomes order_reference. The east warehouse's file is unchanged |
| Tue 02:15 | Airflow | The shipments_daily DAG's load_raw task copies both files into Snowflake by column name; the task succeeds |
| 02:16 | Snowflake | 41% of the rows in raw.shipments land with a null order_ref |
| 02:20 | GX Core | validate_raw runs the shipments_raw Checkpoint; expect_column_values_to_not_be_null on order_ref (mostly 0.99) fails; the Slack Action posts and the operator raises GXValidationFailed |
| 02:21 | Airflow | The dbt Core tasks downstream skip as upstream_failed; fct_deliveries stays on Monday's data |
| 02:24 | Data Workers | Reads the failed run through its Airflow connector, re-checks the null rate in Snowflake by warehouse and finds every null in rows from the west file, loaded under a header that no longer matches |
| 02:31 | Data Workers | Traces lineage: stg_shipments, fct_deliveries, the Tableau on-time delivery workbook and the carrier SLA report sit in the blast radius |
| 02:40 | Data Workers | Proposes the fix in Spellbook: a diff to the load mapping that accepts both header names, a rerun plan from load_raw, and a column-set Expectation for the suite so a renamed header fails at the file next time |
| 06:50 | Spellbook | The shipments data owner, paged through Slack, reviews the diff and blast radius, approves and merges the change |
| 07:00 | Airflow | Data Workers queues the rerun from load_raw; the DAG replaces Tuesday's partition, the Checkpoint passes and the dbt tasks build |
| 07:25 | Snowflake | Data Workers verifies row volume on fct_deliveries per warehouse against recent Tuesdays and a zero null rate on order_ref |
| 07:40 | Tableau | The scheduled extract refresh shows Tuesday's deliveries; Data Workers files the receipt and records the fix for next time |
Great Expectations did its job perfectly: it caught a partial break a row count would have missed and stopped the bad batch before dbt built on it. What changed is everything after the stop: the cause came from the data, the fix arrived with its blast radius, one named person approved it, and the rerun went through the DAG you already trust.
| Job | What Great Expectations does | What Data Workers does |
|---|---|---|
| The rule | Expectations and Suites state what good data looks like, versioned with your code | Reads those rules as context and proposes new Expectations when a fix shows a gap |
| Detection | A Checkpoint validates a batch and fails the task when an Expectation misses its mostly threshold | Watches freshness and volume itself, and re-checks a failed batch in the warehouse with the same semantics |
| Root cause | Validation Results show which Expectation failed and sample unexpected values | Joins the failed run to orchestrator history, lineage, recent schema changes and incident history to find what changed |
| The fix | Out of scope by design: the Action notifies and the pipeline stops | Proposes the complete fix (code diff, rerun plan, data cleanup if needed, new Expectation) with blast radius, routed to a named owner |
| Running it | Your engineer edits code and clears tasks by hand | The owner approves in Spellbook; Data Workers queues the rerun through Airflow |
| Verification | The Checkpoint passes on the next run | Checks volume and quality on every downstream model the fix touched |
| The record | Validation Results and Data Docs | A receipt: the cause, the diff, who approved it, what it touched, how it was verified and how to undo it |
Why doesn't Great Expectations just do this itself?
Because a testing framework is the right thing for Great Expectations to be. GX Core describes data with expressive assertions and validates batches against them; a Checkpoint "executes one or more Validation Definitions and then performs a set of Actions based on the Validation Results." Actions notify people and update Data Docs. GX never changes the data it validates, and it does not need to know which Airflow task loaded the batch, which dbt models read it or which Tableau workbook the operations team opens at eight. That narrow scope is why teams can drop a Checkpoint into any pipeline without a security review of what it might change.
The stewardship change keeps that focus: GX Core is a community-driven project with Fivetran supporting maintenance and integrations, while GX Cloud and its AI features went to FICO.
Fixing what fails is a different product with different liability. The fix has to be checked against everything downstream, approved by a named owner, undoable before it runs, rerun through the orchestrator in the right order, proven on the downstream numbers and recorded for the next audit. That means owning changes in Airflow, Snowflake and dbt, systems a Checkpoint runs inside but does not run. Data Workers is built for exactly that job.
Every tool owns a slice. Data Workers covers the whole lifecycle
Great Expectations owns the assertion: the clearest, most portable way to say what good data looks like. Each point tool adds another console, another contract and another handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, building on the suites your engineers already wrote.
| Stage | Data Workers | Great Expectations | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 3 | Expectation Suites and Data Docs document what each table should look like. Data Workers keeps one governed context graph of definitions, owners, lineage, quality and usage across every platform. |
| Analytics & Insights | 8 | 2 | GX validates data; it does not answer business questions. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 9 | GX's home stage: hundreds of declarative Expectations, mostly thresholds and Checkpoints that run anywhere Python runs. Data Workers runs its own checks with the same semantics and repairs what fails. |
| Observability & Incidents | 8.5 | 4 | Checkpoint Actions post to Slack and stop the pipeline; there is no incident object. Data Workers diagnoses across systems, fixes with approval and verifies the fix. |
| Pipelines & Ingestion | 8.5 | 3 | Checkpoints run inside Airflow, Dagster or Prefect tasks and fail them on bad data. Data Workers reruns and backfills through your orchestrator, with approvals. |
| Schema & Migration | 8 | 4 | Column-set and type Expectations catch a schema change once it lands. Data Workers catches schema changes, scores their blast radius and plans migrations in waves. |
| Governance & Access | 8.5 | 2 | GX Core has no access model of its own. Data Workers runs the warehouse access request queue with time-bound, approved grants. |
| Security & Privacy | 8 | 2 | Expectations can assert formats on sensitive columns. Data Workers' pull request review flags new columns whose names or annotations look sensitive, and leaves a receipt on every data change. |
| Cost / FinOps | 8 | 1 | GX does not track warehouse spend. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 3 | Teams validate feature tables with Expectations. Data Workers keeps the data under your models fresh and correct. |
Great Expectations leads on its home stage, as it should. See Data Workers vs data observability, Bigeye, Anomalo, Sifflet and Soda vs Data Workers, Great Expectations alternatives, Great Expectations vs Soda and Great Expectations vs Soda vs AI agents.
How Great Expectations and Data Workers work together
GX Core stays inside your DAGs, failing tasks and posting to Slack. Engineers ask Data Workers from Claude Code or another MCP client what broke and what it touches. Spellbook Data Catalog (in preview) is where the data team looks: each proposed change, who approved it and how to roll it back. Between them, Data Context Wizard keeps one governed context graph across Snowflake, dbt and the rest of the estate, the Data-Agents Swarm does the work with 20+ specialist agents, the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember), and per-domain guardrails hold approvals, receipts and rollback.
What Data Workers reads and runs. Great Expectations is a native connector, and it is precise about where your results live.
- •GX Core in Airflow. A failed Checkpoint fails its task, so Data Workers picks it up there: its Airflow connector reads the DAG run and its task instances, and its quality agent re-checks the warehouse with
run_quality_checkandget_quality_score, using GX's own semantics (mostlythresholds, ordered severity, the four result formats). Your suites and Data Docs stay untouched. - •GX Cloud. For teams that ran GX Cloud before the FICO acquisition and still hold access under their transition terms, the Great Expectations connector reads validation results and monitors through the GX Cloud API, and can run a suite there on request.
- •The rest of the loop.
diagnose_incidentandget_root_causework through the evidence,trace_cross_platform_lineageandblast_radius_analysismap every model and report downstream, the dbt manifest diff shows what moved in the models, andget_incident_historychecks whether the same break happened before. The fix runs throughremediate: code changes are proposed as a diff for the owner to merge, data cleanups are proposed for the owner to approve and apply, and reruns are queued through Airflow. Verification usesrun_quality_checkandget_quality_score, and every step lands inget_audit_trail.
Setup. GX needs no change. Connect Data Workers to Airflow, Snowflake, dbt and Tableau, then add the agents to your MCP client. Each agent is an MCP server; the client setup guide documents the path: clone the open-source repo and add one start-agent.sh entry per agent.
# Example: Data Workers agents in Claude Code, from a clone of the open-source repo
claude mcp add --scope user dw-catalog -- "$(pwd)/start-agent.sh" dw-context-catalog
claude mcp add --scope user dw-incidents -- "$(pwd)/start-agent.sh" dw-incidents
claude mcp add --scope user dw-quality -- "$(pwd)/start-agent.sh" dw-quality
claude mcp add --scope user dw-schema -- "$(pwd)/start-agent.sh" dw-schemaAsk "why did validate_raw fail in shipments_daily last night, and what does the fix touch?" and the client returns the diagnosis, what it touches downstream and a proposed fix. For a shared endpoint, the Data Workers remote server serves /mcp with an API key (bearer) or OAuth tokens from your identity provider, verified through JWKS. For writing suites, see Claude Code Great Expectations tests and quality agent Expectation generation.
One failed Checkpoint, L0 to L4. The same failure at each level of the ladder, set per domain.
- •L0 manual. An engineer reads the Slack post, opens Data Docs, finds the header change and fixes it by hand.
- •L1 observe. Data Workers posts the diagnosis: the renamed header, the rows affected and everything downstream. Nothing changes.
- •L2 propose. Data Workers proposes the mapping diff, the rerun plan and the new Expectation. Nothing runs until the shipments data owner approves in Spellbook.
- •L3 act reversibly. For change classes with a proven record, such as rerunning a failed load after an approved fix, Data Workers queues the rerun, verifies it and records the receipt.
- •L4 autonomous. For a scoped domain with a long clean record, Data Workers handles the repeatable steps end to end and posts the receipt; code changes and data cleanups still go to the owner.
For the safety model, read is it safe to let AI agents change production data, how approvals work, autonomy levels L0 to L4 and rolling back an agent change. On where data lives: the agents run in your infrastructure, your data stays in your systems, and the hosted Conductor sees workflow metadata only.
What changes for your team
Great Expectations made your team write down what good data means. Data Workers makes every broken promise end in a fix.
- •Incidents. A failed Checkpoint arrives with a diagnosis, a blast radius and a proposed fix, and closes with a receipt.
- •Data quality. Each fix proposes the Expectation that would have caught it earlier, as a diff to your suite, so coverage grows from real breaks.
- •Cloud spend. Snowflake credits are traced to the dbt model behind them, and each fix goes to its owner drafted.
- •Access. A request for warehouse access becomes a scoped, time-boxed grant the data owner approves.
- •Audits. GX records what failed; Data Workers records what changed, who approved it and how to undo it.
- •Migrations. A platform move runs in approved waves, with parity checks planned and tracked for each wave and the owner's sign-off before it completes.
The on-call engineer changes most: the 2 a.m. Slack post becomes a proposal to review. See the data incident response playbook, beyond data observability: autonomous resolution and who owns the agents.
Keep Great Expectations, or consolidate?
Keep Great Expectations if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most GX Core teams keep it, and should: years of Expectation Suites are encoded knowledge about your data. Teams that relied on GX Cloud for scheduling and history can keep their suites in GX Core and let Data Workers run its own checks with the same semantics, keep the history and do the follow-through. What teams consolidate is the stack around the suites: a second quality tool alerting on the same break, hand-written rerun scripts and a runbook wiki. Weighing a build on a coding agent? Read build it ourselves with Claude Code and MCP servers: the calls are the easy part; the context graph, approvals and rollback are the work. The same pattern runs across the category: see you're on Soda, you're on Elementary and you're on Monte Carlo, and every connector in Data Workers integrations. For the category view, read what is an agentic data platform.
The case for your CFO
The outcome: your engineers already invested years in suites that stop bad data. Data Workers turns each failed Checkpoint from a morning of tracing and manual reruns into a diagnosis on arrival and a complete fix with one approval, so the numbers are current before anyone reads them.
The risk story is plain. Autonomy is set per domain: at L1 Data Workers only reads; at L2 it changes nothing until a named person approves; at L3 it applies changes it can undo. Code changes and data cleanups go to their owners. An unanswered approval request expires and escalates, never auto-grants. No agent can promote its own work. Every change carries a receipt: the cause, the diff, who approved it, what it touched downstream, how it was verified and how to undo it. An org-wide stop halts all autonomous dispatch. Zero migration: GX Core, Airflow, Snowflake, dbt and Tableau stay where they are.
Why now: GX Cloud's exit and GX Core's new steward put the quality stack on the agenda this year, and the cheapest decision is to keep the suites and add the layer that acts on them. The first win is read-only: every failed Checkpoint in one DAG family gets a diagnosis and a blast radius. What stays the same: your suites, Checkpoints, DAGs, warehouse permissions and code review. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Our Great Expectations suites stay as code we own; Data Workers turns every failed Checkpoint into an approved, verified fix with a receipt."
Getting started
Start with a pilot. Pick one DAG family whose Checkpoints fail often enough to hurt, such as partner file loads, connect Data Workers to Airflow, Snowflake and dbt, and run at L1 so every failed Checkpoint gets a diagnosis and a blast radius. Then turn on reruns after an approved fix at L2. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Is GX Core still safe to build on after the FICO and Fivetran changes? Yes. GX Core is Apache 2.0, Great Expectations says it "will always remain free," and releases continue under Fivetran's stewardship (1.23.2 shipped September 28, 2026). Your suites are code you own either way.
We were on GX Cloud. What does Data Workers give us? Where you still hold GX Cloud access under your transition terms, Data Workers' Great Expectations connector reads your validation results and monitors through the GX Cloud API. Going forward, keep your suites in GX Core and let Data Workers run checks with the same semantics, keep the history in its audit trail and act on failures.
How does Data Workers see a failed Checkpoint in GX Core? Through the orchestrator. With the Airflow provider, a failed Checkpoint raises GXValidationFailed and fails the task; Data Workers reads that run through its Airflow connector, re-checks the data in the warehouse and traces lineage.
Does Data Workers rewrite our Expectation Suites? No. When a fix reveals a gap, it proposes a new Expectation as a diff for the suite's owner to merge, under your review process.
Does Data Workers delete the bad rows? No. Data cleanups are proposed for the table's owner to approve and apply. Usually the cleanest repair is a rerun: Data Workers queues the DAG from the load task after the fix is approved, and your load logic replaces the partition.
Sources
- •Great Expectations, "An Update for the Great Expectations Community" (May 6, 2026: FICO acquires GX Cloud; not publicly available beginning June 1; Fivetran stewards GX Core), https://greatexpectations.io/blog/an-update-from-great-expectations/ (checked Oct 2, 2026)
- •Great Expectations, homepage (GX Core, Apache 2.0, "will always remain free"), https://greatexpectations.io/ (checked Oct 2, 2026)
- •Fivetran, "Fivetran to Become Steward of the Great Expectations Open Source Community and GX Core Project" (May 13, 2026), https://www.fivetran.com/press/fivetran-to-become-steward-of-the-great-expectations-open-source-community-and-gx-core-project (checked Oct 2, 2026)
- •GX Core repository and releases (1.23.2, Sep 28, 2026), https://github.com/fivetran/great_expectations (checked Oct 2, 2026)
- •GX Core docs, Create a Checkpoint with Actions (version 1.23.2), https://docs.greatexpectations.io/docs/core/trigger_actions_based_on_results/create_a_checkpoint_with_actions (checked Oct 2, 2026)
- •Great Expectations Airflow provider (operators, GXValidationFailed, result formats), https://github.com/fivetran/airflow-provider-great-expectations (checked Oct 2, 2026)
- •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)
- •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)