You're on Ternary: Ternary Is the Ledger Finance and Engineering Share. Data Workers Is Accountable for the Data Behind Every Line
Running Ternary for cloud and AI spend? Keep it. Data Workers finds the data change behind a cost alert, traces what it touches and sends each fix to its owner, behind approvals.
Your finance team runs technology spend in Ternary. AWS, Azure and Google Cloud billing land in one normalized ledger, mapped to your cost centers, GL codes and ERP chart of accounts, next to Snowflake, Databricks and token telemetry from Anthropic and OpenAI. FinOps analysts build reports, set anomaly alerts on spend and token consumption, and open cases that engineering works through Jira. The AI Observatory shows who consumes which model at what cost, and FP&A tracks credit burn against each prepaid contract. Since September the Ternary MCP server answers ledger questions in Claude or ChatGPT. Ternary is the ledger finance and engineering share. Data Workers is accountable for the data behind every line: when a cost moves because a pipeline, a model or an agent changed, it finds the data change, traces what it touches and sends each fix to its owner, behind approvals.
Key takeaways
- •Ternary keeps its job. The ledger, GL mapping, budgets, alerts, cases, the AI Observatory and the MCP server stay with finance and FinOps. Data Workers works with Ternary from day one.
- •A cost alert often has a data cause. A renamed column or a stale table can drive spend in a warehouse or an AI agent. Data Workers finds it in the dbt manifest diff, orchestrator runs and warehouse checks.
- •It traces readers first. dbt lineage and the context-graph notes your team records show which marts, dashboards and agents sit on a model.
- •Fixes go to their owners, behind approvals. dbt changes are drafted as diffs, rebuilds are queued after a named person approves, and agents' code stays with its team.
- •Every fix leaves a receipt to link from the Ternary case: diff, approver, checks, readers and each Data Workers action's model cost.
- •Start with a pilot on one domain, read-only first, and climb from L0 manual toward L4 autonomous.
Ternary is the ledger finance and engineering share. Data Workers is accountable for the data behind every line.
Ternary answers what technology costs, who owns each dollar and whether a contract is burning ahead of plan. Data Workers answers what changed in the data that made the cost move, who else reads that data and who signs off on the repair. The two meet whenever a spend spike starts in a dbt model, a schedule or a table.
Here is a week at a B2B software company on Google Cloud. A dbt Core project on BigQuery, run by a nightly Prefect flow at 03:00, builds mrt_account_health, one row per account with a health score. A Metabase dashboard for customer success reads it. So does Ask Accounts, an in-house agent: account managers ask it about renewals in Slack, and it writes SQL against BigQuery and answers with Claude through the Anthropic API, billed against a prepaid commitment under the key ask-accounts-prod. Ternary reads the Google Cloud billing export and the Anthropic token telemetry, and the FinOps analyst has an anomaly alert on token consumption grouped by key, posting to Slack. The team has recorded the Metabase dashboard as a reader in the Data Workers context graph. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Tue 15:10 | GitHub and dbt Core | The analytics engineer who owns mrt_account_health merges a pull request that renames health_score to account_health_score and updates the two dbt models that read it. CI passes |
| Wed 03:00 | Prefect and BigQuery | The nightly flow run builds the project. mrt_account_health now carries only the new column name |
| Wed 08:30 | Ask Accounts and Anthropic API | Account managers start asking about renewals. The agent's generated SQL fails with "Unrecognized name: health_score". Its retry step sends the error back to Claude and tries again, up to 25 times per question, with a longer prompt each time |
| Wed 09:00 to 18:00 | Ask Accounts and BigQuery | Some retries find mrt_account_health_v1, a table dbt stopped building in July that nobody dropped, and answer with July health scores. The rest give up after 25 attempts |
| Thu 07:00 | Ternary and Slack | After the daily refresh, the anomaly alert fires: ask-accounts-prod consumed far more tokens on Wednesday than its expected range. The prepaid Anthropic commitment is now burning ahead of the accrual |
| 09:10 | Ternary and Jira | The FinOps analyst opens an Investigation case on the alert and assigns the platform engineer who owns Ask Accounts. Ternary's Jira integration creates the issue |
| 09:30 | Claude Code | The engineer has the Ternary MCP server and Data Workers' MCP servers in one Claude Code session. Ternary's ternary_list_cost_alerts returns the alert with its baseline, and a cost query by day and API key shows the jump began Wednesday morning |
| 09:35 | dbt and BigQuery | Data Workers' change review diffs the dbt manifests from before and after Tuesday's merge and flags mrt_account_health and its two readers as modified; the model's SQL shows the rename to account_health_score. blast_radius_analysis returns the two dbt models and the Metabase dashboard from the graph. The engineer records Ask Accounts as a reader |
| 09:40 | dbt and BigQuery | The agent's logs show retries reading mrt_account_health_v1. It is not in the dbt manifest, and the data owner confirms in BigQuery that it last loaded in July |
| 09:55 | Slack and Spellbook | Data Workers posts the plan in Spellbook with the readers attached, and Slack cards go to three owners: a dbt diff that keeps health_score as an alias of account_health_score for 30 days, for the model owner; a retry cap and the new column name in the agent's prompt, for the agent owner; retiring mrt_account_health_v1, for the data owner |
| 10:05 | Spellbook and GitHub | The analytics engineer approves the diff in Spellbook and merges it |
| 10:06 | Prefect | Data Workers queues the Prefect flow run that rebuilds mrt_account_health |
| 10:35 | BigQuery | The run completes. run_quality_check, connected with a BigQuery service-account key, passes nulls on both columns and uniqueness on account_id. The agent owner's test questions return current scores on the first attempt |
| 11:00 | Ask Accounts and BigQuery | The agent owner ships a retry cap of three and the new column name. The data owner revokes the agent's access to mrt_account_health_v1 and schedules its removal |
| 11:30 | Slack | The agent owner pulls Wednesday's answers that cited the old table from the agent's logs, and the account management lead sends corrections |
| Fri 07:00 | Ternary and Spellbook | The next refresh shows ask-accounts-prod back within its expected range. The FinOps analyst closes the case with the Data Workers receipt linked, and FP&A books Wednesday's overrun against the commitment in the right period |
Nothing in Ternary was wrong. The alert fired on the right key, the ledger put the overrun on the right contract and the case reached the right engineer within the morning. What the ledger cannot see is why a token line moved: a column rename in a dbt project, an agent's retry loop and a forgotten table, owned by three people. Ternary saw the token spend; Data Workers does not read the agent's retries or the Anthropic bill. It connected the cost to the data change, traced who reads the model, gave each owner their part and checked the mart before the agent went back to work. The graph now lists Ask Accounts as a reader, so the next change to mrt_account_health names it before merge.
| Job | What Ternary does | What Data Workers does |
|---|---|---|
| The ledger | Normalizes cloud, SaaS, AI and on-premise spend and maps it to cost centers, GL codes and the ERP | Leaves the ledger to finance; never writes to the GL or reconciles invoices |
| Detection | ML anomaly alerts and thresholds on spend, token consumption and unit cost, per report | Checks the data side: keys, nulls and row counts in BigQuery or Snowflake, and the baselines your team records |
| Diagnosis | Shows which key, service or team moved, and when | Finds the data change behind it: the dbt manifest diff, orchestrator runs, lineage |
| Impact | Shows which cost center owns the spend | Traces marts, dashboards and agents through the manifest and context-graph notes |
| The fix | Opens a case, assigns an engineer, creates the Jira issue | Drafts the dbt change as a diff for its owner and queues the rebuild after approval |
| The proof | Spend back within range, overrun on the right contract | A receipt per fix: diff, approver, checks, readers and the model cost of each Data Workers action |
Why doesn't Ternary just do this itself?
Because Ternary is built around one unit of work, a line of technology spend, and one promise: that finance can trust it at period close. It reads billing exports, warehouse metadata (read-only queries on Snowflake's system views) and token telemetry. Its MCP server runs every call as the signed-in user and writes nothing except a report you ask it to save. That is right for a finance system of record: one that also edited dbt models and prompts would carry the liability for every number it reports.
Knowing that a token spike traces to a renamed column, who reads that model, and that an alias column keeps them working while the agent's owner fixes the prompt, is data-engineering knowledge. Acting on it crosses dbt, BigQuery, the orchestrator and an agent's code, each with its own owner, and needs an approver and a record. A ledger is measured on whether the books are right; the data team on whether the data those books pay for is right. Data Workers is built for the second job, on top of the ledger you already run.
Every tool owns a slice. Data Workers covers the whole lifecycle
Ternary owns its slice: technology spend as a finance-grade ledger. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail.
| Stage | Data Workers | Ternary | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 4 | Ternary maps spend to cost centers, GL codes and business units, with custom labels and data mapping: strong financial context. Data Workers joins tables, lineage, runs, owners, quality and usage in one graph. |
| Analytics & Insights | 8 | 7 | The Reporting Engine, dashboards, the AI Observatory and the MCP server answer spend questions for finance and FinOps. Data Workers answers questions about the data itself from governed context. |
| Data Quality | 8 | 1 | Ternary measures what technology costs, not whether rows are right. Data Workers checks keys, nulls, row counts and baselines and takes failures to the cause. |
| Observability & Incidents | 8.5 | 4 | Report-linked anomaly alerts, cases and Jira issues route cost surprises to an owner. Data Workers detects, diagnoses and fixes data incidents across systems, with a receipt for each. |
| Pipelines & Ingestion | 8.5 | 1 | Ternary ingests billing data; it does not run or repair your pipelines. Data Workers reads orchestrator runs, queues reruns after approval and reviews pipeline changes. |
| Schema & Migration | 8 | 1 | Ternary sees cost lines, not schemas. Data Workers reads model changes from the dbt manifest, assesses impact and plans migrations in approved waves. |
| Governance & Access | 8.5 | 3 | Roles and scoped views govern who sees which spend. Data Workers dry-runs grants, applies approved Unity Catalog changes and drafts the rest for their owners. |
| Security & Privacy | 8 | 3 | Ternary reads warehouse metadata with read-only queries and runs MCP calls with the user's own permissions. Data Workers keeps a receipt for every data change and proposes masking for its owner. |
| Cost / FinOps | 8 | 9 | Ternary's home stage: a multi-cloud, AI and SaaS ledger mapped to the GL, anomaly detection, commitment modeling and credit-burn tracking. Data Workers ties Snowflake spend to dbt models and finds the data change behind a cost. |
| MLOps & Models | 7.5 | 2 | The AI Observatory tracks model spend and tokens, not model or feature health. Data Workers keeps the training and feature data under models healthy. |
How Ternary and Data Workers work together
Finance stays in Ternary, its Google Sheets add-on and its assistant. Engineers stay in Claude, Claude Code or Cursor. Spellbook Data Catalog (in preview) is where the data team looks: each finding, diff, approver and rollback, with approval requests in Slack or email. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm (20+ specialist agents) does the work, and the Autonomous Data-Conductor runs each fix behind per-domain guardrails.
What Ternary keeps. The ledger and its GL and ERP mapping, showback and chargeback, budgets, alerts, cases with Jira, commitments, the AI Observatory and the MCP server. Data Workers connects to Ternary over its MCP server or API today. Ternary's remote MCP server signs in with OAuth and runs every call as you, so an engineer can ask Ternary which key moved and ask Data Workers what changed in the data, in one session. Data Workers' agents don't call Ternary's server; their checks rest on what Data Workers reads itself.
What Data Workers reads. The Cost Savings & Data Cleanup agent reads Snowflake metering and ties credits to dbt models through query tags, sums a BigQuery account total from recent jobs and reads AWS Cost Explorer by service. Around the bill it reads the dbt manifest and its lineage, run_quality_check results on Snowflake and on BigQuery (with a service-account key), monitor_metrics baselines and orchestrator runs on Prefect, Airflow, Dagster and ADF, among 50+ connectors. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis. Dashboards and in-house agents enter the graph as readers your team records.
What Data Workers changes. dbt changes are drafted as diffs for the model owner to merge. Rebuilds are queued through your orchestrator after a named person approves. An agent's prompt or retry logic stays with its team, and deletes of tables or rows are always the owner's. Ternary's ledger, labels and rules stay with finance.
Setup. Clone the open-source repository 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-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
},
"dw-connectors": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-connectors"]
}
}
}Then add Ternary's server per its documentation for your region, and sign in from /mcp.
# Example: Ternary MCP server in Claude Code (US region)
claude mcp add --transport http ternary https://core-api.ternary.app/mcpList the tools with /mcp, then ask "Ternary flagged ask-accounts-prod. What changed in the data that agent reads, and who else reads it?"
One alert, L0 to L4. The ladder is set per domain.
- •L0 manual. Someone reads the Ternary case, Slack and git logs, and guesses which change caused the spike.
- •L1 observe. Data Workers checks the domain's marts, reports model changes with their readers, and logs what each action would have needed.
- •L2 propose. It drafts the data-side fix and the rebuild; the owner approves before anything runs.
- •L3 act reversibly. For proven classes, such as a rebuild after an approved alias change, it queues the step, re-checks and records.
- •L4 autonomous. For a scoped class in one domain, it runs the loop end to end and posts the receipt.
More on safety, approvals, who owns the agents, autonomy levels, where your data goes, integrations and Data Workers on Google Cloud. Siblings: CloudZero, Vantage, IBM Cloudability, dbt, Prefect and Metabase.
What changes for your team
Ternary's own FinOps persona says finance ignores engineering-owned reports. With Data Workers next to the ledger, a cost case reaches finance with its data cause attached, and these jobs run on autopilot at the level you set.
- •Cloud spend. Snowflake credits per dbt model and each Data Workers action's model cost sit on the receipt linked from the case.
- •Incidents. A cost spike with a data cause arrives traced, with its readers and owners named.
- •Data quality. Marts are checked for keys, nulls and row counts after each fix.
- •Audits. Each fix links the approver, diff and checks, so "who approved this?" has an answer at close.
- •Migrations. Each wave is planned with its checks; the owner signs off before it closes.
- •Access. Grants a fix needs are dry-run first and approved by a named owner.
FP&A gets a dated cause for every overrun it books. The FinOps lead guide and the CFO-facing ROI guide cover the people side.
Keep Ternary, or consolidate?
Keep Ternary if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Nothing here replaces Ternary's ledger, GL mapping or alerts. What teams consolidate is the glue around it: cases that sit open because nobody can say which change drove a cost, and month-end spreadsheets that rebuild the story. Building it yourself? Calling an MCP server is the easy part; lineage, checks, approvals and receipts are the work. See also FinOps for data platforms, MCP for cost optimization agents and the cost of multi-agent data teams.
The case for your CFO
The outcome: when Ternary shows a cost moving, you get the data cause, the people it affects and a reviewed fix the same day, so the ledger stays explainable at close.
The risk story is plain. Data Workers changes nothing in Ternary and never writes to the GL. It drafts each data-side fix for its owner, and rebuilds are queued through your orchestrator after a named person approves. Unanswered requests expire and escalate, never auto-grant. No agent can promote its own work. An org-wide stop halts all autonomous dispatch. The agents run in your infrastructure with your credentials and your own model key; your data stays in your systems, and the hosted Conductor sees workflow metadata only. Zero migration.
Why now: AI spend is one of the fastest-moving lines on the technology ledger, and more of it comes from agents that query your warehouse on their own. When the data under them changes, the cost moves first and wrong answers follow. The first win is one domain, read-only, with its readers recorded. Data Workers' own model spend can show up in Ternary like any other key, because you pay your model provider directly with no markup; the model cost guide and the flat-fee explainer cover the detail.
The sentence to repeat upstairs: "Ternary tells us where every technology dollar went; Data Workers tells us what changed in the data to make it move, and fixes it with an approver and a receipt."
Getting started
Start with a pilot. Pick the domain where a cost surprise hurts most, connect Data Workers read-only to BigQuery or Snowflake, the dbt project and your orchestrator, record every reader of the key models, including in-house agents, and let it check those marts as the next Ternary alerts come in 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 connect to Ternary? Over its MCP server or API today. Your assistant can use Ternary's MCP server side by side with Data Workers' servers in one session; Data Workers' agents work from what Data Workers reads natively.
Does Data Workers detect cost anomalies? That is Ternary's job. Data Workers takes the alert's question to the data: what changed in the models, runs and tables behind that cost, and who signs off on the fix.
Does Data Workers write to our GL or ERP? No. The ledger and its ERP mapping stay with finance. Receipts give FinOps and FP&A the cause, approver and date of each data fix to attach to a case.
Will Data Workers' own model spend show up in Ternary? Yes, wherever Ternary already reads your model provider: Data Workers runs on your own key. Each Data Workers action's model cost is also written on its receipt, and a session scan budget stops an agent issuing more queries once it is spent. The spend of your other agents is Ternary's to see; Data Workers does not read it.
How does Data Workers check a fix worked? After the approved rebuild, run_quality_check checks nulls, key uniqueness and a minimum row count on the mart in Snowflake, or in BigQuery with a service-account key. Your dbt tests keep running as before.
Sources
- •Ternary home page (Finance positioning, ledger mapped to GL and ERP, MCP banner, ingestion, buyer personas), https://ternary.app/ (checked Oct 3, 2026)
- •Ternary Cloud FinOps page (multi-cloud normalization, anomaly detection incl. prepaid credit burn rate, commitment optimization), https://ternary.app/ternary-cloud-finops/ (checked Oct 3, 2026)
- •Ternary docs, Model Context Protocol overview (tools, OAuth, read-only except saving reports), https://docs.ternary.app/docs/model-context-protocol (updated Sep 24, 2026; checked Oct 3, 2026)
- •Ternary docs, Ternary MCP for Claude (Claude Code setup), https://docs.ternary.app/docs/ternary-mcp-for-claude (checked Oct 3, 2026)
- •Ternary docs, Alerts & Anomaly Detection, https://docs.ternary.app/docs/anomaly-detection (updated Jul 31, 2026; checked Oct 3, 2026)
- •Ternary docs, Case Management, https://docs.ternary.app/docs/case-management and Jira integration, https://docs.ternary.app/docs/jira (checked Oct 3, 2026)
- •Ternary docs, AI Observatory, https://docs.ternary.app/docs/ai-observatory (updated Sep 3, 2026; checked Oct 3, 2026)
- •Ternary docs, Snowflake, Databricks, Data Warehouse Insights and Google Cloud integrations, https://docs.ternary.app/docs/snowflake , https://docs.ternary.app/docs/databricks , https://docs.ternary.app/docs/data-warehouse-insights , https://docs.ternary.app/docs/google-cloud-platform (checked Oct 3, 2026)
- •Ternary release notes: report-linked alerts (Jul 20, 2026), alerts on any measure incl. AI token consumption (Aug 3, 2026), AI Observatory (Aug 14, 2026), MCP server (Sep 3, 2026), MCP saves reports and lists recommendations (Sep 22, 2026), Google Sheets add-on (Sep 23, 2026), https://announcekit.co/ternary/ternary-release-notes (checked Oct 3, 2026)
- •Data Workers agent swarm and public repositories (origin/main): dbt manifest lineage,
blast_radius_analysis,trace_cross_platform_lineage,run_quality_check, Prefect flow trigger, Snowflake metering and query-tag attribution, BigQuery job total, per-action model cost, session scan budget, approvals (checked Oct 3, 2026) - •Data Workers client setup docs, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)