Semantic Layer vs Model Layer: What a Number Means vs What It Will Become
There is a sentence going around finance software right now, and it is close enough to true that it is worth taking apart carefully.
The sentence is: whoever governs the context governs the stack. Models will change, interfaces will change, agents will change, but if you own the layer that defines what revenue means, what an entity is, and which numbers roll into which, you are the control point and everything above you is replaceable.
That is right. It is also incomplete in a way that matters enormously if you are trying to plan anything.
What a Semantic Layer Actually Holds
The category has converged on a fairly consistent definition. A semantic layer is an executable contract between your physical records and your business measures. It persists roughly six things:
- Metric definitions, with the formula that computes each one
- Grain and joins — the level at which a number is true, and how tables connect
- Accounting period rules — what falls in which month, and when a period closes
- Scope — which entities, which currencies, which exclusions
- Permissions — who can see which cut
- Lineage — source, calculation, result, traceable end to end
This is genuinely valuable, and it is genuinely hard. If you have ever watched three people bring three different revenue numbers to the same meeting because the GL, the billing system and the CRM each define a sale differently, you know exactly what problem this solves. A semantic layer ends that argument, permanently, and it is the right thing to build.
It is also, every single one of those six objects, a statement about the past.
The Test That Separates the Two
Here is the question that sorts a semantic layer from a model, and it takes about four seconds to ask:
What happens to cash in November if the second sales hire lands in March instead of January?
A semantic layer cannot answer this. Not because it is badly built, but because nothing in it is shaped like an answer to that question. There is no hire in it. There is no March. There is no alternative March. It holds definitions that let you compute a number correctly from records that exist, and a hire that has not happened yet leaves no records.
Ask it something retrospective and it is superb: what was gross margin by segment last quarter, computed the same way every time, with the lineage to prove it. Ask it something prospective and it has nothing to reach for.
The distinction is not pedantic, and it is not a gap that gets closed by adding fields. A semantic layer says what a number means. A model says what it will become. Those are two different objects with two different shapes.
What a Model Layer Holds That a Semantic Layer Does Not
Four things, and none of them fit inside a metric definition.
Time as a first-class dimension. Not "which period does this record belong to" but "what is the value of this variable in each of the next 36 months, and what drives it". A semantic layer buckets facts into periods. A model generates values for periods that have no facts yet.
Assumptions that are named and owned. Headcount plan, price increase, churn, collection delay. These are not derived from records. Someone decided them, and someone should be accountable for them. In a semantic layer, an assumption has nowhere to live: it is neither a source record nor a definition.
Scenarios that coexist. Base, downside, the version where the fundraise slips two quarters. Not three exports, three living structures over the same logic, comparable line by line. A semantic layer has exactly one truth by design, which is the entire point of it, and is precisely why it cannot hold three.
A dependency graph you can push a change through. Change the hiring date, and payroll, the payroll taxes, the cash conversion and the covenant headroom all move, in the right order, without anyone re-deriving the chain. This is the part people underestimate. It is not a spreadsheet with more rules; it is a directed graph with a topological order, and it is the difference between "change a number" and "change a structure".
Why This Is Suddenly Urgent
For most of the last decade the distinction was academic, because nothing could reach either layer automatically. You pulled a report, you opened the model, and you did the joining in your head.
Agents changed that, and they changed it asymmetrically. Over the last eighteen months, most of the finance stack has opened up: accounting platforms, spend tools, data warehouses and BI layers now expose themselves to an agent, often over MCP, usually in a few clicks. An agent can read your ledger, your billing, your semantic definitions, and reconcile all three.
Then it builds you a forecast, and puts it in a chat window.
That is the actual state of the art, and it is where the frustration comes from. The retrieval problem is solved to a standard nobody expected three years ago. The persistence problem is untouched. Watch how practitioners work around it and the shape is always the same: skills and prompt files that encode how to project, with the data pasted in fresh each month. The procedure persists beautifully. The projection does not survive the session.
You can run that way for a while. It costs discipline rather than money, right up until a source changes format, or two systems claim the same word, or you are doing it for a tenth client.
Both, In Order
None of this is an argument against semantic layers. It is an argument about sequence, and the sequence is not ambiguous.
You want the semantic layer first. A model built on numbers whose definition is contested is worse than no model, because it launders the disagreement into a projection and nobody can find it afterwards. Fix what revenue means before you forecast revenue.
But finishing there leaves you with a very well-governed rear-view mirror. The decisions that need a number attached to them are almost never about last quarter. They are about whether to make the hire, sign the three-year commitment, take the pricing risk. Those need a structure that projects, holds assumptions someone owns, and carries more than one future at a time.
The practical test for anything sold to you as a context layer, a control point, or an AI-native finance platform is the one from earlier. Ask what happens to cash in November if a hire moves from January to March. If the answer is a narrated paragraph rather than a recomputed structure you can inspect, you are looking at a semantic layer. Buy it for what it is, and do not expect it to plan.
The Takeaway
The category is right that context is the control point. It is half right about what context means.
Definitions, lineage and permissions are context about what already happened, and they are table stakes now. Assumptions, scenarios and a dependency graph are context about what might happen, and almost nothing in the stack holds them. An agent with access to the first and not the second will always be able to tell you, very precisely and with full lineage, exactly where you have already been.
Layerz is built for the second layer: a model as structure, separate from its data, that Claude can change through MCP without rebuilding it, and that exports to clean Excel whenever someone asks for a file. If your semantic layer is not sorted yet, sort that first. The order matters more than the vendor.