A semantic layer is a written model of what a business's data means. It records which metrics exist, how each is calculated, which tables and joins it uses, and what every term refers to. AI needs one because without it a model guesses those meanings from column names, and a guessed meaning produces a number that looks right. A 2026 benchmark by dbt Labs, which sells a semantic layer, concludes that the main change is in how AI fails. Plausible wrong answers become errors, and questions outside the model cannot be asked until someone models them.
What the usual answer says
The explainers that rank for this question describe a translator. An August 2026 MIT Sloan article reports research by Barbara Wixom and colleagues at MIT's Center for Information Systems Research. It defines a semantic layer as "a system of technologies and techniques that creates and maintains a consistent, unified representation of data from different sources". It warns that without one, AI "can produce answers that are technically plausible but also incomplete, misleading, or wrong".
The same research found that "In a 2024 survey of 349 executives, just 21% rated their organizations' data curation practices as somewhat or very well developed". Those organisations "were more than three times as likely to report that they were effective at implementing data and AI initiatives that generated value". The article does not say what a semantic layer costs, or what it stops AI from doing.
What a 2026 benchmark measured
dbt Labs, which sells a semantic layer, published a benchmark update in April 2026. Jason Ganz and Benoit Perigaud ran 11 analytical questions on an insurance dataset 20 times each. The questions went to Claude Sonnet 4.6 and GPT-5.3-Codex twice: once writing SQL directly against the full schema, once choosing metrics and dimensions from a semantic layer.
On the semantic layer, Claude's accuracy was 98.2% against 90.0% writing SQL directly, and GPT's was 100.0% against 84.1%. The authors put the difference in how each method failed: "Text-to-SQL will cheerfully give you a wrong number". With the semantic layer, "the LLM can't produce an incorrect join or a bad aggregation: if it picks the right metric and dimensions, the query is guaranteed to be correct". Nor can it produce "correct-looking numbers that are subtly different across runs". Failure, they write, "looks like an error message". Picking the wrong metric is still possible, which is why Claude scored 98.2% and not 100%.
The cost shows in the earlier configuration of the test. On questions that went beyond what the semantic layer modelled, it answered 0%. Direct SQL scored between 48.3% and 100% on those same questions, depending on the model and the year. Closing that gap was cheap in this benchmark. The authors "prompted an LLM to create as few dbt models as possible". Their result: "With just 3 additional models, the Semantic Layer can now answer every question in the benchmark". The authors also note that loading a whole schema into the prompt, as the SQL method required, "isn't practical for larger datasets". The benchmark is small and the vendor has an interest. A 2026 study by Rumiantsau and Fokeev of Cube, which also sells a semantic layer, points the same way. In it, a four-kilobyte file of business definitions added 17 to 23 points of accuracy across three models.
What it holds in a timber business
The definitions that matter are the ones two people could read differently. Delivered volume might be scale tonnes, converted board feet, or volume paid for after deductions. Margin might be before or after freight, before or after rebates. Stock on hand might include packs in transit or tags nobody has closed. Stumpage owed might be accrued at the contract rate or at the rate last invoiced.
A semantic layer writes each of these down once: the formula, the tables it draws on, the unit, the filters. When an AI assistant is asked for margin by customer, it picks the defined metric rather than building its own from whatever columns look relevant. If the question needs a metric nobody has defined, it says so.
Where to start
Start with the handful of metrics that decisions actually rest on, and define them before connecting any AI tool. Write each definition in words first, then as a formula tied to named tables. Test it on questions finance has already answered, and keep the list of questions the layer refuses. That list is the backlog: each refusal names a metric the business uses and has never written down.
When it doesn't apply
dbt Labs' own recommendation is "Text-to-SQL for ad hoc analyses and smaller datasets", and a semantic layer "for enterprise use where accuracy is critical and datasets are large, complex, or messy". A timber business with a few systems may count as small by that standard. If so, well-labelled tables and a written definitions file may give much of the benefit without a semantic-layer product. Exploratory questions, where nobody yet knows which measure matters, sit outside any semantic layer by design. And a semantic layer is only as correct as its definitions. If a formula is wrong, every answer that uses it is wrong the same way.
How Quarri works explains the platform as a layer over existing systems, not a migration.
Sources
- Ganz and Perigaud, "Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update", dbt Labs, 7 April 2026: docs.getdbt.com
- Burnham, "Why a semantic layer is pivotal to your AI strategy", MIT Sloan, 10 August 2026: mitsloan.mit.edu
- Rumiantsau and Fokeev, arXiv 2604.25149, April 2026 (support): arxiv.org
Quarri is an AI-native data platform for the timber supply chain. It connects buying, production, sales and inventory for forest management, sawmill, wood products and pulp, paper and packaging operators.