Explain a number after you shipped
Attribute warehouse or capacity spend to the models and jobs that caused it
- When the bill jumped sharply and nobody can name which model caused it.
- When warehouse credits or capacity units are billed at the workspace level with no model-level breakdown.
Join query history or capacity metrics to the dbt manifest and orchestration runs to attribute spend to the models and jobs that caused it, with the top movers against the prior period. Covers the attribution itself, not any decision to reduce or re-architect the spend.
Sample This Recipe has not been materialized in the Cookbook repository yet. Its trigger, description, prompt, agent guidance and acceptance conditions, and the explanation below, are prototype drafts. Its name, job, area and readiness come from the reconciled Cookbook seed snapshot. Readiness is a separate question from this one: it says whether the capability exists, not whether the writing has been reviewed.
Review planned Recipe
At least one capability or object type this Recipe needs is not supported yet.
Read the VibeData Recipe `cost-attribution-by-model-job` at https://getvibedata.ai/cookbook/cost-attribution-by-model-job At least one capability or object type this Recipe needs is not supported yet. Treat it as a reference, not as work to execute.
Recipe id cost-attribution-by-model-job · Not yet materialized in the Cookbook repository, so the pointer addresses this page.
Verified by
What has to be observably true before this Recipe is finished.
- attributed spend plus unattributed spend equals the total bill for the period
- each top mover is traced to a named model or job with an owner
- the same period recomputed a second time produces the same attribution
- a model with no attributable runs is not silently omitted from the total
Recipe promptThe task specification the agent reads. Reference only — it is not what you copy.
Deliver: Attribute warehouse or capacity spend to the models and jobs that caused it. Join query history or capacity metrics to the dbt manifest and orchestration runs to attribute spend to the models and jobs that caused it, with the top movers against the prior period. Covers the attribution itself, not any decision to reduce or re-architect the spend. Execute inside the current Intent. Its Domain, repository, platform, environment and attached sources are the context for this work — read them rather than asking for them. The work is done when: - attributed spend plus unattributed spend equals the total bill for the period - each top mover is traced to a named model or job with an owner - the same period recomputed a second time produces the same attribution - a model with no attributable runs is not silently omitted from the total Report the evidence for each condition above with the result. A condition you cannot meet is something to say, not something to work around.
Agent guidanceHow the agent approaches the work, and what it will not do.
Separate what moved from what only looks different before reaching for a cause. Hold the window and the baseline fixed, line the difference up against what changed inside that window, and answer with a number, a cause and a date.
Composes
- permission and billing reads
- dbt in the project
Asks first
Semantic decisions the Intent cannot supply. Never context Studio already holds.
- which Fabric target this work lands on, when the Domain carries both a Lakehouse and a Warehouse
- the window, and the baseline the answer is measured against
Guardrails
- Build in an isolated copy. Production is read, never written.
- At least one capability this Recipe needs is not supported yet. Say so and stop rather than substituting a different approach.
What you need
- Microsoft Fabric Lakehouse, Microsoft Fabric Warehouse, MotherDuck, or DuckDB.
- Read access to the billing or permission surface the work reads from.
- dbt in the project, or the intent to add it.
- Needs query history or capacity metrics retained for the period.
How it goes
- State the question the way it was asked of you, including the number in it.
- Agree the window, and the baseline the answer is measured against.
- Let it separate what actually moved from what only looks different.
- Line the difference up against what changed inside that window.
- Write the answer down as a number, a cause and a date.
What you end up with
The deliverable, in your own repository, as governance and cost work a reviewer who knows the project reads as native to it. Alongside it, the evidence for every one of the acceptance conditions above — which is the part that is still there in three weeks when somebody asks.