Semantic Layer vs. Business Context for AI Analytics

A semantic layer tells an AI analytics agent how company data is structured and calculated. Business context tells it how those definitions should be used in a particular situation. A reliable analytics agent needs both.

The semantic layer should govern metrics, dimensions, joins, grain, filters, and access rules. Business context adds targets, ownership, exceptions, operating events, company terminology, and the purpose behind a question. Without the first, an agent can calculate the wrong number. Without the second, it can calculate the right number and still give the wrong answer.

This distinction matters because a good SQL query is not the same as a good business analysis. An agent may execute valid code while choosing the wrong revenue definition, comparison period, customer population, or level of detail.

What Is a Semantic Layer?

A semantic layer is a governed representation of business data. It translates warehouse tables and columns into shared concepts such as net revenue, active customer, gross margin, renewal date, and product category.

The implementation varies by platform. A semantic layer may define:

Metrics and calculations: The approved formula for revenue, churn, conversion, or another business measure.
Dimensions: The attributes by which a metric can be grouped or filtered, such as region, product, channel, or customer segment.
Relationships and joins: Which datasets can be combined and how their cardinality should be handled.
Data grain: What one row represents and which aggregations are valid.
Time logic: Fiscal calendars, reporting periods, event dates, and default comparisons.
Access rules: Which users can query particular rows, fields, or models.
Names and descriptions: The business language people use instead of raw database identifiers.

dbt describes its Semantic Layer as a place to define metrics centrally on top of existing models and handle joins consistently for downstream tools. In Looker, LookML models define tables, Explores, joins, dimensions, and measures.

For an AI agent, this governed structure narrows the space of possible interpretations. The agent does not have to guess which revenue column to sum or invent a join between orders and customers.

What Is Business Context?

Business context is the information needed to apply governed data correctly to a real decision. Some of it belongs in the semantic layer. Much of it does not.

Examples include:

The board reports net revenue, while the sales team uses booked annual contract value for pipeline planning.
A 5% decline is material for renewals but normal weekly variation for website traffic.
The Northeast region changed territory assignments on July 1, so comparisons that cross that date need an adjustment or warning.
Enterprise customers have a 90-day onboarding period and should not be included in the adoption-risk cohort before it ends.
Finance owns the official margin definition, while Operations owns the explanation for a temporary fulfillment surcharge.
A product launch, pricing change, data migration, or outage may explain a break in the trend.

This information often lives across operating procedures, planning documents, meeting notes, metric documentation, and the experience of subject-matter experts. It changes more often than a warehouse schema and may apply only to one team or decision.

Microsoft now makes the distinction explicit in Power BI. Its guidance for preparing a semantic model for Copilot includes simplifying the schema, creating verified answers, and adding AI instructions with business terminology and domain-specific logic. The model provides structure; the added instructions explain how the business expects that structure to be used.

Semantic Layer vs. Business Context

Question	Semantic layer	Business context
What does this metric mean?	Formula, source fields, aggregation, and grain	Which definition applies to this audience and decision
How should data be combined?	Approved joins, relationships, and primary keys	Known exceptions, migrations, and periods that should not be compared
Who can see the answer?	Row-, field-, or model-level access rules	Whether the result is appropriate to share or act on
What time period applies?	Fiscal calendar and valid date fields	Current planning cycle, reporting cadence, and unusual events
Is the result important?	Calculated value and statistical comparison	Target, tolerance, owner, and business consequence
What should happen next?	Usually outside the model	Review process, escalation path, and decision owner

The boundary is not perfectly fixed. A mature semantic layer can store descriptions, synonyms, default filters, and other context. The useful question is not where a field is stored. It is whether the agent receives the right information, at the right scope, from an approved source.

Why a Semantic Layer Is Necessary but Not Sufficient

A semantic layer prevents many basic errors. It can stop an agent from summing a non-additive metric, joining at the wrong grain, using a deprecated field, or bypassing an access rule.

It cannot know every reason a person is asking a question.

Consider the request: “Why did revenue fall last month?” A semantic layer can define net revenue, choose the correct order date, and provide valid dimensions for investigation. The agent still needs to know:

Whether the requester means recognized revenue, billed revenue, bookings, or another approved measure.
Whether “last month” should follow the calendar or fiscal period.
Which baseline matters: prior month, prior year, forecast, or target.
Whether a pricing change, delayed renewal, acquisition, or data migration affected the period.
Which movements are material enough to investigate.
Who owns the affected metric and should review the conclusion.

Without that context, the agent may return a technically correct decomposition that is irrelevant to the decision.

Example: How an Agent Uses the Wrong Revenue Definition

Imagine a warehouse with three governed measures:

Gross revenue: Order value before refunds and discounts.
Net revenue: Recognized revenue after refunds and discounts.
Booked annual contract value: The annualized value of newly signed contracts.

All three are legitimate. None is universally “the revenue metric.”

A finance leader asks, “Why is revenue below plan?” The correct analysis uses net revenue, the finance forecast, and the fiscal month. A sales leader asks, “Why is revenue down in enterprise?” The sales operating review may use booked annual contract value and compare the current quarter with quota.

The semantic layer supplies the three definitions and prevents invalid calculations. Business context maps each question to the right definition, target, period, and audience. If the request remains ambiguous, the agent should ask a clarifying question instead of silently choosing one.

The solution is not to delete two of the measures. It is to preserve each approved definition and document when it applies.

What Context Does an AI Analytics Agent Need?

Start with seven layers of information. Add more only when a real question requires it.

1. Business vocabulary

Map the words people use to governed entities and measures. Include common abbreviations and terms that vary by team.

For example, “customer” might mean an account with a signed contract to Finance, a workspace with recent activity to Product, and a billing entity to Operations. The agent should know the difference.

2. Metric definitions

Provide the formula, source, grain, owner, valid dimensions, and known limitations for each important metric. Mark deprecated or experimental definitions clearly.

3. Join and grain rules

Tell the agent which joins are valid and what one row represents. These rules prevent fanout, double counting, and comparisons between incompatible populations. Looker’s documentation, for example, explains why correctly defined relationships and primary keys matter when measures pass through joins.

4. Time and comparison rules

Define fiscal periods, time zones, late-arriving data, and the date field each metric uses. State which baseline is normal for each operating review.

5. Targets and materiality

A metric movement has no business meaning without a useful reference point. Provide targets, forecast values, normal ranges, and thresholds for escalation.

6. Events and exceptions

Record product launches, campaigns, outages, pricing changes, reorganizations, acquisitions, and data migrations. Include effective dates and affected populations.

7. Decision and review rules

State who owns the metric, who reviews high-impact analysis, where the result is delivered, and what the agent must not conclude automatically.

These layers turn a database question into an operating question. They also make an answer easier to audit because a reviewer can see which definition, exception, and decision rule influenced it.

More Context Is Not Always Better

An agent does not need every company document for every question. Irrelevant context can introduce conflicting definitions, stale instructions, and unnecessary ambiguity.

Use four rules:

Scope context to the task. A finance analysis should not automatically load every sales, marketing, and product procedure.
Prefer approved definitions. Identify the owner and status of important context instead of treating every document as equally authoritative.
Preserve effective dates. Business rules change. The agent needs to know which version applied during the period being analyzed.
Expose conflicts. When two approved sources disagree, ask for clarification or show both interpretations rather than hiding the choice.

This is context engineering in practical terms: selecting, structuring, governing, and maintaining the information an agent needs to perform a specific job.

How to Reuse LookML and dbt Without Creating a Second Source of Truth

If a data team already maintains business logic in LookML or dbt, an AI analytics rollout should start there.

Do not copy every metric into an isolated prompt library and expect both versions to remain synchronized. Instead:

Inventory the metrics, models, joins, and access rules that already govern reporting.
Identify business context that is missing from those models, such as targets, procedures, events, and audience-specific definitions.
Give the agent access to the approved model and only the additional context required for its work.
Test whether generated queries reconcile with trusted dashboards or analyst-produced answers.
Define how changes flow from the source system into future agent runs.
Keep a reviewer in the loop for ambiguous or high-impact conclusions.

This preserves the data team’s existing investment while acknowledging that metric logic alone does not describe the whole business.

How to Evaluate an AI Agent’s Context System

Test the system with your own data and questions. A polished demonstration over a clean sample model will not expose the hard failures.

Test 1: Ambiguous terminology

Ask for “revenue,” “active customers,” or another term with multiple valid definitions. The agent should use the correct scoped definition or ask which one you mean.

Test 2: Join safety

Ask a question that requires combining tables at different grains. Inspect the generated query and confirm that the result does not double count records.

Test 3: Business exceptions

Choose a period affected by a pricing change, outage, territory shift, or migration. Check whether the agent finds and applies the relevant context.

Test 4: Permissions

Run the same question as users with different access. Confirm that the semantic model and the finished explanation both respect those boundaries.

Test 5: Evidence

Require the metric definition, source, time period, filters, query or code, and values behind the conclusion. An answer should remain reviewable after the chat ends.

Test 6: Change management

Update a definition or instruction, then rerun a saved analysis. Confirm which version was used and whether dependent workflows receive the change safely.

Microsoft warns that AI output can vary even with the same prompt and grounding data. Its Power BI semantic-model guidance recommends preparing the model and users because unprepared systems can return inaccurate or misleading output. Evaluation should measure repeatability and inspectability, not only whether one answer looks plausible.

How Orion Uses a Semantic Layer and Business Context

Orion by Gravity is designed to use both governed data logic and additional company context.

Teams can use their existing Looker and dbt logic rather than teaching Orion every metric from raw warehouse tables. Orion’s Knowledge Base adds the information that may not belong in those models: company definitions, operating procedures, analytical methods, product documentation, and team guidelines.

Knowledge Base pages can be enabled for specific projects, which keeps the context relevant to the work. Orion can cite those pages in deliverables and accept suggested updates when new information appears. Human review and revision history help keep the shared context governed over time.

This approach is useful when a company already trusts its data foundation but needs more people to ask questions, investigate metric changes, and turn the work into a reusable report or workflow. It does not eliminate the need to maintain the semantic layer or review consequential analysis.

For adjacent guidance, see:

Frequently Asked Questions

Does an AI analytics tool need both a semantic layer and business context?

Yes. The semantic layer provides governed metrics, dimensions, joins, grain, and permissions. Business context explains which definition, target, exception, and decision rule applies to the current question. Either one by itself leaves important room for error.

How do I stop an AI analytics agent from using the wrong revenue definition?

Maintain each approved revenue measure in the semantic layer, document its owner and intended use, and give the agent rules that map audience and question type to the correct measure. If the request remains ambiguous, require the agent to ask for clarification.

Can a semantic layer prevent AI hallucinations?

It can reduce errors by constraining the agent to governed fields, calculations, and joins. It cannot guarantee that every interpretation or explanation is correct. Teams still need business context, evidence, permissions, testing, and human review.

What context does an AI analytics agent need beyond metric definitions?

It may need targets, materiality thresholds, fiscal periods, operating events, exceptions, ownership, audience, procedures, and review rules. Supply only the context relevant to the current task.

Do we need to rebuild our LookML or dbt definitions for an AI agent?

Not necessarily. Start with a product that can use the governed logic you already maintain. Add missing business context around those definitions instead of creating an independent metric system that will drift over time.

Who should own business context for AI analytics?

Ownership should follow the information. Data teams usually govern metric and model logic. Finance, Sales, Product, Operations, and other domain owners should approve the targets, exceptions, terminology, and decision rules they understand best.

A Practical Next Step

Pick one recurring question whose answer your team already trusts. Write down the approved metric, join path, grain, comparison period, target, known exceptions, permissions, and reviewer. Then ask an AI analytics product to answer the question and show its work.

The test is not whether the agent can produce SQL. It is whether it can apply the right business meaning, expose the evidence, and behave safely when the context is incomplete.

Semantic Layer vs. Business Context: What an AI Analytics Agent Actually Needs