You're on Gable: Gable Guards the Producer's Pull Request. Data Workers Owns What Gets Through
On Gable for code-level data lineage and data contracts? Keep it at the producer's pull request. Data Workers makes sure the data that still gets through is right downstream, behind approvals.
Your data starts in code, and Gable reads it there. Its static analysis scans your services in CI and traces each field from the consumer app through backend systems into the data stores, with no runtime agents, no sampling and no production overhead. Platform leads approve a lineage version as the trusted baseline, Gable tags personal data in code automatically, and audit-ready exports feed the privacy review or the BCBS 239 file. On the critical boundaries, producers publish data contracts, and gable data-asset check compares each change against them before it merges, at the enforcement level the contract owner set: record, notify, alert or block. Gable stops breaking changes at the producer's pull request. Data Workers owns whether the data that still gets through is right downstream: it catches what a clean contract check can't see, traces it through the warehouse, routes the fix to its owner and proves the fix held, behind approvals.
Gable's own blog puts it plainly: the data that hurts you is the data nobody flagged. A contract describes a boundary's shape, and plenty of bad data keeps its shape.
Key takeaways
- •Gable keeps its job. Code-level lineage, contracts, enforcement levels, data tagging, lineage approvals and audit exports stay where they are. Data Workers works with Gable from day one.
- •Data Workers covers the warehouse side of the boundary. Baselines on the models downstream catch a change that passed the contract check, and
blast_radius_analysisshows every dbt model it reaches. - •Fixes go to owners. Data Workers proposes the dbt change as a diff for the owner to merge and queues the rerun through your orchestrator after a named person approves. Contracts stay with their producers.
- •Different questions. Gable shows which code path writes a field. Data Workers shows which models broke, and, from what the team has recorded in its context graph, which syncs and dashboards sit behind them.
- •Every fix leaves a receipt: trigger, evidence, diff, approver, checks and undo path, next to the lineage Gable exports.
- •Start with a pilot on one critical producer boundary, read-only first, from L0 manual toward L4 autonomous.
Gable is the gate at the pull request. Data Workers owns what gets through.
Gable answers one question before deploy: does this change alter how data flows, and does it break a contract someone depends on? Data Workers answers the questions after it: is the data that landed right, what did it break, and what has to change, in which system, to put it right?
Here is a Tuesday at a consumer lender. A Kotlin payments-service writes installments to MySQL. Fivetran syncs that database into Snowflake hourly. dbt Core builds the models, run by a Prefect flow at 02:00. int_payments_matched joins loan_payments.account_ref to dim_accounts.account_number; fct_delinquency_daily counts days past due from it; a collections_queue model feeds a Hightouch sync to Salesforce at 07:00; the credit risk team reads delinquency in Tableau. loan_payments carries a Gable contract that collections and finance subscribe to. Accounts are moving to a new ledger that identifies each account by a UUID. After every run, the Prefect flow posts two numbers to Data Workers' metric monitor (monitor_metrics): rows loaded and payments matched. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Tue 14:05 | GitHub | The ledger team opens a pull request on payments-service: for migrated accounts, write the ledger UUID into account_ref |
| 14:09 | Gable | gable data-asset check runs in CI against the contract on loan_payments. Same field, same VARCHAR(64) type, no violation. The result posts as a pull request comment; reviewers merge |
| 15:30 | MySQL | The release deploys. Installments for migrated accounts, about 12% of the book, carry ledger UUIDs |
| Hourly | Fivetran | Each sync lands the rows in Snowflake raw_payments.loan_payments, exactly as written |
| Wed 02:00 | Prefect | The flow runs dbt build. The inner join in int_payments_matched finds no account for 4,180 payments and drops them; fct_delinquency_daily shows 3,950 borrowers one day past due. Every dbt test passes |
| 02:41 | Snowflake | The flow posts its numbers. Rows loaded sit inside their baseline; payments matched fall 37% below it. monitor_metrics flags the anomaly |
| 02:44 | Snowflake | Data Workers runs run_quality_check on the raw table: no null account_ref, no duplicate payment_id. Loads normal, matches down: the loss sits in the join |
| 02:47 | Slack and Spellbook | Data Workers posts the finding to data on-call: the join key, the first affected load (Tue 15:00) and the blast radius from blast_radius_analysis (int_payments_matched, fct_delinquency_daily, collections_queue). Context-graph notes the team recorded add the 07:00 Hightouch sync and the Tableau dashboard. It names three owners and proposes holding the sync |
| 06:35 | Hightouch | The collections lead pauses the 07:00 sync. Nobody gets a call about a payment they made |
| 08:20 | Gable | The ledger engineer reviews the version changes on payments-service in Gable: the new ledger code path writes account_ref, and the lineage shows the ledger also publishes an account map that Fivetran lands as raw_ledger.account_map |
| 08:40 | GitHub and dbt | Data Workers proposes the fix as a diff for the analytics engineer: resolve account_ref through raw_ledger.account_map in stg_loan_payments, plus a relationships test so an unmatched key fails loudly. Its pull request review shows the three models and no column changes for readers |
| 09:20 | Spellbook and Prefect | The engineer merges. The data owner approves the rerun in Spellbook; Data Workers queues the Prefect flow with a full refresh of the three models and reads the flow run's status |
| 10:15 | Snowflake | Payments matched return to baseline in monitor_metrics; run_quality_check passes on fct_delinquency_daily. Delinquency drops back by 3,950 |
| 10:30 | Spellbook | Data Workers writes the receipt: alert, checks, diff, approver, rerun, before and after counts, undo path. The collections lead resumes the sync. The ledger team adds a character-length constraint on account_ref to the Gable contract, so the agreed format is on record |
Gable did its job exactly. The field kept its name and type, so the contract held. The break was in meaning: one column now carried two kinds of key. The code was correct and the data was valid, so no static check could see it; it showed up only when the data met a join in the warehouse. That is where Data Workers stands.
| Job | What Gable does | What Data Workers does |
|---|---|---|
| The change | Scans the producer's code in CI and checks it against the contract | Watches what the change does to the data after it lands, with checks and baselines |
| The boundary | Contract owners set enforcement from record to block; subscribers follow violations | Covers the models past the boundary, plus the syncs and dashboards the team has noted |
| The lineage | Traces each field through services into data stores, from code | Traces each table through dbt models with blast_radius_analysis |
| The cause | Shows which code path writes a field and what changed in a version | Narrows a bad number to the table, column and load where it started |
| The fix | Producers change their code and tighten their contracts | Proposes the dbt change as a diff; queues the Prefect rerun after approval |
| The proof | Approved lineage versions and audit exports | A receipt per fix: evidence, approver, checks, before and after, undo path |
Why doesn't Gable just do this itself?
Because Gable is static on purpose. It reads code, not rows: no runtime agents, no sampling, no production overhead, no data exposure risk. That choice is why regulated enterprises can point it at every service they own, and why its lineage holds up in front of an auditor. It also means Gable never sees the values a service writes, so a change that keeps a field's shape and changes its meaning passes every static check by construction. Gable's own direction agrees: contracts on the few boundaries where real agreement exists, code-level lineage across everything else.
Working on the warehouse side is a different product with a different liability: credentials to the warehouse and orchestrator, context about Fivetran, dbt, Prefect, Hightouch and Tableau, blast radius across them, a named owner's approval for each change, a rollback path and proof the fix held. A lineage tool holding warehouse access would lose the property its buyers value most: it touches no data. Data Workers is the product on the other side of that line.
Every tool owns a slice. Data Workers covers the whole lifecycle
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, and it builds on the tools already there.
Gable's home stage is Schema & Migration, where it ties Data Workers for work done before deploy; its next strength is Catalog & Context, from code.
| Stage | Data Workers | Gable | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 7 | Gable maps every field through your services from the code, with approved lineage baselines. Data Workers joins warehouse-side lineage to quality, runs and ownership in one governed graph. |
| Analytics & Insights | 8 | 2 | Gable answers where a field comes from and goes. Data Workers answers questions about the data itself from governed context. |
| Data Quality | 8 | 6 | Contracts check the shape of producer data before it ships. Data Workers checks values after they land, with null, key and row-count checks and baselines. |
| Observability & Incidents | 8.5 | 3 | Gable works before deploy, in CI, by design. Data Workers detects, diagnoses, fixes and verifies incidents that reach the warehouse. |
| Pipelines & Ingestion | 8.5 | 4 | Gable reads the services that produce data; it does not run pipelines. Data Workers queues reruns after approval and reviews pipeline changes. |
| Schema & Migration | 8 | 8 | Gable's home stage, a tie: contract checks on the producer's change in CI, Avro and Protobuf schemas published from the repo. Data Workers covers the warehouse side: impact on readers, the dbt fix as a diff, migrations with rollback. |
| Governance & Access | 8.5 | 6 | Contract owners, subscriptions and enforcement levels give an agreed boundary. Data Workers routes each data change to a named approver and keeps the record. |
| Security & Privacy | 8 | 6.5 | Gable tags personal data in code and shows where it flows before AI consumption. Data Workers proposes classifications on warehouse columns for their owners. |
| Cost / FinOps | 8 | 1 | Gable does not manage warehouse spend. Data Workers attributes Snowflake spend to dbt models through query tags and reads AWS Cost Explorer. |
| MLOps & Models | 7.5 | 3 | Gable documents which fields reach models and chatbots. Data Workers keeps the training and feature data under them healthy. |
Scores are directional measures of scope, not benchmarks.
How Gable and Data Workers work together
Your people stay where they are: producers in their repos with Gable in CI, analytics engineers in dbt, risk analysts in Tableau, and Claude, Cursor or GitHub Copilot for questions and code. Spellbook Data Catalog (in preview) is where the data team looks: each finding, proposed change, blast radius, approver and rollback, with approval requests reaching people in Slack or email. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with 20+ specialist agents, and the Autonomous Data-Conductor runs each fix (detect, diagnose, fix, review, verify, remember) behind per-domain guardrails.
Where Gable fits. Data Workers connects to Gable over its REST API today, and Gable stays the system of record for code-level lineage, contracts and their owners. Gable's surface is its REST API and CLI (contracts, data assets, contract checks, lineage export). Data Workers reads natively what sits downstream: Snowflake checks, the dbt manifest, pull requests on GitHub and Prefect flow runs, among 50+ connectors; Fivetran, MySQL and Hightouch connect over their APIs today. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis, and open incidents through get_incident_history.
What Data Workers writes, and where. To Gable, nothing: contracts, constraints and enforcement levels belong to their producers, and a finding goes to the producing team with the evidence attached. dbt fixes go to the model owner as a diff to merge. Reruns are queued through your orchestrator after approval. Ingestion and reverse-ETL syncs are paused and resumed by their owners. Data cleanups are proposed for the owner to approve and apply. Approved facts, such as "account_ref holds an account number or a ledger UUID", land in the Context Wizard graph for the next agent and engineer.
Setup today. Data Workers' agents come from the open-source repository: clone it and add start-agent.sh entries to your client config, as the client setup docs show.
// Example: .mcp.json for Claude Code
{
"mcpServers": {
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
},
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
}
}
}List the tools with your client's own command (/mcp in Claude Code), then ask "which models read raw_payments.loan_payments, and what breaks if account_ref stops matching dim_accounts?"
One request, L0 to L4. The autonomy ladder is set per domain, so payments can sit at a different level from marketing.
- •L0 manual. Connected, not acting. Engineers find the dropped payments when a borrower calls.
- •L1 observe. Data Workers flags each baseline break with its blast radius and owners and logs what each action would have needed.
- •L2 propose. Data Workers drafts the dbt diff and the rerun plan; owners approve before anything runs.
- •L3 act reversibly. For proven classes, such as queuing the rerun after a fix merges, Data Workers acts, verifies and records it. Code still arrives as diffs.
- •L4 autonomous. For a scoped, trusted class in one domain, Data Workers runs the loop end to end and posts the receipt for review.
Read more on safety, how approvals work, the autonomy levels and where your data goes. On the access side of the same estate, see You're on Immuta, You're on Varonis and You're on BigID.
What changes for your team
Teams on Gable already did the hard cultural work: producers own their data, and contracts sit on the boundaries that matter. What still costs them time is everything past the merge: the 02:00 drop nobody can explain, the hunt through dbt for every model a field reaches, the ticket that bounces between producers and analytics. With Data Workers, those jobs run on autopilot at the level you set.
- •Incidents. A break that got past the contract arrives traced, fixed through its owner and recorded.
- •Data quality. Nulls, keys, row counts and baselines are checked after each run, and failures go to the cause.
- •Cloud spend. Snowflake spend is tied to each dbt model through query tags, and the fix goes to that model's owner.
- •Access. Grant changes a fix needs arrive as proposals; Unity Catalog changes apply after approval.
- •Audits. Each change links the trigger, approver, checks and undo path, next to the lineage Gable exports.
- •Migrations. Each wave is planned with its parity checks, and the owner signs off before it closes.
The data engineers guide covers the downstream role in depth.
Keep Gable, or consolidate?
Keep Gable if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most teams on Gable keep it, especially in regulated estates where code-level lineage is the evidence auditors ask for. What they consolidate is the tooling around it: hand-written row-count scripts behind contracted tables, spreadsheets mapping producer fields to dbt models, and the on-call rotation that rebuilds that map at 3 a.m. For the contract side, see data contracts in dbt pull requests, data contracts vs schema registry and data contracts and AI agents; for regulation, BCBS 239 with AI agents and SOX, HIPAA, GDPR and the EU AI Act. Building this layer yourself? Read build it ourselves with Claude Code and MCP servers: reading a baseline is the easy part; approvals, rollback and receipts are the work.
The case for your CFO
The outcome: the numbers past every contract are right, and when a change slips through, it is caught and fixed before it reaches a customer, a regulator or a collections call. Gable keeps breaking changes out at the pull request; Data Workers owns what still gets through.
The risk story is plain. Data Workers changes nothing in Gable or in your application code. Model fixes arrive as diffs your engineers merge; reruns run only after a named approver says yes; sync pauses and data cleanups stay with their owners. Each action leaves a receipt with the trigger, evidence, diff, approver, checks and undo path. Unanswered requests expire and escalate; they never auto-grant. No agent can promote its own work. Autonomy is set per domain from L0 manual to L4 autonomous, and an org-wide stop halts all autonomous dispatch. The agents run in your infrastructure; your data stays in your systems, and the hosted Conductor sees workflow metadata only. Zero migration.
Why now: producers ship faster with coding agents, and any release can change what a field means without changing its shape. The first win is one producer boundary, read-only, with baselines on the models downstream and a report of every break they would have caught. What stays the same: your Gable licence, contracts, lineage approvals and producer ownership. Start with a pilot; the path is on the pricing page, and the pilot is credited in full against the first year. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Gable stops breaking changes before they ship; Data Workers makes sure the data that ships anyway is right, with an approval and a receipt for every fix."
Getting started
Start with a pilot. Pick the producer boundary your business feels first, such as payments, claims or orders, connect Data Workers read-only to the Snowflake models, dbt project, pull requests and orchestrator runs downstream of it, record baselines on the numbers that matter, and let it report what it would have caught before you turn on the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers enforce our data contracts? No. Contracts and their enforcement levels stay in Gable with the producers who own them. Data Workers works downstream of the boundary: it checks the data after it lands, traces what a bad change reaches and proposes the fix to the model owner.
If Gable already blocks breaking changes, what is left to break? Changes that keep a field's name and type and change its meaning: a new kind of key, a new unit, a field one code path stops filling. They pass a static check by design. Data Workers catches them with checks and baselines on the warehouse side.
Does Data Workers read Gable? It connects over Gable's REST API today. In practice the two meet in the incident: Data Workers narrows a bad number to a table, column and load, and the producing team uses Gable's lineage to find the code path behind it.
Does Data Workers change our application code? No. Producers own their code. Data Workers sends the producing team the evidence and proposes changes on the data side: dbt models as diffs, reruns after approval.
Will this help with BCBS 239 or other audits? Data Workers produces evidence, a receipt per fix and a tamper-evident audit log, which sits next to the lineage Gable exports. Your compliance team and auditors decide what satisfies a requirement.
Where does our data go? The agents run in your infrastructure and hold the credentials. Your data stays in your systems; the hosted Conductor sees workflow metadata only, such as table names, proposals and approvals, never rows, credentials or model keys.
Sources
- •Gable, home page: code-level data flow lineage, static analysis with no runtime agents, BCBS 239, data contracts, https://www.gable.ai/ (checked Oct 3, 2026)
- •Gable docs, introduction, https://docs.gable.ai/intro.md (checked Oct 3, 2026)
- •Gable docs, documentation index (REST API and CLI; no MCP page), https://docs.gable.ai/llms.txt (checked Oct 3, 2026)
- •Gable docs,
gable data-asset check(checks assets against a contract; Kotlin and MySQL source types; markdown output for PR comments), https://docs.gable.ai/docs/cli/data-asset/check.md (checked Oct 3, 2026) - •Gable API, contract enforcement levels (RECORD, NOTIFY, ALERT, BLOCK, INACTIVE), https://docs.gable.ai/api-reference/contract/create-a-contract-enforcement-level.md (checked Oct 3, 2026)
- •Gable API, contract constraints (string constraints: charLength, isNotEmpty, isNull, isNullThreshold), https://docs.gable.ai/api-reference/constraints/get-contract-constraints.md (checked Oct 3, 2026)
- •Gable docs, lineage version approvals, https://docs.gable.ai/docs/impact/approvals.md (checked Oct 3, 2026)
- •Gable docs, data tagging (PII tag applied automatically), https://docs.gable.ai/docs/tracing/data-tagging.md (checked Oct 3, 2026)
- •Gable docs, auto-publish Avro and Protobuf schemas, https://docs.gable.ai/docs/resources/auto-publish-datastore-schemas.md (checked Oct 3, 2026)
- •Gable docs, product changelog (Jun 15 to Jul 10, 2026), https://docs.gable.ai/docs/releases/product_changelog.md (checked Oct 3, 2026)
- •Gable blog, "Why You Can't Seem to Adopt Data Contracts No Matter How Hard You Try" (Jul 21, 2026), https://www.gable.ai/blog/why-you-cant-seem-to-adopt-data-contracts-no-matter-how-hard-you-try (checked Oct 3, 2026)
- •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)
- •Data Workers open-source repository, agent tools and start-agent.sh, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers pricing, pilot and hosted Conductor, https://dataworkers.io/pricing/ (checked Oct 3, 2026)