A commercial leader asks an AI assistant,“What was our revenue in India last month?” The assistant queries the warehouseand returns a number. Finance checks it against its report and finds adifferent total.
For a data leader, the immediate challengeis identifying which part failed. Improving source quality will not resolve anundefined metric. Adding a metric description will not fix an assistant thatignores it.
A semantic layer for AI makes businessdefinitions, calculations, and relationships available to AI workflows. Itsvalue depends on whether those workflows select and apply the right meaning—andrecognize when the question requires clarification.
An unexpected AI answer can have several causes. Use the observed behavior to guide the investigation.
These are starting hypotheses. A single answer can contain several failures.
The semantic question is specific: does the system have access to the business meaning required for this request, and can it apply that meaning correctly?
A semantic layer maps business concepts to enterprise data. It can describe entities such as customers and orders, dimensions such as country, metrics such as net sales, and the relationships used to calculate them.
Snowflake’s Cortex Analyst, for example, uses semantic views containing logical tables, dimensions, facts, metrics, and relationships to connect business language with underlying data structures. [1]
The concept is established. dbt also describes centrally maintained metric logic that can serve downstream consumers. The enterprise challenge is capturing the organization’s own rules and connecting them to the tools people actually use. [2]
Here, semantic engineering means the ongoing work of agreeing, implementing, testing, and maintaining those rules.
A glossary explains a term. An executable metric calculates it. A dependable implementation connects the explanation, calculation, owner, and intended use.
Consider this simplified, illustrative sales dataset. All amounts are in INR.
Assume the organization has approved two measures:
For this example, both lines were invoiced in the reporting month, both customers have an Indian billing address, and the qualifying returns were processed in that same month. There are no taxes or currency conversions in the example. These are illustrative reporting rules, not an accounting policy.
The results are:
Gross sales = ₹100,000
Net sales = ₹100,000 − ₹10,000 − ₹15,000 = ₹75,000
Both answers are valid for their stated measures. Neither automatically answers an unspecified request for “revenue.” In this illustrative model, revenue has no approved mapping to either sales measure; sales and accounting revenue should not be treated as interchangeable.
If the business has not approved a default interpretation, the assistant should ask:
“Do you mean gross sales before discounts and returns, or net sales after those adjustments? If you mean accounting revenue, that requires a separately approved measure.”
Once the user selects net sales, an inspectable answer could read:
“Net sales were ₹75,000 for customers with an Indian billing address during the selected calendar month. This uses invoiced gross sales less discounts and qualifying returns processed in the same period.”
That answer makes the interpretation visible. A reviewer can check the measure, geography, period, and adjustments.
Finance and commercial teams may legitimately use different measures. Recognized revenue, booked orders, gross sales, and net sales answer different questions.
Putting them all behind a field called “Revenue” conceals those differences.
A useful semantic foundation gives each approved measure a clear name, intended use, and owner. It also records when the assistant should ask the user to choose.
A compact metric definition should capture:
This definition is useful to both an engineer implementing the metric and a business owner reviewing its meaning.
Storing definitions centrally does not ensure that consumers use them. The integration determines how meaning influences the answer.
Three common implementation patterns provide different controls:
These patterns can be combined. A description can help the assistant explain a metric while an approved interface performs its calculation.
For the example above, the workflow should identify the requested measure, resolve the country and period, execute the approved calculation, and return the result with material assumptions.
Access controls must still apply. Semantic context does not itself establish permission to query the underlying data.
A semantic layer becomes more dependable when definitions are managed as governed business assets rather than informal descriptions maintained by individual developers.
A practical governance approach identifies who proposes, reviews, approves and maintains each business definition. It also records the context in which a metric is valid, the data it depends on and the date from which a definition applies.
Governance does not mean adding process for its own sake. The objective is to make important business definitions discoverable, explainable and maintainable throughout their lifecycle.
Suppose the ₹15,000 return against invoice line A consists of two records: ₹10,000 and ₹5,000.
A direct join between that invoice line and both return records can repeat the ₹60,000 sales value. An otherwise sensible calculation may then overstate sales.
The implementation must handle the different detail levels—for example, by aggregating returns appropriately before combining them with sales. Tests should check the resulting totals and relevant edge cases.
This is why “net sales means gross sales minus discounts and returns” is only the beginning. The engineering must preserve that meaning through the actual data relationships.
Business owners approve the policy. Data and analytics engineers implement and test it. AI teams connect the workflow and evaluate whether it selects, explains, and applies the approved measure.
Business users need to know what a metric means. Data terms also need to know where it comes from and what depends on it. Connecting semantic definitions to technical metadata and lineage can help teams trace a metric from its source data through transformations models to dashboards, applications or AI workflows.
Useful capabilities may include schema discovery, table and column metadata, upstream and downstream dependencies, metric-to-model mapping, ownership information and change history. Automated discovery can accelerate onboarding, but inferred relationships and suggested definitions should be reviewed before they become approved business logic.
Start with one decision area and a few important metrics. Build a small evaluation set that includes straightforward requests, difficult joins, ambiguous language, and unsupported questions.
For the illustrative example:
Where feasible, compare the same questions and AI configuration with and without semantic context. Keep the data snapshot and access conditions consistent, record configuration changes, and repeat trials where model variability matters.
Measure whether the workflow:
Set acceptance criteria before reviewing results. Report failures by question type; an overall success rate can conceal a serious weakness in one metric. Semantic context should earn confidence through these checks.
A production implementation needs more than a set of definitions and a successful AI demonstration. Teams must be able to operate, monitor and evolve it as usage grows.
Semantic readiness is particularly relevant to conversational analytics and agents querying structured enterprise data. It complements source quality, freshness, access controls, and evaluation.
Before expanding a pilot, select one disputed business question and trace it through five items:
Question → approved definition → owner → executable calculation → expected answer
A missing link gives the team a concrete improvement to make.
At RandomTrees, these areas represent complementary capabilities for addressing the challenges of enterprise AI adoption:
[1] Snowflake — Cortex Analyst documentation
https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst
[2] dbt — Semantic Layer introduction
https://www.getdbt.com/blog/semantic-layer-introduction
[3] RandomTrees — Services
https://randomtrees.com/services
Related — From Business Question to Validated SQL
https://randomtrees.com/post/business-question-to-validated-sql
Related — Building an Automated Data Quality Layer Across Enterprise Pipelines
https://randomtrees.com/post/automated-data-quality-layer-enterprise-pipelines
