Your warehouse is only as good as the semantic model behind it. Who is writing yours?
A warehouse answers against a semantic model that somebody authors by hand. That model carries the calculation. It rarely carries the exceptions around it, the policy that decided it, or the name of the person accountable when two teams report the same number differently.
This page sets out what Snowflake is built for, what a hand-authored model does not hold, how a governed context layer compares, and when you do not need one.
Key takeaways
- Snowflake runs the warehouse and answers fast against a semantic model. Nothing on this page proposes replacing either.
- That model is authored by hand, and it holds calculations rather than the rules and exceptions around them.
- Most of what governs a metric was never in the warehouse. It is in a policy document, a finance manual, a slide made for an audit.
- A governed context layer holds the definitions, exceptions and owners with their provenance, and leaves the query execution where it already is.
What Snowflake is built for
Snowflake is a warehouse: storage and elastic compute, separated so you can scale one without the other, with governance, sharing and lineage over what sits inside. It is a very good product at what it does, it is usually the least controversial part of an estate, and the reason people put their data there is that it works.
Its AI features answer questions in natural language, and they answer them well when the underlying semantic model has been authored properly: metrics defined, dimensions declared, joins specified, ambiguity resolved in advance by a human who thought about it. That model is the thing that makes the answers good. Without it, natural language over a warehouse is guesswork with a nice interface.
Which puts the interesting question one level down. The quality of the answers depends on the quality of the model, and the model is a hand-written artefact maintained by a small number of busy people. That is where this comparison lives.
The gap it leaves
Take days sales outstanding.
The model defines it, correctly, as receivables over revenue times days in period. Anyone asking gets a number, and the number is consistent across every dashboard, which is exactly what a semantic model is for.
What the model does not say is that treasury excludes disputed invoices from the numerator, that the exclusion was agreed in a working-capital policy three years ago, that it applies to two entities and not the third, and that the person who can settle a question about it sits in treasury rather than in analytics. So the number is consistent and it is not the number treasury reports, and each side has a definition it can defend.
The general form of this is worth stating plainly. A semantic model holds the calculation. The governing rule lives in prose, somewhere the warehouse has never looked. That is not a defect in the model. A model file is simply not a place where a policy, its exceptions, its effective date and its owner can be recorded, and nobody designed it to be.
- A semantic model encodes a calculation. It rarely encodes the exception, and almost never encodes why the exception exists.
- It records what the modeller believed on the day. With no link to the document that decided it and no owner to ask when it is questioned.
- Changes arrive as a pull request. Which is a good record of what changed in the model, and no record at all of what changed in the business.
- The warehouse cannot see the source of the rule. The policy that constrains the metric was written in prose and stored somewhere else entirely.
Side by side
| Snowflake | Metagem | |
|---|---|---|
| What it holds | Tables, views, a semantic model, governance over the warehouse | Terms, rules, processes, roles and the fields that carry them |
| Source coverage | What has been loaded into the warehouse | Structured and unstructured sources across the estate |
| Who authors the semantic model | Analytics engineers, by hand | Extracted from sources, then approved by domain owners |
| Rules and exceptions | Where someone modelled them | First-class objects, with the fields they govern |
| Provenance | The model file and its version history | Each concept linked to its source document or field, and its approver |
| When the business changes | Someone updates the model | Re-extraction proposes the change for review |
| Executes queries | Yes | No |
| Stores your data | Yes | No |
| Serves rows to a dashboard | Yes | No |
The row that decides whether these compete is the last but one. Snowflake executes and Metagem does not. Everything above it describes a division of labour rather than a contest: one system is responsible for returning the right rows quickly, the other for knowing which rows the question actually meant.
When you do not need this
If one team owns the model, the metrics are settled, the exceptions are few enough to hold in your head, and the rules behind them are already encoded rather than sitting in documents, the warehouse and a well-maintained semantic model are proportionate and cheaper. The layer earns its place when the definitions are contested between functions, when the exceptions outnumber the rules, or when something automated has to resolve a definition and there is nobody to ask.
How the two fit together
What Metagem supplies
Definitions with owners, the rules and exceptions around them, the processes that produce them, and the mapping down to the fields that carry them. All of it with provenance.
What Metagem does not do
No query execution, no text-to-SQL, no federation, no virtualisation, no storage. It does not serve rows and it is not a metrics store competing for that job.
What you keep
The warehouse, the semantic model, the BI tools above it and the analytics engineering practice around all three.
The definitions come from structured and unstructured sources across the estate, not from a modelling session inside one platform, which is what lets a policy written in prose end up attached to the field it governs. And because the meaning is not warehouse-resident, the same governed definitions serve Snowflake, your BI tools and your agents alike, in open formats that stay yours if the stack underneath ever changes.
Being the authority on meaning is a different discipline from being fast at returning rows. Snowflake is excellent at the second. Metagem holds the rules, exceptions and ownership the first one needs.
What's different hereThe category-level version of this argument, without the vendor, is on semantic layer vs context layer.
Frequently asked questions
Start with a number two teams report differently.
We will show you what sits behind each version: the definition, the exceptions, the policy they came from, and who is accountable for settling it.
Talk to our team