August 26, 2026 · semantic-layer · governance · analysis
The Meaning Hiding Inside ‘Growing’
A governed metric is only part of an analytical question. Words such as growing, declining, and churning can still hide choices about population, period, comparison, and scope.
Venkatesh Seetharam
Co-founder & CEO
Harish Butani
Co-founder & CTO
An executive asks a routine question: “How is revenue growing in the Northeast?”
Revenue may already be governed. Northeast may already be governed. The word still carrying much of the analysis is growing.
Same-store or all locations? Percentage change or absolute delta? Compared with last month, last year, or plan? Fiscal or calendar period? Currency adjusted? Several readings can be legitimate. A metric definition alone may not select one.
The point is not that semantic layers ignore calculations. Many define standard growth, churn, and retention metrics. The long tail begins when an ordinary question combines governed objects in a way nobody authored in advance.
The semantic layer is the foundation
Tables, columns, and keys describe the data model. Semantic models add business meaning: approved measures, dimensions, hierarchies, joins, and sometimes derived calculations. That work is valuable. An AI analyst should use it, not route around it.
But business questions rarely stop at a metric. They ask whether revenue is growing, a segment is churning, a product is underperforming, or customers are becoming less engaged. Those verbs compose metrics, populations, comparisons, periods, thresholds, and judgment.
Some semantic systems can encode some of this logic. The problem is not that they govern nothing. It is that the combinations used in ordinary questions often extend beyond what the organization anticipated and authored.
Analysts compose more than metrics
A human analyst reads “losing regular buyers” and translates it into an analysis. They may reuse a known cohort, choose a period, compare against a baseline, and ask what “regular” means for this team.
That interpretation can be good or bad. The useful part is that another person can ask the analyst what they chose and why. In strong teams, the answer points to a shared definition, local convention, prior analysis, or explicit clarification.
Metadata and lineage systems make much of the technical path inspectable. They do not, by themselves, record why a particular analytical composition was right for this question.
Fluency can hide the composition
A language model can interpret the same phrase and generate a polished result. If the system does not expose the interpretation, the choice is buried inside a fluent workflow. Changes in phrasing, context, or model behavior can also change a material choice without making that change obvious to the reviewer.
The risk is not that every run will differ. It is that a difference in meaning can be silent.
The evaluation question, then, is not only whether the model found the right table. It is whether the system shows the analytical verbs it applied:
- What did “growth” mean here?
- Which population was compared?
- Which period and baseline were used?
- Which definitions came from governed context?
- Which remaining choice required clarification?
Put the analytical operation on the record
Our approach is to represent the intended analysis as a visible plan before SQL executes. Available semantic definitions ground the nouns. The plan also exposes the operations being applied to them: comparison, ranking, segmentation, filtering, and time logic.
When an unresolved choice would materially change the analysis, the system should ask. When a definition the team maintains resolves it, the system should cite that source. Query generation can then be checked against the material bindings in the selected plan.
This is not a claim that every analytical verb can be pre-modeled or that a visible plan makes an answer automatically correct. It is a design principle: do not let the most consequential part of the question disappear between the prompt and the SQL.
The semantic layer gives AI analytics a strong foundation. The next requirement is a reviewable way to compose the operations around that foundation without letting their meaning disappear between the question and the SQL.
See what an interpretation plan makes visible: how Spotonix works