Ask four systems at your company what your Active ARR is and you will get four answers. The board deck says €2.38M, because someone ran a SUMIF on last month's export. Power BI says €2.41M, because the DAX measure excludes resellers. The CRM report says €2.52M, because it counts open and closed-won together and never splits currencies. And the AI assistant you connected last quarter says "about €2.6M", because it guessed from raw tables.
None of those four numbers has an owner. None of them has a history. Every one of them is slightly different, and the meeting where someone notices turns into an argument about whose spreadsheet is right.
Today we are shipping the RevOS Metric Store, which exists to end that argument. It gives every metric one definition of record, and gives that definition what a number needs before an organisation can govern it: an owner, a status, a version history, lineage, and a composition anyone can read.
## Metrics as first-class entities[#](#metrics-as-first-class-entities)
For most companies, a metric is not an object. It is a cell in a report, a measure in a BI tool, a line in a prompt, or a formula in someone's head. Each copy was reasonable when it was created. Over a few years the copies drift apart, the people who wrote them move on, and nobody can say what "churn" meant in the quarter you are comparing against.
We built the Semantic Model to fix the definition problem: entities, joins, and metrics written once as code and shared by every consumer. That turned out to be necessary but not sufficient. A definition with no owner is a number nobody will defend. A definition with no history is a number you cannot compare over time. A definition with no record of who depends on it is a number you cannot safely retire.
So the Metric Store treats each metric as an entity with its own URL and its own record:
- Definition. The aggregation, the expression, every filter in plain language, and the model's own description with its caveats. Written once in your cube file, reviewed in a pull request, applied through the CLI, and shown read-only in the store. There is no second editor for a metric to drift from.
- Owner. The team accountable for the metric, and who reviewed it.
- Status. Draft, certified, or deprecated with a pointer to its replacement. A person certifies a metric. When you deprecate one, it stays visible, because old reports keep citing it.
- Version history. Every change with its date, author, and diff. You can state what a metric meant in any past period.
- Lineage. The integration, the BigQuery table, and the cube upstream. The tables, scores, segments, and agents that depend on it downstream.
- Freshness. When the cube cache last refreshed and when each connection last synced, including the failed ones.
One catalog. Every metric your 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. Hiding them is how they stay undocumented.
Reused by people and by agents# #
The reason we care so much about one definition is that the number of consumers keeps growing. A metric used to be read by a dashboard and a spreadsheet. Now it is also read by customer tables, health scores, segments, automations, and AI agents.
In RevOS, all of those read the Metric Store rather than carrying a copy. A board shows the numbers your team watches under one shared date range, segment, and filter set. Customer tables and scores pull certified metrics as columns and inputs. BI tools read the same definitions through the semantic model. And agents in Claude, ChatGPT, Copilot, or your own stack query the same metrics over the RevOS MCP server, with the same descriptions and caveats a person sees.
This matters most for the agents. We have written before about why an AI agent working from raw tables produces confident, wrong numbers: it is not inventing data, it is inventing definitions, as SQL it wrote against tables it does not understand. Grounding the agent in governed definitions is the fix, and the effect is large. 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.
The Metric Store makes that grounding available to every agent, not only ours. Any MCP client can list the catalog, read a metric's definition, owner, status, and caveats, and query its value. And it adds the part the agent could not get from a definition alone: whether the metric is certified or still a draft, and what it was called before it was deprecated. An agent that can read status is an agent that can say "this metric was replaced in July, here is the new one" instead of quoting the old number.
The foundation for "why did this number change?"# #
The question we hear most from revenue operations leads is not "what is the number" but "why did it move". A metric changes for a short list of 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.
Most tools can only help with the last one, by breaking the number down by segment. The others need something the tools do not have: the metric's composition and its lineage across every layer and stack.
The Metric Store has both. For Active ARR it shows the Exact Online integration, the BigQuery table it lands in, the cube that defines it, and the table, score, and segment that read it, on one graph. Underneath, it lists what changed in the period you are looking at: a filter added in version 3.1 on the 12th, a source table rebuilt on the 4th, a connection that has been failing for eleven days. 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.
That does not answer the question for you. It gives you facts to check one by one instead of hypotheses to argue about, and in our experience that is the difference between a five-minute answer and a two-day investigation.
What it looks like# #
Three surfaces, all reading the same definitions.
- The Catalog. Every metric in the semantic model, searchable, with kind, cube, owner, status, where it is used, and freshness. Rows with no description are flagged as an invitation to fix them.
- The metric page. One number with its own URL: the value against the previous period, the conditions applied, what it can be broken down by, how it is calculated, its lineage, and its freshness.
- The Board. The numbers your team watches, as tiles under one shared set of conditions, with a sparkline and a delta that is only coloured when the direction is known.
The [product page](https://www.revos.ai/product/metric-store) walks through all three.
## Getting started[#](#getting-started)
If you are already on RevOS, the Metric Store reads the metrics your semantic model defines today. Open the Catalog, find the one your team argues about most, give it an owner, and certify it. That single step tends to end a surprising number of recurring meetings.
If you are not on RevOS yet, bring that same metric to a demo. In thirty minutes we will put it in the catalog on your own data, with an owner, a history, and its lineage, and you can decide whether the number holds up. [Book a demo](https://try.revos.ai/meetings/renat/revos-demo?utm_source=blog&utm_medium=website&utm_campaign=metric-store).
The agent era raises the price of a vague metric. Give every metric one definition, and both your people and your agents will stop guessing.
Frequently asked questions #
- What is the RevOS Metric Store?
- The Metric Store is the catalog and definition of record for the metrics in your RevOS Semantic Model. Each metric has an owner, a status, a version history, a readable composition, lineage, and a list of dependents. People watch metrics on a board and on a page per metric. Dashboards, tables, scores, segments, and AI agents reuse the same definitions.
- How is the Metric Store different from the Semantic Model?
- 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, ownership, status, version history, lineage, and dependents. It shows the definition read-only.
- What is the lifecycle of a metric in RevOS?
- A metric starts as a draft, is certified when its owner and reviewers stand behind 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. Each definition change creates a new version and the earlier versions stay readable.
- How does the Metric Store help explain why a metric changed?
- Because it knows a metric's composition and lineage, it separates the usual causes: 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 one segment drove the change. You still do the thinking, but you start from facts.
- Can AI agents use the Metric Store?
- Yes. Agents query metrics through the RevOS MCP server and read the same certified definitions, descriptions, and caveats a person sees, including whether a metric is deprecated or still a draft.
Read more about revenue operations, growth strategies, and metrics in our blog and follow us on LinkedIn and Youtube.