Metric Store
One definition of every metric, for people and agents.
The Metric Store is the catalog and definition of record for your metrics. Each metric has an owner, a status, a version history, lineage, and a composition you can read. Boards, tables, scores, BI tools, and any AI agent over MCP all read that one definition, so nobody has to rebuild it in another spreadsheet.
30 minutes on your own metrics, from the definition to the board.
Why a metric store
Four answers to one question
Organisations collect metrics faster than they document them. The same number gets recomputed in a spreadsheet, a BI measure, a CRM report, and lately an AI assistant working from raw tables. Nobody owns any of the copies, nothing records how they changed, and each one is slightly different.
Before
Definitions live in formulas, DAX, report filters, and people's heads. Changing one breaks a quarterly report somewhere, and nobody can say what the number meant last year.
With the Metric Store
Every metric has one definition, an owner, a status, a version history, and a record of what depends on it. Every consumer reads it and none of them keeps a copy.
What changes
Arguments about a number end at its page. New dashboards, tables, and agents connect in minutes. When you retire a metric, you can see what depends on it before you do.
How it works
Metrics as first-class entities
A metric here is an object with a definition, an owner, a status, a history, and a list of dependents, rather than a cell in a report or a line in a prompt.
Define it once, as code.
You write a metric in your Semantic Model as a cube file: the aggregation, the expression, the filters, and a description that includes the caveats. The change goes through a pull request and the CLI applies it, so someone reviewed it and the diff is on record.
Govern it like an entity.
The Metric Store attaches an owner, a status, a version history, and a list of dependents to each definition. When you deprecate a metric it stays visible and points to its replacement, because old reports keep citing it.
Reuse it everywhere.
Boards, tables, scores, segments, and BI tools read the definition rather than keeping a copy of it. AI agents query the same metric over MCP, so the answer in a chat is the number in the board deck.
What you get
Metric governance, built in
The parts of a single source of truth that a warehouse on its own does not give you.
A central catalog
Every metric the semantic model defines, in one searchable index with its kind, cube, owner, status, where it is used, and how fresh it is. Undocumented metrics are listed as well, with a note asking for a description, because hiding them is how they stay undocumented.
Definitions with a history
Each metric is versioned. You can read what the definition was in any past period, who changed it, and why. When two reports disagree, you check the version instead of the spreadsheet.
Ownership and lifecycle
A metric has an owner and a status: draft, certified, or deprecated with a replacement. A person certifies it, so people and agents can tell a number the organisation stands behind from one that is still a proposal.
Composition you can read
The aggregation, every column it touches, and every filter, written in plain language and read-only. A composite metric shows its operands as metrics in their own right, so you can read a ratio through the two numbers that make it.
Lineage end to end
Integration, BigQuery table, cube, metric, and the tables, scores, segments, and agents that depend on it, in one graph with the last sync of every connection. The graph only shows what the data knows. If a source is not recorded, it says so.
Reused by people and agents
The same definition serves the board, BI dashboards, customer tables, health scores, and segments, and is exposed to any MCP client through the RevOS MCP server. Change it once and all of them pick it up, since none of them keep a copy.
For agents
Every metric, available to every agent over MCP
RevOS ships an MCP server, so any MCP client can use the Metric Store: Claude, ChatGPT, Copilot, or an agent you build yourself. The agent lists the catalog, reads a metric's definition, owner, status, and caveats, and queries its value under the same conditions a person would set on the board.
That is what makes agents hallucinate less. Most wrong numbers from an AI assistant are not invented data; they are invented definitions, written as SQL against raw tables. An agent that reads a certified definition does not have to guess what “active” or “ARR” means. In Snowflake's published text-to-SQL evaluation, a general-purpose model scored 51% on raw schemas and over 90% once grounded in a governed semantic model.
Status travels with the metric. An agent that can see a metric is deprecated will point you to its replacement instead of quoting the old number.
Lineage and composition
The foundation for “why did this number change?”
A metric moves for one of a few reasons: its definition changed, something upstream changed or failed to sync, one of the metrics it is built from moved, or one segment drove it. Because the store knows the composition and the lineage across every layer and stack, you can check those reasons one by one instead of guessing.
Definition changed
The version history shows what changed, when, and who changed it. A filter added on the 12th explains a step on the 12th.
Upstream changed
A rebuilt table or a connection that failed eleven days ago shows up on the same graph as the metric, next to the last sync of every source.
Composition moved
For a composite metric, each operand is a metric with its own page, so you can read a ratio through the two numbers that make it. A breakdown then shows which segment moved.
RevOS hasn't just met our expectations; it has exceeded them, becoming an essential part of our daily operations. I'm truly excited about our future capabilities with this incredible tool.
Bring the metric your team argues about most.
In 30 minutes we put it in the catalog with an owner, a history, and its lineage, on your own data.
Built on the RevOS platform
The Metric Store governs what the rest of the platform defines, computes, and consumes.
Semantic Model
Where every metric in the store is defined as code, reviewed, and applied through the CLI.
AI Agents
Agents that answer from certified metric definitions over MCP, not from raw tables.
Predictive Scoring
Scores built from governed metrics, listed as dependents on the metric page.
Segments
Segments defined on the same metrics, so a filter means the same thing everywhere.
FAQ
Questions about the Metric Store
The Metric Store is the central catalog and definition of record for the metrics in your RevOS Semantic Model. Each metric is treated as a first-class entity with an owner, a status, a version history, a readable composition, lineage, and a list of everything that depends on it. People watch metrics on a board and on a page per metric; dashboards, tables, scores, segments, and AI agents reuse the same definitions.
Metric sprawl. In most organisations the same metric gets computed in several places: a spreadsheet, a BI measure, a CRM report, an AI assistant working from raw tables. The definitions drift, nobody owns them, and meetings turn into arguments about whose number is right. The Metric Store replaces the copies with one governed definition that every consumer reads.
The Semantic Model is where metrics are defined as code and applied through the CLI. The Metric Store is the governance and discovery layer on top: the catalog, the owner and status, the version history, the lineage, and the dependents. It shows the definition read-only, so there is no second place where a metric can be edited.
A metric starts as a draft, is certified once its owner and reviewers vouch for it, and is deprecated with a pointer to its replacement when it should no longer be used. Deprecated metrics stay visible because old reports keep citing them. A definition change creates a new version; the previous versions remain readable.
Because the store knows a metric's composition and its lineage, it can separate the usual suspects: the definition changed in a given version, an upstream source or table changed or failed to sync, one operand of a composite metric moved, or a particular segment drove the change. You still do the thinking, but you start from facts instead of a hunch.
Any MCP client, such as Claude, ChatGPT, Copilot, or an agent you build, connects to the RevOS MCP server and can list the catalog, read a metric's definition, status, owner, and caveats, and query its value. The agent answers from the certified definition instead of generating SQL against raw tables, which is where most wrong numbers come from. In Snowflake's published text-to-SQL evaluation, a general-purpose model scored 51% on raw schemas and over 90% when grounded in a governed semantic model. Status travels with the metric, so an agent can also tell you when a metric is deprecated or still a draft.
Measure is a pre-declared aggregation in the model, such as Active ARR as a SUM. Field is a per-row number where you choose the aggregation. Column is a table column flagged as a measure. Score is the points output of a scoring rule, and the only kind with a declared direction and thresholds.
No. Your BI tools keep their dashboards and read the governed definitions through the Semantic Model, so the number in Power BI and the number on the RevOS board agree. The Metric Store adds what BI tools lack: one catalog, ownership, lifecycle, version history, and lineage for every metric.
Ready to give every metric one definition?
See the Metric Store on your own semantic model, from the catalog to the lineage graph.