Anavsan terminology
The language of workload governance
These are the terms Anavsan uses when monitoring is not enough. Operating-model language (the loop, ownership, proof) applies to Snowflake and BigQuery. Snowflake mechanics (spillage, Native App, Cortex, warehouses) stay labeled as Snowflake. Snowflake Workload Governance remains a defined SEO term for the Snowflake flavor of the discipline.
Operating model
Category language. These terms name the discipline, not a dashboard tile.
Snowflake Workload Governance
Operating modelThe operating discipline that traces waste to a workload and owner, assigns the fix, enforces a decision, and proves closure from the data. Monitoring detects spend. Governance closes the loop.
Full explainer →Continuous Workload Governance
Operating modelGovernance that keeps running after the first optimization project. Workloads, schemas, and teams change; savings reverse unless ownership and proof stay in the operating rhythm.
Read in the explainer →Cost Accountability
Operating modelThe ability to name who owns a cost event, what should change, and whether the waste stopped. Visibility without an owner is reporting. Accountability is a closable work item.
Full explainer →Snowflake Cost Governance
Operating modelThe operating model for spend across teams and workloads: detect, assign, and close. It is not Query History, a resource monitor, or a monthly FinOps slide.
Related article →Governance Drift
Operating modelThe gap that opens when Snowflake workloads evolve faster than ownership, context, and policy. Optimizations that worked last quarter quietly stop working.
Related article →Workload Drift
Operating modelConsumption changing faster than the annual forecast because pipelines, BI refresh, Cortex usage, and warehouse settings move independently of the budget story.
Related article →The APEX loop
Product language for the closed cycle. Four stages, one outcome: a finding that closed because the waste stopped — not an open alert, and not a simulation treated as a win.
APEX
Operating modelAccountability and Performance Enforcement Engine. Builds a Private Knowledge Graph and runs Trace → Assign → Enforce → Prove on Snowflake and BigQuery metadata. On Snowflake, that includes 200+ signals.
Full explainer →Trace → Assign → Enforce → Prove
Operating modelThe closed accountability loop. Trace finds waste, not spend. Assign names a party or says needs owner. Enforce drives a decision through your review process. Prove closes the finding when the metric recovers.
Full explainer →Trace
Operating modelFind recurring, fixable waste — the gap versus an efficient configuration. Warehouse spend leaderboards are not Trace. A one-off spike is not Trace. A busy, efficient warehouse never earns a row.
In the loop explainer →Assign
Operating modelName a party from evidence. If ownership is not knowable, say needs owner. Guessing a person from ACCOUNTADMIN is not assignment. Confidence gates the channel, never the ranking.
In the loop explainer →Enforce
Operating modelDrive the item to a documented decision: applied, deferred with a reason, or dismissed. Alerts that sit in Slack are not enforcement. Your PR process is. Silent warehouse alters are not.
In the loop explainer →Prove
Operating modelThe finding resolves itself when the underlying metric returns to a normal band. Nobody self-reports a win. Simulation is change safety, not the Prove stage.
In the loop explainer →Enforcement Desk
Operating modelA ranked worklist of addressable waste. Each row has a mechanism, a dollar figure, an owner, an exact fix, and a status you can defend in review. It ranks waste, not spend, so efficient expensive warehouses stay off the list.
Full explainer →Ask APEX
Operating modelConversational layer over the same estate metadata and Desk findings. Answers show the SQL, assumptions, and as-of time. It is grounded on the finding in front of you, not a generic chatbot over a dashboard.
In the APEX explainer →Private Knowledge Graph
Operating modelAn environment-specific map of users, workloads, query patterns, ownership signals, and fix history. Generic models trained on industry averages cannot assign your issues. The PKG is why assignment is specific.
Full explainer →What it is not
Searchers often land on the wrong category. These contrasts keep Anavsan language from collapsing into monitoring, FinOps culture, or native Snowflake controls.
Monitoring vs governance
Monitoring tells you a warehouse is expensive. Governance names the workload, the owner, the decision, and whether the waste stopped. A better chart is still monitoring.
FinOps vs workload governance
FinOps is the cross-functional practice of managing cloud value. Workload governance is the loop that turns a waste event on Snowflake or BigQuery into owned, decided, and evidenced work. Snowflake Workload Governance is that discipline on credits, warehouses, and queries. FinOps needs the loop; it is not the loop.
Showback, chargeback, ownership
Showback reports consumption. Chargeback bills it. Ownership is who can change the workload. Allocation without an owner still leaves the expensive query unfixed.
Resource monitors vs enforcement
Resource monitors and budgets cap or notify. They do not name an owner, track a decision through your review process, or close a finding when the metric recovers. Caps without owners create surprise suspends, not cheaper runtimes.
Native anomaly detection vs APEX
Snowflake can flag a spike. APEX treats the spike as an input: who owns it, a decision through your review process, and whether the waste stopped. Detection is Trace. The stall is after.
Snowflake mechanics
These are Snowflake behaviors and Snowflake products, not the company line. Governance still has to trace, assign, enforce, and prove them. Featured: query spillage and Native App vs full platform.
Query spillage
Snowflake mechanicsWhen intermediate data no longer fits in warehouse memory, Snowflake writes to local disk or remote storage. Runtime grows. Credits follow runtime. Spillage is not a bill line item.
Full explainer →Native App vs full platform
Snowflake mechanicsThe Native App is in-account credit, warehouse, query, and storage monitoring on Snowflake. The full platform is APEX: Trace, Assign, Enforce, Prove. They are two products for two jobs. BigQuery has no Native App claim.
Full explainer →Credit waste vs spend
Snowflake mechanicsSpend is what you paid. Waste is the gap versus an efficient configuration for the same work. Ranking by spend keeps valuable warehouses on top forever. Ranking by waste keeps the list short.
Warehouse idle time
Snowflake mechanicsCredits accrue while a warehouse is running with no queries. Auto-suspend that is too slow, or a last spilling job that blocks suspend, turns idle minutes into a cost pattern.
Resume / suspend thrashing
Snowflake mechanicsWarehouses that bounce on and off around a poorly chosen auto-suspend window. Each resume has a cost; so does sitting idle. The cheaper window is measured in credits, not in a default of 60 seconds.
Full table scans
Snowflake mechanicsQueries that read far more micro-partitions than the question requires. Extra scan volume extends warehouse runtime. Filters, clustering, and column pruning cut the working set.
BI refresh storms
Snowflake mechanicsMany dashboards hitting the same warehouse at once. Queuing, concurrency, and delayed auto-suspend extend runtime for everyone on that cluster, not just the dashboard that started it.
Time Travel tax
Snowflake mechanicsStorage held by Time Travel and Fail-safe after drops, copies, and high churn. It does not appear as a compute spike. It compounds on the storage line until retention and unused objects are governed.
Cortex / AI credit spend
Snowflake mechanicsToken and function usage billed against the same credit pool as warehouses. Without workload-level visibility, AI spend hides inside the monthly bill until someone traces the function and owner. Cortex is Snowflake-only.