There is a line in Snowflake's recent post about its Decision Platform that I keep coming back to: CFOs don't need more AI. They need AI they can sign off on.
Most of the design decisions behind RevOS come from the same idea, so I want to lay them out properly. The short version is the title. We use probabilistic AI where it adds insight and deterministic computation where the number counts. The language model proposes the design and the logic. The database computes every figure. No number that reaches a report was ever arithmetic done by a model.
Two kinds of systems, two kinds of mistakes# #
A deterministic system gives the same output for the same input, every time. A SQL query over a fixed table is deterministic, and so is a spreadsheet formula. If the answer is wrong, the logic is wrong, and you can go and read the logic.
A probabilistic system samples from a distribution of likely outputs. A large language model is probabilistic. Ask it the same question twice and you can get two different answers, both of them fluent and confident. That is not a bug. It is what lets the model draft, explore and design. It is also why it should never be the thing that calculates net revenue retention.
Most of the trouble with AI on business data comes from putting the probabilistic system in the deterministic seat. A model asked for a metric does not calculate anything. It predicts what a plausible answer looks like. On a good day it writes a query, runs it and reports the output. On a bad day it guesses which table holds revenue, how downgrades should be treated and what "mid-market" means, and the number it hands back is quietly wrong. Frontier models fail this way too. What makes it dangerous is that the failure is silent, and silent is the worst kind of wrong for anyone who has to put their name under the figure.
Snowflake measured this. In its own text-to-SQL evaluation, a general-purpose model writing SQL from a raw schema scored about 51%. Grounding the same task in a governed semantic model pushed accuracy past 90%. The model did not get smarter between those two runs; the context around it changed. We have written about why in agentic data engineering and in how to structure data for AI agents.
So the question is which job to give the LLM, and which to keep away from it.
The division of labour at RevOS# #
One rule decides it: the model designs, the database computes.
| | The LLM owns (probabilistic) | The database owns (deterministic) |
|---|---|---|
| What it does | Proposes entities, relationships, metric definitions, playbook rules and the SQL that implements them | Runs that SQL over governed data and returns the number | | Input | Your intent in plain English, plus the current model and lineage as context | The committed, reviewed logic and the source records | | Output | A proposal, in the form of a diff you can read | A figure with lineage back to every source field | | When it is wrong | The diff gets rejected at review time | The logic is wrong, and the logic is readable | | Repeatable? | No, and it does not need to be | Yes, always |
The LLM proposes the logic#
Everything an agent does at RevOS that involves language or judgement runs on a language model. Through the RevOS CLI, an AI coding agent such as Claude Code or Cursor explores your warehouse, proposes how the business should be modelled, and writes the pieces: dbt models, the entities and metrics in the semantic layer, the rules a playbook follows, and the SQL behind all of it.
This is where a probabilistic system earns its keep. Designing a model is a search through options. Translating "trial accounts should not count as active customers" into the right change across three definitions is language work, and so is explaining why a score moved. A model is faster at this than a person starting from a blank file, and quite often better.
What it produces is always a proposal. The agent does not run its idea against production and report the result as fact. It opens a change and waits.
The database computes every number#
Once logic is reviewed and merged it stops being a proposal and becomes part of the RevOS Semantic Model: one governed definition of each entity and metric, used by every person, workflow and agent. From that point on, every figure is the output of deterministic SQL running in your BigQuery warehouse.
That covers a lot more than headline metrics. Segment membership, the inputs that feed a health score, the list of accounts a renewal playbook will act on, the number an agent quotes in a Slack thread: all of it is computed in the warehouse from the same definitions, and all of it carries lineage, meaning you can see which source fields, through which transformations, produced the value. Ask the same question tomorrow and you get the same answer unless the underlying records changed.
This is why we call the semantic layer the numbers half of a company brain. The knowledge half (documents, decisions, call notes) is well served by retrieval and summarisation, which are probabilistic by nature and perfectly fine for that job. The numbers half has to be exact.
Proof travels with the logic#
A proposal is only safe if somebody checks it before it counts. At RevOS the check is the one your engineers already trust: a pull request.
Every change the agent proposes lands as a diff in your own Git repository. Before it can merge it runs through your CI/CD pipeline, where automatic validation catches the usual ways data logic goes wrong. dbt tests, primary-key and uniqueness checks, and data contracts that fail the build if a model breaks the shape its consumers depend on. Then a person reads the diff and approves it. Production mutations such as schema changes and deletions keep a human in the loop however routine they look, and every action the agent takes is written to an immutable audit log.
The effect is that the agent fails at review time rather than in production. A wrong idea shows up as a red check and a readable diff, instead of a wrong number in a board deck three weeks later.
Probability where it adds insight#
None of this means we avoid machine learning. Some questions are estimates by nature. Which accounts are likely to churn next quarter? What will pipeline look like in March? A predictive score is probabilistic because the future is, and I would be more worried about a vendor who claimed otherwise.
The rule still holds underneath. The features a churn model learns from are computed deterministically from governed definitions. The score is stored against the account it describes, together with the inputs that drove it, so a person can see why an account moved from green to amber. The forecast is a probability; the data it rests on and the record of how it was produced are exact.
That is the same shape Snowflake describes, with machine learning forecasting the drivers and deterministic SQL calculating every number that rolls into the P&L. The ML adds the insight. The SQL is what you sign.
What this looks like day to day# #
Take one change and follow it through the loop.
- You describe the change in plain English: "Exclude trial accounts from active customers, and recompute NRR without them." You do not write a formula or any SQL.
- The agent proposes the logic. It finds the three definitions that depend on "active customer," edits them, updates the SQL and opens a pull request with a plain explanation of what changed. This step is probabilistic, and it is only a proposal.
- The checks run. Tests, uniqueness checks and data contracts execute in CI. If the change breaks a downstream model, the build goes red before anyone sees a number. Deterministic.
- A person approves. The diff is readable, so the review takes minutes rather than a meeting.
- The warehouse recomputes. Every metric that depends on the definition is rebuilt from source, with lineage, and every agent and dashboard reads the new figure. Deterministic again.
- Agents act on the result. A renewal agent picks up the accounts that now qualify, drafts its outreach for a person to approve, and logs what it did. The draft is probabilistic. The list it worked from is not.
The person in that loop changed business logic without writing a line of SQL and still ended up with a number they can defend, because the number is the output of a query they can read.
Why the AI has to live in the data foundation# #
One more design choice makes the split work: the AI operates inside the data platform, not on a copy of it.
If the model works from an export, a cached extract or a vector index of your tables, two things go wrong. The context is stale by the time it is used, and the model has no way to run the deterministic half at all, so it can only predict what the answer might be. At RevOS the agent sits on the same governed warehouse the SQL runs in. It sees the current model, the current lineage and the current permissions when it proposes a change, and the database that computes the number is the same one the agent reasoned about. That is also what makes the result safe to expose through MCP: whichever AI agent your team uses, Claude, Cursor or a custom workflow, asks the semantic layer and gets the computed figure with its lineage, rather than a model's recollection of it.
Where that leaves you# #
The model proposes the design and the logic, because that is search and language work and it is good at it. The database computes every number, because a number someone signs off on has to be exact and repeatable, with a trail back to the source. Proof travels with every change through tests, review and the audit log, so the model's mistakes show up as rejected diffs rather than wrong figures.
That is how you get to AI a CFO can sign off on. It is not less AI. It is the same AI, kept out of the seat where it does harm.
Frequently asked questions #
- What is the difference between probabilistic and deterministic AI?
- A deterministic system gives the same output for the same input every time, like a SQL query over a fixed table. A probabilistic system samples from a distribution, so the same input can produce different outputs. Large language models are probabilistic. That makes them good at generating options, drafts and designs, and unreliable for calculations that have to be exactly right and repeatable.
- Why should an LLM not calculate business metrics directly?
- Because a language model does not calculate, it predicts plausible text. Ask it for last quarter's net revenue retention and it will produce a confident number that may or may not match the data, and may differ on the next run. A metric that finance or a board will sign off on needs to be computed by a system that is exact and repeatable, with a trail back to the source records. That is what a database query over governed data gives you.
- What does RevOS let the LLM do?
- The design work. The agent proposes entities and relationships for the semantic model, writes metric definitions and the SQL behind them, drafts playbook logic, and translates a plain-English change request into a concrete diff. It also explains results and summarises context for a person. It never computes a number that ends up in a report.
- What does the database do in RevOS?
- All the computation. Every metric, every score input, every segment membership and every figure that reaches a person or an agent is the output of deterministic SQL running in your data warehouse (BigQuery). The same inputs always give the same output, and every output carries lineage back to the source fields it was built from.
- How does RevOS check the logic the AI proposes?
- Proposed logic lands as a pull request in your own Git repository. Before it can merge it has to pass automated validation: dbt tests, primary-key and uniqueness checks, and data contracts, run through your normal CI/CD. A person reviews and approves the change. Production mutations such as schema changes and deletions keep a human in the loop, and every action is written to an immutable audit log.
- Does this mean RevOS avoids machine learning?
- No. Predictive scores such as churn risk and forecasts are probabilistic by nature, and that is where probability adds insight rather than risk. RevOS keeps the inputs to those models deterministic and governed, stores every score against the record it describes, and shows which inputs drove it. The estimate is probabilistic. The data it rests on is not.
- Can I change business logic without writing SQL?
- Yes. You describe the change in plain English, for example that trial accounts should no longer count as active customers. The agent turns that into a change to the semantic model and the SQL behind it, and opens a reviewable pull request. You read the diff, the tests run, and once it merges every metric that depends on that definition is recomputed from the same source of truth.
- Is this the same approach Snowflake describes for its Decision Platform?
- It is the same principle. Snowflake describes machine learning forecasting the drivers while deterministic SQL calculates every number that rolls into the P&L, with AI proposing logic that the platform then proves. RevOS applies the same division of labour to the revenue data of B2B SaaS companies, with BigQuery as the warehouse, a governed semantic layer as the shared definition of the business, and MCP as the way any AI agent reads the result.
Read more about revenue operations, growth strategies, and metrics in our blog and follow us on LinkedIn and Youtube.