The short version
The technical translation is the easy part. The work is a semantic layer: agreed definitions for your business terms, mapped to actual columns, with the edge cases decided. Start with twenty questions people already ask, define only the terms those need, and always show the query so the answer is checkable.
Why does this go wrong so often?
Because a plausible answer to a question about your own data is far more dangerous than a plausible answer about anything else. Nobody can eyeball whether “4,182 active customers” is right. It goes into a board pack.
And the failure is rarely a broken query. It is a query that runs perfectly against a definition nobody agreed — counting trial accounts as customers, or including the subsidiary that finance excludes, or using a date field that means “created” where the question meant “first purchased”. The number is wrong in a way that looks entirely normal.
What is a semantic layer and why do I need one?
It is the written definition of what your business terms mean in terms of actual data: which tables and columns, which filters, which exclusions. “Active customer” means a customer record with at least one paid order in the trailing ninety days, excluding internal accounts and excluding orders subsequently refunded in full.
With that written down, a system has something to be correct against. Without it, the system guesses — reasonably, consistently, and differently from your finance team. The semantic layer is simultaneously the thing that makes this work and the thing nobody budgets for.
It is also valuable independently. Most organisations that write one discover two or three places where departments have been reporting the same metric differently for years.
Where do I start?
With the questions, not the data. Collect twenty questions people actually ask — from the reports currently being requested, the recurring Slack messages to whoever owns the database, the things that take an analyst two days each month.
Then define only the terms those twenty questions need. This keeps the definition work finite and anchored to real demand, rather than an eighteen-month exercise to model the whole business that stalls before anyone gets an answer.
Should it show the query it ran?
Always, and this is not optional. The generated query is the citation: it lets anyone who knows the data confirm the answer, and it lets someone who does not know the data ask a colleague to.
Hiding it produces a confident number with no provenance, which is the single most dangerous artefact this class of system can produce. Showing it changes the failure mode from “wrong number in a board pack” to “that filter looks off” — caught in seconds by the first person who reads it.
What about permissions?
The system must run under the asking user’s permissions, not a service account with broad access. This sounds obvious and is very commonly got wrong, because a single privileged connection is far easier to set up.
The consequence of getting it wrong is that anyone who can ask a question can reach anything — salaries, individual performance, customer records they have no reason to see — without any of it looking like a breach. The natural language interface is exactly what makes it easy: nobody needs to know how to write a query to ask what the highest salary in the company is.
Will it replace our analysts?
It removes a category of request rather than a role. The two-day exercise to produce a number somebody needed for a meeting largely disappears, and most analysts regard that as the worst part of the job rather than the point of it.
What remains is the work that was always the value: deciding which questions are worth asking, investigating why a number moved, building the definitions the system depends on, and challenging a result that looks wrong. Analysts also become the natural owners of the semantic layer, which makes them more central rather than less.
How accurate is it?
Very high on questions covered by defined terms, and unreliable outside them — which is exactly why the boundary needs to be visible. A system that answers confidently on an undefined term has produced a guess dressed as a fact.
The behaviour to insist on is a refusal: “I don’t have a definition for ‘engaged user’ — here are the terms I do know”. That is a good answer, it tells the user exactly what to fix, and the list of things people ask for that are undefined becomes your roadmap for the semantic layer.
What data should it not touch?
Personal data beyond what the asker is entitled to see, individual performance records, salary information, and anything with a regulatory access regime attached. Decide this deliberately at design time rather than assuming permissions will handle it.
It is also worth logging every question asked. Not to police anyone, but because the log is both an audit trail if a query is ever challenged and the clearest available signal of what the business actually wants to know.
How do we know if it is working?
Three measures. How many of the twenty original questions it answers correctly without help. How many ad hoc requests to the data team have stopped arriving. And how often someone acts on an answer without checking it — which sounds like a success measure and is worth watching carefully, because unchecked trust in an undefined term is precisely where the expensive mistake comes from.
The healthiest pattern is people trusting it on defined terms, checking the query when the answer surprises them, and coming back to extend the definitions when they hit its edge. That is a system being used properly rather than believed uncritically.
Does this work on a data warehouse we do not have?
Poorly, and it is worth being direct about it. If your data lives in six operational systems that disagree with each other, a natural language layer over any one of them answers questions about that system rather than about the business.
You do not need a full warehouse programme first, but you do need one place where the questions can be answered from. Often that is a modest set of joined tables covering the twenty questions rather than a model of everything — which is weeks of work rather than quarters, and it is the same work you would have to do eventually anyway.
What does it cost to run?
Less than people expect on the query side, because the volume is low — humans ask a few questions a day, not thousands. The ongoing cost is the semantic layer: definitions drift as the business changes, and something must be somebody’s job.
Budget for a quarterly review with whoever owns the metrics. A definition that quietly stopped matching how the business now operates produces confident, consistent, wrong answers — which is worse than a system that admits it does not know.