The Semantic Layer Was AI Infrastructure All Along

Disclosure: These views are my own and do not represent my current or any former employers. This paper uses only public sources and does not describe non-public product information.

Executive summary

Enterprise AI is often presented as a model adoption problem. Select a capable model, connect it to company data, and useful answers should follow.

The difficult part usually appears earlier because the model does not know what an organisation means by active customer, recognised revenue, available service, qualified lead, resolved incident, late order, or compliant transaction. A database schema can expose tables and columns without explaining which measures are authoritative, how entities relate, which aggregation is valid, whose definition applies, when the data was observed, or whether the current user may see it.

Semantic models were built to solve that translation problem for business intelligence. They define measures, dimensions, relationships, hierarchies, business terminology, aggregation behaviour, and access rules above physical data. That is relatively old technology. It is also much of the context that an AI system needs before natural language can become a reliable enterprise query.

Microsoft now describes Power BI semantic models as logical descriptions of an analytical domain containing metrics and business-friendly terminology.[3] Its current Fabric training explicitly teaches organisations to prepare a semantic layer for AI by adding metadata and linguistic context, then to expose that meaning through semantic models and ontologies.[10] Fabric Data Agents use schema, metadata, synonyms, numerical ranges, report visual metadata, and Prep for AI configuration when generating DAX.[6]

The same architecture is appearing across the industry. Snowflake semantic views define business entities, metrics, dimensions, and relationships for Cortex Analyst and Cortex Agents.[14][15] Databricks metric views define metrics once and add agent metadata such as display names and synonyms to improve natural-language interpretation.[17][18] Google grounds Looker Conversational Analytics in LookML.[20][21] The dbt Semantic Layer centralises metric definitions for downstream tools and applications, including AI consumers.[22]

The convergence responds to documented difficulty in enterprise text-to-SQL. BEAVER uses more than 9,000 question-SQL pairs derived from private enterprise warehouses and reports 10.8 percent accuracy for the strongest evaluated agentic configuration in its May 2026 revision.[24] Spider 2.0 contains large schemas, several SQL dialects, documentation, and multi-step workflows. Its original code-agent baseline solved 21.3 percent of tasks, although specialist systems on the live Spider 2.0-Snow leaderboard had exceeded 90 percent by August 2026.[23][28] AmbiQT demonstrates a separate problem: one natural-language question can map plausibly to two queries when schemas contain overlapping names and relationship paths.[25]

These benchmarks establish the difficulty of raw enterprise translation rather than proving that a semantic layer is the only solution. A mature semantic layer can remove some uncertainty before the model starts by providing:

1. a governed vocabulary;
2. authoritative measures and aggregation rules;
3. entity relationships and valid join paths;
4. user-facing names, descriptions, and synonyms;
5. scope and access controls at query time;
6. lineage and ownership information;
7. stable query interfaces;
8. reusable definitions across reports, applications, and agents.

An organisation that has invested seriously in Fabric, Power BI semantic models, Snowflake semantic views, Databricks metric views, LookML, or dbt MetricFlow may therefore be materially closer to AI readiness than its AI programme assumes. It has already completed part of the expensive organisational work: agreeing what important data means.

That conclusion applies only within clear boundaries. A semantic model is potential AI infrastructure rather than automatic AI readiness. Microsoft's own documentation requires intentional preparation through focused AI data schemas, verified answers, instructions, and evaluation.[6][7][8] It also states that nondeterministic AI features cannot guarantee the same output every time.[7] A semantic layer can preserve a bad definition, become stale, omit unstructured knowledge, expose an incomplete lineage path, or provide a confident answer over poor source data. It does not replace current data quality, identity enforcement, model evaluation, provenance, incident response, or deterministic controls for consequential actions.

This paper is therefore about AI consumption of structured enterprise data, not foundation-model training and not every form of retrieval. Its main claim is:

A mature, governed semantic layer shortens the path to reliable enterprise AI because it supplies business meaning and query constraints that raw data does not. The remaining work is to prepare, evaluate, operate, and bound that layer for AI use.

The practical test is whether priority business questions can travel through the analytics platform with stable meaning, current evidence, correct access, testable answers, and an accountable owner.

1. Data access is not business understanding

Giving an AI system database access solves a transport problem. It does not solve interpretation.

Consider a warehouse containing these fields:

cust_status
net_amt
close_dt
case_state
region_key

The model can infer plausible meanings. It cannot know, from the names alone, whether:

• cust_status describes billing, support, product use, or legal standing;
• net_amt is net of discounts, returns, tax, credits, or currency conversion;
• close_dt records a contractual close, a sales estimate, or a system event;
• case_state = resolved means customer recovery, internal closure, or no further action by one team;
• region_key should follow the customer, transaction, service, or reporting entity.

Documentation can help, but enterprise questions usually depend on several definitions at once. "What was net revenue from active European customers last quarter?" requires the system to identify:

1. the authoritative customer entity;
2. the approved definition of active;
3. the correct revenue measure;
4. the valid relationship between customers and transactions;
5. the organisation's fiscal calendar;
6. the geographic classification rule;
7. currency and return treatment;
8. the current user's access.

A raw table catalogue may contain all required columns and still leave every one of those choices unresolved.

This is why enterprise text-to-SQL is not equivalent to code generation over a small demonstration database. Spider 2.0 tasks can require searching metadata, dialect documentation, and project code before producing several queries that may exceed 100 lines.[23] BEAVER focuses on private warehouse conditions where domain knowledge and complex analytical functions matter.[24] SQL syntax is only part of the challenge; the system must also locate and apply the organisation's meaning.

What AI consumption means here

This paper uses AI consumption to mean a model or agent retrieving, analysing, or reasoning over enterprise data at inference time. Examples include:

• conversational analytics;
• a data agent answering operational questions;
• an assistant preparing an incident briefing;
• a customer-support copilot interpreting account state;
• an agent using governed metrics to decide whether to escalate;
• a model generating DAX or SQL against approved data.

This is different from training a foundation model on enterprise records. A semantic model is primarily a query and meaning layer. It does not make source data suitable for pretraining, fine-tuning, or unrestricted ingestion.

The distinction matters because "AI-ready data" is often used without saying which AI use is intended. Data prepared for aggregate financial questions may be unsuitable for document retrieval. A model designed for reporting may not represent operational state transitions. A semantic layer can be highly useful inside its declared analytical domain while offering no answer outside it.

AI readiness should therefore be assessed against priority questions and actions, not awarded as a platform-wide label.

2. What a semantic model already contains

A semantic model sits between physical storage and a consumer. It expresses an analytical domain in terms that the consumer can use safely and consistently.

In Microsoft Fabric, Power BI semantic models are described as logical representations of analytical domains containing metrics, business-friendly terminology, facts, and dimensions.[3] Snowflake uses semantic views as schema-level metadata objects for entities, facts, dimensions, metrics, and relationships.[14] Databricks metric views separate measure definitions from the dimensions used to group and filter them.[17]

Although the implementations differ, their core responsibilities are familiar.

These artifacts form more than a convenience layer. Suppose five reports each calculate active customers independently and a sixth consumer is added through an AI agent. Without a governed definition, the agent becomes another place where logic can diverge. With a shared measure, the agent can ask for the result rather than reconstructing the definition from raw events.

Snowflake's documentation gives a similar example. A physical column with an opaque name can be represented as gross revenue, while net revenue can be defined once with the correct aggregation. Snowflake explicitly notes that without a semantic view, inconsistent calculations can spread across reports and applications.[14]

The semantic model is not the source of truth

The phrase single source of truth is often applied too broadly. A semantic model can be the authoritative definition of a metric without being the authoritative source for every underlying fact. The customer system may own account status. The order system may own transactions. A policy repository may define eligibility. The semantic model combines and interprets those sources for a declared analytical purpose.

That distinction should remain visible:

System of record -> curated data -> semantic definition -> AI query -> output

Each arrow can fail independently: the source can be wrong, transformation can be late, the semantic definition can be stale, the generated query can select the wrong object, and the model can misstate the result. A reliable architecture preserves these boundaries rather than treating the semantic layer as proof that every answer is true.

3. Why old modelling technology fits a new consumer

Dimensional models, OLAP cubes, governed measures, and semantic layers long predate generative AI. They were created because physical data structures are poor interfaces for most business questions.

The new consumer changes the scale of that old problem. A trained analyst may recognise a warehouse convention, remember an exception, or ask the data owner before using a doubtful metric. A language model can generate a plausible query without noticing that the choice was ambiguous, then repeat that choice across many users and interfaces.

Semantic modelling provides a useful division of labour:

Language model:
  Interpret the user's wording and propose an analytical intent.

Semantic layer:
  Resolve business concepts, metrics, relationships, and allowed scope.

Query engine:
  Execute deterministic calculations against current data.

Policy boundary:
  Decide whether the result may be disclosed or used for an action.

The model remains probabilistic even though the calculation beneath it can stay deterministic.

This is particularly important for measures. A language model should not recreate recognised revenue, customer retention, service availability, or error-budget consumption every time a user asks. It should select a reviewed definition and supply the requested filters and grouping.

Language metadata becomes operational

Descriptions and synonyms once improved self-service reporting; they now influence machine interpretation. Microsoft documents that Fabric Data Agents can use semantic-model schema, synonyms, numerical value ranges, report visual metadata, and Prep for AI configuration during DAX generation.[6] Databricks describes display names, format specifications, and synonyms as agent metadata that improves LLM accuracy.[18] Looker states that Conversational Analytics uses LookML fields, labels, descriptions, synonyms, and sampled values as source context.[21]

Metadata quality now affects production behaviour. A label is no longer only a presentation choice. A synonym can determine which measure an agent selects. A missing relationship can prevent the system from answering a valid question. An obsolete description can guide the model toward an obsolete interpretation.

Organisations that treated semantic metadata as optional documentation will need to treat it as executable context.

Human verification still matters

Several platforms now expose verified or approved query patterns.

Power BI verified answers associate human-approved visuals and filters with trigger phrases at the semantic-model level.[8] Snowflake uses verified queries both to answer known questions and to suggest broader semantic concepts such as the definition of active user.[16] Looker data agents can include verified queries in their configured context.[20]

The mechanism varies, but the design principle is stable:

High-value business questions should have testable expected interpretations.

These reviewed patterns create anchors around questions where ambiguity is expensive without requiring a hard-coded dashboard for every question.

4. Microsoft Fabric as an AI data path

Fabric is a useful worked example because it connects storage, transformation, semantic modelling, natural-language access, governance, and AI integration inside one platform.[1]

The existing analytics path already resembles an AI grounding path, even though one product cannot remove every boundary.

OneLake provides the shared data foundation

OneLake is the logical data lake included with each Fabric tenant. Microsoft describes it as a central location for analytics and AI workloads across the organisation.[2] It stores tables in Delta Parquet or Iceberg and supports distributed ownership through tenants, domains, workspaces, and data items.

This helps with several AI prerequisites:

• one discoverable location rather than many disconnected copies;
• open table formats;
• shared governance and security;
• data reuse across analytical engines;
• ownership boundaries through domains and workspaces.

Central storage is still not semantic readiness. OneLake can hold an excellent gold layer or a large collection of poorly described tables. The value depends on preparation, ownership, and curation.

Curated data supplies stable analytical grain

Fabric lakehouses, warehouses, pipelines, notebooks, and dataflows can turn raw records into curated tables. Direct Lake moves data preparation into OneLake rather than maintaining a separate imported copy inside each semantic model.[4]

That architecture can reduce duplication and refresh cost. It also moves responsibility upstream.

If currency conversion, identity resolution, late-arriving facts, or deletion handling is wrong in the curated layer, Direct Lake makes the wrong result available efficiently. Performance is not evidence of meaning.

The semantic model supplies business interpretation

The semantic model adds:

• facts and dimensions;
• relationships;
• measures and calculations;
• hierarchies;
• names and descriptions;
• row-level and object-level security;
• presentation and analytical behaviour.

Since September 2025, Fabric no longer creates default Power BI semantic models automatically for new warehouses, lakehouses, and mirrored items.[3] This is a useful architectural signal. Storage does not create business meaning by itself. A semantic model is now an explicit design artifact.

Direct Lake reduces the distance to current data

Direct Lake semantic models read Delta tables from OneLake into the VertiPaq engine. A framing operation refreshes metadata references to the latest files rather than copying the whole dataset into an import model.[4]

This can shorten the path between prepared data and interactive analysis. It does not remove every freshness question:

• the upstream pipeline may be late;
• framing may not have occurred;
• a source may use a different update cadence;
• cached results may remain visible;
• the business definition may be stale even when the rows are current.

AI answers need freshness at both levels:

Data freshness: Are the records current?
Semantic freshness: Is the definition still valid?

Security can remain in the query path

Direct Lake can evaluate access using the current user's Microsoft Entra ID identity or a configured fixed identity. Microsoft documents workspace, item, compute, OneLake, row-level, and object-level security options.[5]

This is materially better than asking a model to remember which rows it should not disclose. Access control belongs in the query and data systems.

The configured identity still matters. A fixed identity can create a different scope from user single sign-on. An agent that crosses product or compliance boundaries needs its own review. Microsoft warns that some Fabric IQ integrations may send data outside an Azure compliance boundary and places responsibility for geographic and compliance implications on the deploying organisation.[11]

Lineage supports investigation

Fabric provides lineage views across items in a workspace and shows upstream connections outside the workspace one level up.[12] This helps answer:

• which pipeline produced the table;
• which semantic model depends on it;
• which reports may be affected by a change;
• why an answer may be stale.

Lineage is not automatically complete. Cross-workspace and external dependencies may require other views and governance systems. The presence of a lineage interface is useful; its coverage must still be measured.

The Fabric path

An organisation may already have the first three layers. That is significant. It is not the same as having completed the last three.

5. Preparing a Fabric semantic model for AI

Microsoft's current product documentation is unusually explicit about the preparation required.

Fabric Data Agents process questions through an orchestrator, select a source, generate DAX for a Power BI semantic model, execute the query, and format the result.[6] For semantic models, query generation depends on metadata and Prep for AI configuration across three components.

AI data schemas

An AI data schema presents a focused subset of tables, columns, and measures. This reduces the number of plausible interpretations.

Microsoft gives a direct example: a model may contain Total Revenue, Gross Sales, Net Sales, and Sales After Returns. If a user asks for sales, the system must choose. Focusing the AI schema on the organisation's intended measure removes a class of guesswork.[6]

This is one of the strongest arguments for reusing mature analytics models. The organisation has probably already encountered this ambiguity in reports and executive reviews. AI does not create the definitional conflict. It makes the cost of leaving it unresolved more visible.

An AI schema should therefore be designed around intended questions, not around everything the user could technically access.

Verified answers

Verified answers associate likely questions with human-approved visuals, measures, filters, and trigger phrases. They are stored at model level and can be reused across reports or data agents that consume the same model.[8]

They are useful for:

• terms with several plausible meanings;
• executive or regulated metrics;
• common questions where consistency matters;
• calculations with non-obvious filters;
• questions used in acceptance testing.

They also create maintenance work. If a referenced measure changes, the verified answer must be reviewed. A verified answer can become confidently stale.

AI instructions

AI instructions add business context and analytical guidance to the semantic model. Microsoft states that these instructions are interpreted by an LLM and are not guaranteed to be followed exactly.[6]

This creates an important control boundary:

Guidance improves interpretation. It does not become a security boundary because it is written next to the model.

Evaluation is part of preparation

Microsoft provides a Fabric Data Agent SDK for loading questions and expected answers, running evaluations, and inspecting summary and step-level results.[9] The evaluation feature is currently in preview.

This is a material change from traditional dashboard acceptance. An AI-facing semantic model needs an evaluation set containing:

• common business questions;
• ambiguous terms;
• conflicting measures;
• missing and stale data;
• security boundary cases;
• unsupported questions;
• expected clarifications;
• priority executive or customer questions;
• regressions from previous failures.

The evaluation should test interpretation, generated query, source scope, and final answer separately. A correct number with the wrong access path is not a pass. A correct DAX query followed by an unsupported narrative claim is not a pass.

Preview status matters

Prep for AI, advanced DAX generation, evaluation, and Fabric IQ contain preview features as of August 2026.[6][7][9][11] Preview documentation states that some capabilities have no service-level agreement and are not recommended for production workloads.[11]

The architectural direction is clear. The operational maturity of each component must be assessed separately.

Microsoft also plans to retire Power BI Q&A experiences in December 2026.[13] The advanced DAX documentation currently notes that instance value indexing depends on a Q&A setting and that replacement configuration will be documented.[6] This is a reminder that AI-readiness metadata has its own product lifecycle.

6. The industry is converging on governed meaning

Fabric is one implementation of a wider design:

Snowflake

Snowflake states that generic text-to-SQL systems struggle when given only a database schema because schemas lack business process definitions and metric handling.[15] Semantic views add logical entities, relationships, facts, dimensions, and metrics. Cortex Analyst uses that information to generate SQL against physical tables.

Snowflake also exposes an improvement loop through verified queries. A reviewed query for active users can be used to suggest a reusable definition of active.[16] That is semantic governance becoming training data for the organisation's analytical interface, without retraining the underlying foundation model.

Databricks

Databricks metric views define measures once while allowing dimensions and groupings to be selected at query time.[17] Agent metadata adds display names, synonyms, and formatting rules specifically to improve how Genie and other natural-language tools interpret the data.[18]

Genie is presented as a natural-language experience over data governed through Unity Catalog, with domain-specific agents configured by data teams using trusted data, metrics, and business rules.[19]

Looker

Google describes Looker Conversational Analytics as grounded in the Looker semantic modelling layer for governed self-service analysis.[20] Its best practices state that response quality depends on the clarity of LookML fields, measures, labels, descriptions, synonyms, and data-agent configuration.[21]

This is an important concession from the platform itself: a stronger model does not remove the need for a clear semantic interface.

dbt

dbt moves metric definitions into a central modelling layer and uses MetricFlow to handle joins and serve consistent metrics to downstream applications.[22] The same definition can be consumed through reports, spreadsheets, APIs, and AI integrations.

The dbt architecture is useful because it separates semantic definitions from one BI product. It also highlights a portability question for every organisation: are business definitions reusable across consumers, or trapped inside one interface?

What the convergence proves

The platforms cannot prove that semantic modelling guarantees correct AI, but they support a shared architectural conclusion:

Enterprise natural-language access works better when business meaning is explicit, governed, and queryable.

The commercial implementations differ in maturity, security model, portability, and scope. Fabric IQ remains in preview while other semantic features are generally available. The comparison should not flatten those differences.

The architectural direction is still clear enough to influence investment. Semantic work completed for BI can become reusable infrastructure for agents, provided that it is current, accessible, and tested for the new consumer.

7. How close existing investment gets you

An organisation that has invested in mature semantic models may already have:

• a shared business vocabulary;
• approved measures;
• mapped relationships;
• a curated gold layer;
• data owners;
• security roles;
• lineage;
• release processes for model changes;
• usage history showing priority questions;
• report visuals that can become verified-answer candidates.

Those assets reduce the amount of new work needed for AI consumption, although their value varies. A large number of reports can coexist with weak measure governance. A catalogue can exist without active ownership. A model may contain relationships but still expose twenty versions of revenue.

The following ladder distinguishes possession from readiness.

Level 0: Raw access

The agent receives tables, columns, and database credentials.

It must infer terminology, relationships, measures, and valid queries. This is the environment in which enterprise text-to-SQL benchmarks show large performance gaps.[23][24]

Level 1: Documented schema

Tables and columns have usable names, descriptions, correct types, and explicit relationships.

The agent can navigate more reliably, but important calculations may still be recreated differently by each consumer.

Level 2: Governed measures

Priority metrics, dimensions, and aggregation rules are defined once and owned.

The agent selects an approved measure rather than synthesising business logic from raw fields.

Level 3: Access-controlled semantic layer

Identity, row scope, object visibility, and data permissions are enforced at query time. The semantic model is versioned and its dependencies are visible.

AI can now consume governed meaning without receiving unrestricted database access.

Level 4: AI-prepared semantic layer

Priority questions define a focused AI schema. Names, descriptions, and synonyms reflect user language. Verified answers cover expensive ambiguity. Instructions describe analytical context. Evaluation tests expected and adversarial questions.

This is where a mature BI model becomes an intentional AI interface.

Level 5: Operated AI consumption

The organisation monitors answer quality, security boundaries, freshness, lineage, cost, and failures. It can identify which semantic-model version, query, source data, and model configuration produced an answer. Changes use progressive release and rollback. Incidents have owners.

Level 5 is a continuing maintenance regime rather than a fixed destination.

Readiness is question-specific

A useful conservative model is:

Readiness for one priority question =
  minimum of:
    meaning coverage,
    source authority,
    access correctness,
    data freshness,
    evaluation coverage,
    operational ownership

The minimum matters because an average hides broken links.

A perfectly documented metric with stale source data is not ready. A correct measure exposed to the wrong user is not ready. An accurate answer with no owner or regression test is not ready for dependable operation.

8. What the semantic layer does not solve

The semantic layer is powerful partly because its scope is bounded. Expanding its claims beyond that scope weakens the architecture.

It does not repair source data

A reviewed measure can calculate precisely over duplicated customers, misclassified orders, missing events, or delayed transactions.

Semantic logic may hide some source defects by filtering or compensating for them. That can be useful. It can also make the defect harder to see.

AI readiness still requires:

• source quality ownership;
• validation at ingestion and transformation;
• reconciliation with systems of record;
• observability for pipeline delay and loss;
• explicit treatment of late and corrected data;
• known uncertainty in the result.

Direct Lake makes this boundary especially visible. It can make prepared OneLake data available quickly, but Microsoft explicitly places data preparation in the lake path.[4] The semantic model cannot infer that a missing partition should have arrived.

It does not cover all enterprise knowledge

Many questions depend on documents, policies, contracts, tickets, source code, incident records, and conversation history.

A semantic model may know that a customer is in a particular segment. It may not know why a contract contains an exception. It may calculate service availability without containing the incident decision that excluded a specific maintenance window.

Structured semantic access and document retrieval should complement each other:

Semantic layer:
  governed entities, measures, relationships, and analytical state

Document retrieval:
  policy text, rationale, exceptions, evidence, and narrative context

The application needs a rule for which source is authoritative for each claim. Blending both into one generated answer without provenance recreates the ambiguity the semantic layer was meant to reduce.

It does not guarantee novel analysis

Semantic layers are strongest when important concepts and relationships are known in advance.

Exploratory questions may require:

• a field that was deliberately excluded;
• a new relationship;
• a temporary cohort;
• event-level detail;
• an unmodelled external source;
• a calculation that has not yet been governed.

The correct response may be to ask for clarification, route the question to an analyst, or create a reviewed extension. Returning a confident answer from the nearest available measure is worse than admitting that the question is outside the modelled domain.

It does not govern actions

A semantic model can calculate that inventory is below a threshold. It should not, by itself, authorise a purchase.

It can identify customers whose account state appears eligible for a refund. It should not replace the current entitlement system and approval policy.

The output of a semantic query can inform an action. Permissions, preconditions, recipient restrictions, financial limits, and destructive operations must be enforced by deterministic systems after the query.

It does not remove model behaviour

Microsoft notes that Prep for AI cannot ensure the same output every time because Copilot behaviour remains nondeterministic.[7] AI instructions are guidance, not guarantees.[6]

The semantic layer narrows the space of interpretation. It does not remove natural-language ambiguity, response-generation error, unsupported claims, or the possibility that the model answers a different question from the one the user intended.

9. Failure modes of AI-facing semantic layers

The new consumer changes the consequences of familiar modelling defects.

Confident staleness is the central risk

Ungoverned data often looks uncertain. A semantic layer is designed to look authoritative.

That is valuable when the definition is current. It is dangerous when the authority is inherited from past review rather than present validity.

A metric record should therefore carry:

• accountable owner;
• definition and business purpose;
• source systems;
• valid grain and dimensions;
• date last reviewed;
• event that requires revalidation;
• known exclusions;
• consumers;
• tests;
• superseded version.

The AI-facing description should not outlive the evidence behind it.

Too much schema can reduce accuracy

The instinct to expose everything is understandable. More fields appear to create more capability.

Microsoft's AI data schema guidance argues for a focused subset because large models with overlapping fields increase ambiguity and latency.[6] The same principle appears in other platforms through curated Explores, semantic views, metric views, and domain-specific data agents.

The selection question is:

What is the smallest governed semantic surface that answers the intended questions?

Useful data can remain in the enterprise catalogue while each agent receives a smaller supported query surface.

Security must be tested through the whole path

A model can have correct RLS and OLS while the application uses a broad service identity. A data agent can execute a permitted query and then include another user's context in the prompt. An integration can cross a geographic or compliance boundary not present in the original BI path.

Security testing should include:

• direct semantic-model access;
• agent access using each supported identity mode;
• users with no workspace role;
• users with partial row and object access;
• malformed and attacker-selected identifiers;
• cached and follow-up questions;
• exported or embedded output;
• downstream tool calls.

The test result should state which boundary was exercised. "RLS enabled" is a configuration fact, not end-to-end evidence.

10. The semantic model as an AI consumption contract

An AI-facing semantic model should be treated as a versioned contract between business meaning, data engineering, security, and the consuming application.

The contract needs ten parts:

Questions outside the declared set may still work, but they do not inherit the same reliability claim. If several teams use different meanings, scope or explicitly named variants should preserve the disagreement. A model should not silently choose between order customer and billing customer, for example, when the two relationships answer different questions.

The same measure may also be acceptable for aggregate planning and prohibited for individual employment evaluation. The contract must describe permitted use as well as calculation.

Appendix B provides a copyable priority-question record. Detailed provenance retention can vary by consequence, but consequential answers need enough evidence to reconstruct the semantic version, generated query, source state, identity, and policy decision.

11. A practical operating model

The work can begin without a platform migration.

The sequence also fits the continuing Govern, Map, Measure, and Manage functions in the NIST AI Risk Management Framework. The Generative AI Profile extends that risk-management approach for generative systems.[26][27]

Step 1: Select priority questions

Choose ten to twenty questions that:

• recur frequently;
• influence a material decision;
• currently require analyst interpretation;
• produce disagreement;
• would create harm if answered incorrectly;
• demonstrate several semantic domains.

Do not start by exposing the entire warehouse to a general assistant.

Step 2: Map existing assets

For each question identify:

• current report or dashboard;
• measure;
• semantic model;
• source tables;
• data owner;
• security policy;
• existing test;
• known disagreement;
• current manual explanation.

This reveals how much AI-readiness work has already been completed.

Step 3: Resolve definitions before prompt engineering

If two executive reports use different revenue definitions, an AI instruction cannot make both authoritative.

Resolve or scope the conflict. Name each variant. Record ownership. Then expose the intended measure.

Prompt tuning should not be used to conceal unresolved governance.

Step 4: Create a focused AI surface

Select only the entities, dimensions, measures, and synonyms needed for the question set.

In Fabric this can use Prep for AI and an AI data schema.[6][7] Other platforms use semantic views, metric views, LookML Explores, or MetricFlow models.

The focused surface should preserve dependencies required by the selected measures.

Step 5: Build an evaluation set

Include:

• canonical questions;
• paraphrases;
• ambiguous wording;
• wrong-but-plausible measures;
• missing data;
• stale data;
• unauthorised users;
• cross-tenant or cross-region scope;
• unsupported questions;
• questions requiring clarification;
• regression cases from production.

Evaluate generated query and final answer separately.

Step 6: Add verified anchors

Create verified answers or queries for high-value questions.

Avoid using them only to make a demonstration look reliable. They should cover real ambiguity and be maintained as business definitions change.

Step 7: Enforce identity and policy

Test the effective identity at query time. Put row, object, tenant, and purpose restrictions in deterministic systems.

If the application can take action, add a separate action contract after data retrieval.

Step 8: Release progressively

Start with:

1. internal data owners;
2. analysts;
3. a small business cohort;
4. wider read-only access;
5. bounded actions only after separate control review.

Monitor unsupported-question rate, correction rate, access failures, query latency, and business disagreement.

Step 9: Operate the semantic layer

Trigger re-evaluation when:

• a measure changes;
• a relationship changes;
• a source system changes;
• a new region or product is added;
• security policy changes;
• a verified answer changes;
• the agent runtime or model changes;
• a user reports a material discrepancy.

Semantic definitions should have the same change awareness as APIs and production configuration.

Step 10: Prepare for incidents

Declare an AI data incident when:

• a material metric is wrong;
• unauthorised data is disclosed;
• stale data is presented as current;
• an important question selects the wrong definition;
• a model change creates broad analytical regression;
• the organisation cannot reconstruct a consequential answer.

The incident record should include semantic version, generated query, source state, access context, affected questions, affected users, correction plan, and downstream decisions.

12. What to measure

AI data readiness should be measurable without pretending that one score proves truth.

Priority-question coverage

Measure the percentage of selected questions with:

• named owner;
• approved concepts and measures;
• valid source path;
• access test;
• freshness objective;
• expected interpretation;
• evaluation case;
• incident owner.

Report the weakest missing element rather than only the average.

Authoritative metric coverage

Measure how many material KPIs have one approved definition within the relevant scope.

Conflicting definitions may be legitimate across finance, sales, and operations. They should be explicitly named and bounded.

Semantic metadata coverage

Measure description, synonym, ownership, and review-date coverage for objects exposed to AI.

Coverage does not measure quality. Sample whether the metadata distinguishes the terms users actually confuse.

Ambiguity rate

Track the percentage of priority questions that:

• match several plausible measures;
• require clarification;
• produce different query structures across runs;
• are routed to the wrong domain;
• receive an unsupported answer.

The measure identifies where more data is not the answer.

Verified-question pass rate

Run the evaluation suite after semantic, data, model, agent, or policy changes. Track:

• exact interpretation pass;
• acceptable result tolerance;
• unsupported-claim rate;
• query execution failure;
• clarification correctness;
• regression by question cohort.

Access-boundary pass rate

Continuously test expected allow and deny cases across roles, rows, objects, workspaces, tenants, and identity modes.

Any disclosure failure should be counted separately from ordinary answer accuracy.

Freshness compliance

Measure both source and semantic freshness:

Source freshness:
  observation time to query availability

Semantic freshness:
  business change to reviewed definition deployment

The second measure is often missing because semantic change is treated as documentation work rather than production change.

Lineage coverage

Measure the percentage of exposed measures for which an operator can trace:

• source;
• transformation;
• semantic definition;
• verified question;
• consuming agent or application.

Correction propagation time

Measure how long it takes from an accepted correction until:

• the definition is updated;
• evaluation passes;
• caches and verified answers reflect it;
• users receive corrected output where required;
• the old definition stops influencing ordinary questions.

Cost per governed answer

Semantic preparation creates maintenance cost. AI querying creates model and compute cost.

Track cost against:

• priority questions answered;
• analyst work avoided;
• decision latency reduced;
• user adoption;
• correction burden;
• incidents.

Ingestion volume and token use are operational inputs, not business outcomes.

13. Counterarguments

A capable model can infer the schema

Models can infer many names, joins, and calculations. That is useful for exploration.

The benchmark evidence shows that enterprise workflows still require metadata, documentation, domain knowledge, and multi-step reasoning.[23][24] The rapid gains on the Spider 2.0-Snow leaderboard also show that stronger agents, prepared metadata, and specialised workflows can close much of the gap without one prescribed semantic product.[28]

Inference still cannot establish which of several plausible business definitions the organisation has approved. The decisive test is whether the organisation can defend the interpretation; query generation alone does not settle it.

A knowledge graph or ontology is the real AI layer

Ontologies can represent entities and relationships across analytical domains more broadly than a report-oriented semantic model. Fabric IQ itself distinguishes ontology modelling from traditional analytical modelling and can bind ontologies to OneLake sources and Power BI semantic models.[10][11]

This is an extension, not a reason to discard mature measures and dimensions.

A semantic model may remain the best authority for analytical calculations. An ontology can provide a wider business concept layer. Document retrieval can provide policy and narrative context. Reliable systems compose these layers without pretending they are interchangeable.

Semantic layers become bottlenecks

Central definitions can slow experimentation. Ownership queues can become political. A model can freeze one team's interpretation and force every new question through a specialist group.

That is a governance design problem, not an argument for unmanaged definitions.

Useful responses include:

• domain ownership;
• versioned definitions;
• proposed and approved states;
• temporary exploratory metrics;
• clear promotion criteria;
• reusable semantic APIs;
• deprecation rather than silent mutation.

The layer should make disagreement visible without requiring every idea to become enterprise policy.

Semantic models preserve technical debt

Many existing models are duplicated, poorly named, overgrown, or tied to one report. Reusing them without review can scale their defects.

This concern is valid. Existing investment shortens the path only where it contains real semantic work. Report count is not maturity. The AI-readiness assessment should identify which models deserve promotion, consolidation, repair, or retirement.

Vector retrieval makes semantic modelling unnecessary

Vector retrieval can find documents and examples related to a question. It does not, by itself, execute the organisation's approved aggregation or enforce valid joins.

A retrieved document can describe net revenue. A semantic measure can calculate it against current governed data. Many useful applications need both.

Vendor platforms create lock-in

Business definitions embedded in proprietary interfaces can become difficult to move. Platform-specific DAX, LookML, YAML, APIs, and security models are not identical.

Reducing lock-in requires separating:

• business definition;
• physical source;
• platform expression;
• tests;
• ownership;
• consumer contract.

Code-based definitions, catalogues, APIs, and emerging interchange efforts can improve portability. Migration cost should be part of the platform decision.

OneLake's use of Delta Parquet and Iceberg reduces storage-format lock-in, but it does not make DAX measures automatically portable.[2]

AI readiness also depends on organisational practice

Definitions require agreement. Owners must review them. Security teams must test access. Business users must supply real questions. Operators must respond to failures.

The whitepaper's claim is not that Fabric or another platform creates this discipline. It is that organisations with mature semantic practice have already built part of it.

14. Limitations

This paper uses public product documentation and published research available on 31 August 2026. Product names, maturity, configuration, and preview status will change.

Fabric Data Agent evaluation, Prep for AI components, advanced DAX generation, and Fabric IQ include preview capabilities in the cited documentation. Architecture should not be confused with current service-level commitment.

The cross-platform comparison is conceptual. Microsoft semantic models, Snowflake semantic views, Databricks metric views, LookML, and dbt MetricFlow do not have identical features, security semantics, or deployment maturity.

The paper does not measure the cost of creating or maintaining each platform's semantic layer. Existing investment can reduce future work while also carrying technical debt.

The benchmark results describe particular datasets, model versions, tools, and evaluation methods. They demonstrate difficulty in enterprise text-to-SQL; they do not prove that one semantic implementation will reach a particular accuracy level.

The paper focuses on structured analytical consumption. It does not provide a complete architecture for document retrieval, multimodal data, model training, transaction processing, or autonomous action.

It does not claim that a semantic definition is true because it has been approved. Governance improves accountability and consistency. Evidence and review remain necessary.

Conclusion

Generative AI did not create the semantic layer's value. The layer was already solving an enduring enterprise problem: physical data does not carry enough shared business meaning for every consumer to interpret it independently. AI makes the consequences of that gap harder to ignore.

An analyst can notice that two revenue measures disagree. An agent can select one and distribute the answer at scale. A report owner can explain an unusual join. A natural-language interface may hide the join behind a fluent sentence. The easier the interface becomes, the more important the underlying contract becomes.

Microsoft Fabric demonstrates one complete direction. OneLake centralises analytics data. Curated lakehouse and warehouse layers prepare it. Power BI semantic models define measures, dimensions, relationships, and security. Prep for AI focuses the model, adds linguistic context, and anchors priority questions. Fabric Data Agents and Fabric IQ make that meaning available to AI consumers.

Snowflake, Databricks, Looker, and dbt are moving toward the same architectural conclusion through different products. Natural-language analytics needs more than a schema. It needs governed meaning.

Organisations with mature semantic investment are therefore closer to reliable enterprise AI for structured analytical questions. They may already have the hardest assets to recreate:

• agreed vocabulary;
• reviewed metrics;
• entity relationships;
• access boundaries;
• ownership;
• lineage;
• a history of real business questions.

These assets shorten the path without completing it. The semantic layer must be prepared for AI, tested against priority questions, kept current, observed in production, and bounded by deterministic security and action controls. Bad definitions become more dangerous when machines can reuse them easily. Good definitions become more valuable for the same reason.

AI readiness does not begin when a model receives a database credential. It begins when the organisation can state what its data means, who may use it, which questions it can answer, how those answers are tested, and who is accountable when the meaning changes.

Appendix A: AI data-readiness assessment

Use this assessment for one analytical domain, semantic model, or data agent.

# AI data-readiness assessment

Domain:
Platform:
Semantic model or view:
Owner:
Assessment date:
Next review:

## Intended use

Priority questions:
Affected users:
Decisions supported:
Explicitly unsupported questions:
Consequential actions that may consume results:

## Level 0: Raw access

Data sources identified:
Physical schemas discoverable:
Credentials and identities documented:
Direct raw access exposed to AI:

## Level 1: Documented schema

Business-friendly object names:
Descriptions complete:
Relationships complete:
Data types and categories correct:
Ownership recorded:

## Level 2: Governed measures

Priority metrics defined:
Aggregation rules documented:
Grain documented:
Valid dimensions documented:
Conflicting definitions resolved or scoped:
Measure tests:

## Level 3: Access-controlled semantic layer

Effective identity documented:
RLS tests:
OLS tests:
Tenant or workspace isolation tests:
Sensitivity classification:
Lineage coverage:
Version and release process:

## Level 4: AI-prepared semantic layer

Focused AI schema:
Priority synonyms and descriptions:
AI instructions:
Verified answers or queries:
Clarification behaviour:
Unsupported-question behaviour:
Evaluation set:
Regression cases:

## Level 5: Operated AI consumption

Answer-quality monitoring:
Freshness monitoring:
Access-boundary monitoring:
Generated query capture:
Semantic version capture:
Incident triggers:
Correction process:
Rollback:
Support owner:

## Conservative readiness

Meaning coverage: 0 / 0.5 / 1
Source authority: 0 / 0.5 / 1
Access correctness: 0 / 0.5 / 1
Data freshness: 0 / 0.5 / 1
Evaluation coverage: 0 / 0.5 / 1
Operational ownership: 0 / 0.5 / 1

Readiness score: lowest element
Blocking gaps:
Gap owners:
Target dates:
Decision: not ready / limited pilot / production read-only / bounded action

Appendix B: Priority question contract

# Priority question contract

Question ID:
Business question:
Example phrasings:
Decision supported:
Consequence of a wrong answer:
Owner:

## Meaning

Primary business concepts:
Authoritative measure:
Valid dimensions:
Valid grain:
Time and calendar rule:
Known ambiguous terms:
Required clarification:

## Evidence

Systems of record:
Curated source:
Semantic object:
Freshness objective:
Known quality limitations:
Lineage path:

## Access

Allowed roles:
Row scope:
Hidden objects:
Prohibited uses:
Effective query identity:

## Expected interpretation

Expected filters:
Expected query shape:
Expected result shape:
Tolerance:
Verified answer or query:
Unsupported conditions:

## Evaluation

Canonical case:
Paraphrase cases:
Ambiguity cases:
Stale-data case:
Missing-data case:
Access-denied case:
Regression cases:
Last passing run:

## Operations

Semantic-model version:
Review date:
Change trigger:
Monitoring:
Incident owner:
Correction path:

Appendix C: Questions for technical leaders

• Which ten business questions create the most cost when answered slowly or incorrectly?
• Which of those questions already have a governed measure?
• Which semantic models contain duplicated or conflicting definitions?
• Which reports are trusted because of their owner rather than their model?
• Can an operator trace an AI answer to a semantic version and generated query?
• Does effective identity remain correct through every supported agent path?
• How many priority questions have expected-answer tests?
• How quickly do business-definition changes reach semantic models and verified answers?
• Which AI questions require documents or policies outside structured data?
• Where could an answer inform an action that needs deterministic approval?
• Which preview components are in a production dependency path?
• What semantic assets should be consolidated, promoted, or retired before AI access expands?

About the author

Jason Doyle writes about reliable software, observability, incident leadership, applied AI, and practical controls for systems that influence human and organisational decisions. He publishes at jasondoyle.ie.

References

1. Microsoft, What is Microsoft Fabric, Microsoft Learn, updated 31 August 2026, https://learn.microsoft.com/en-us/fabric/fundamentals/microsoft-fabric-overview.
2. Microsoft, OneLake, the unified data lake, Microsoft Learn, updated 31 August 2026, https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview.
3. Microsoft, Power BI Semantic Models, Microsoft Learn, updated 6 July 2026, https://learn.microsoft.com/en-us/fabric/data-warehouse/semantic-models.
4. Microsoft, Direct Lake overview, Microsoft Learn, updated 28 August 2026, https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview.
5. Microsoft, Integrate Direct Lake Security, Microsoft Learn, updated 31 August 2026, https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-security-integration.
6. Microsoft, Semantic model best practices for data agent, Microsoft Learn, updated 11 August 2026, https://learn.microsoft.com/en-us/fabric/data-science/semantic-model-best-practices.
7. Microsoft, Prepare Your Data for AI to Improve Copilot Results, Microsoft Learn, updated 30 May 2026, https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-prepare-data-ai.
8. Microsoft, Prepare your data for AI - Verified answers, Microsoft Learn, updated 30 May 2026, https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-prepare-data-ai-verified-answers.
9. Microsoft, Evaluate your data agent, Microsoft Learn, updated 23 June 2026, https://learn.microsoft.com/en-us/fabric/data-science/evaluate-data-agent.
10. Microsoft, Prepare AI-ready analytics data in Microsoft Fabric, Microsoft Learn training path, updated 1 May 2026, https://learn.microsoft.com/en-us/training/paths/prepare-ai-ready-analytics-data/.
11. Microsoft, Connect agents to Microsoft Fabric with Fabric IQ, Microsoft Learn, updated 24 August 2026, https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/fabric-iq.
12. Microsoft, Lineage in Fabric, Microsoft Learn, updated 4 June 2026, https://learn.microsoft.com/en-us/fabric/governance/lineage.
13. Microsoft, Best practices to optimize Q&A, Microsoft Learn, updated 2 June 2026, https://learn.microsoft.com/en-us/power-bi/natural-language/q-and-a-best-practices.
14. Snowflake, Overview of semantic views, Snowflake Documentation, accessed 31 August 2026, https://docs.snowflake.com/en/user-guide/views-semantic/overview.
15. Snowflake, Cortex Analyst, Snowflake Documentation, accessed 31 August 2026, https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst.
16. Snowflake, Optimize an existing semantic view or model with verified queries, Snowflake Documentation, accessed 31 August 2026, https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst/analyst-optimization.
17. Databricks, Unity Catalog metric views, Databricks Documentation, accessed 31 August 2026, https://docs.databricks.com/aws/en/uc-semantics/metric-views/.
18. Databricks, Agent metadata in metric views, Databricks Documentation, accessed 31 August 2026, https://docs.databricks.com/aws/en/uc-semantics/agent-metadata.
19. Databricks, Genie, Databricks Documentation, accessed 31 August 2026, https://docs.databricks.com/aws/en/genie/.
20. Google Cloud, Conversational Analytics in Looker overview, Google Cloud Documentation, accessed 31 August 2026, https://docs.cloud.google.com/looker/docs/conversational-analytics-overview.
21. Google Cloud, Best practices for configuring Conversational Analytics in Looker, Google Cloud Documentation, accessed 31 August 2026, https://docs.cloud.google.com/looker/docs/conversational-analytics-looker-best-practices.
22. dbt Labs, dbt Semantic Layer, dbt Developer Hub, accessed 31 August 2026, https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl.
23. Fangyu Lei et al., Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows, ICLR 2025 Oral, arXiv:2411.07763, 12 November 2024, https://arxiv.org/abs/2411.07763.
24. Peter Baile Chen et al., BEAVER: An Enterprise Benchmark for Text-to-SQL, arXiv:2409.02038, version 3 updated 13 May 2026, https://arxiv.org/abs/2409.02038.
25. Adithya Bhaskar et al., Benchmarking and Improving Text-to-SQL Generation under Ambiguity, Proceedings of EMNLP 2023, pages 7053-7074, https://doi.org/10.18653/v1/2023.emnlp-main.436.
26. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, 26 January 2023, https://doi.org/10.6028/NIST.AI.100-1.
27. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, 26 July 2024, https://doi.org/10.6028/NIST.AI.600-1.
28. XLang Lab, Spider 2.0 leaderboard, accessed 31 August 2026, https://spider2-sql.github.io/.