The Semantic Layer That Travels With the Data

A business semantic layer is the governed layer of context that records what enterprise data means: metric definitions, business terms, entity relationships, quality rules, lineage, and access policies. For AI and LLM applications, it is what lets an agent interpret your data the way your business does instead of guessing from column names.

Picture a failure that plays out in some version at almost every enterprise running AI agents against live data. An analyst asks the company assistant how net revenue trended through the second quarter. The agent finds the right table, writes clean SQL against the revenue column, and reports a 6 percent decline, a number the CFO repeats in board prep before anyone catches the problem. Finance had recalculated that column in April under a new recognition methodology, moving service contracts from booking-date to delivery-date recognition without restating prior months. The agent compared post-change months against pre-change months and presented the artifact as a trend.

Every technical step in that answer was correct, and the failure sat one level up, in meaning: the definition of the column changed, the change lived in a finance memo and a pipeline commit message, and the agent could see neither. Teams file incidents like this under hallucination, and the label aims the fix at the model even though the model behaved as designed. An agent that answers a business question wrong on clean data is usually guessing, because nobody told it what the data means, so it fills the gap between the data's values and the data's meaning with the most plausible assumption available [10][11].

The established fix is a business semantic layer, and nearly every vendor in the data market now claims to sell one [1][16]. What separates them for AI work is reach: whether the meaning attached to a dataset follows it into a Spark job, a federated query, an S3 read, and an agent's tool call, or stops at the border of the platform where the definition was written. This guide defines the business semantic layer, lays out the measured evidence that agents fail without one, compares where the market's semantic layers live and how far each travels, and describes the architecture that carries context with the data itself. It pairs with our companion guide on getting an enterprise data estate ready for AI, which covers the readiness problem beyond semantics.

What Is a Business Semantic Layer for AI and LLM Applications?

A semantic layer is an independent, governed layer that sits between data sources and the tools that consume them, holding the definitions of the business: what each metric means, which dimensions slice it, which join paths connect the tables, and who may see what [1]. The word business carries real weight in that definition. A schema tells a consumer that a column named net_revenue exists and holds decimals. A business semantic layer tells the consumer which recognition methodology produced it, which contract types it excludes, when the definition last changed, and whether this morning's quality checks passed.

For AI agents, a working semantic layer has to carry at least six kinds of context:

• Definitions. What counts as an active customer, which revenue is net of returns, how churn is calculated. Ask three departments what "active customer" means and you often get three answers, which is exactly the ambiguity agents resolve by inventing criteria [10].

• Relationships. Which entities connect, and through which join paths, so a question about customers and orders resolves the same way every time.

• Lineage. Data lineage is the recorded chain of where a dataset came from and which transformations produced it. Lineage is how a consumer learns that a revenue column was recalculated in April.

• Quality status. Which rules the data passed, and when, so an agent can distinguish a governed number from a stale extract.

• Access policy. Who, and which agent acting for whom, may read each column.

• Freshness and versioning. When the data last updated and which version of a definition applies to which time range.

The market has priced in how much this matters. The segment covering semantic layers and knowledge graphs for agentic AI is worth an estimated $1.07 billion in 2026 and is projected to triple to $3.21 billion by 2031, a 24.6 percent compound growth rate [33], and industry analysts have started describing the semantic layer as the next piece of critical data infrastructure rather than a BI convenience [34]. The urgency comes from failure economics: Gartner predicted in early 2025 that through 2026, organizations would abandon 60 percent of AI projects unsupported by AI-ready data [2], and by its 2026 Data and Analytics Summit the firm was telling attendees to treat context itself as infrastructure, a unified layer connecting business meaning to data so agents can operate reliably [3].

The clearest signal that semantics became an interoperability problem arrived in January 2026, when the Open Semantic Interchange working group published version 1.0 of a vendor-neutral, YAML-based specification for exchanging semantic models, with Snowflake, dbt Labs, Salesforce, BlackRock, and more than 40 other companies behind it [24][25]. DataHub, the open-source metadata platform, joined the effort the same season [26]. When the vendors who each sell a semantic layer agree on a format for moving definitions between platforms, they are conceding the premise of this guide: meaning that stays in one system is worth less than meaning that travels.

Why AI Agents Get Business Questions Wrong Without Semantic Context

The failure mode is measured, and the measurements are consistent: models that look fluent on clean academic schemas collapse on real enterprise data, and the collapse is a context problem rather than a model problem.

Text-to-SQL is the task of translating a natural language question into a database query, and it is the foundation under most "ask your data" features. On Spider 1.0, the long-standing academic benchmark built from clean schemas of 10 to 20 tables, GPT-4-class models reach roughly 86 percent execution accuracy [4]. Each step toward enterprise reality removes a layer of that competence:

The Spider 2.0 result deserves a second look, because it is the same family of models losing 76 points the moment the schemas start resembling yours [4][36]. Enterprise practitioners evaluating these systems have reached the same conclusion from the deployment side: benchmark accuracy on academic datasets tells you almost nothing about whether a natural language interface will survive contact with a production warehouse [35].

Now the counter-evidence, which is what makes this an architecture question. When researchers gave GPT-4 the same enterprise insurance questions with and without a semantic representation of the business, accuracy on the raw SQL schema came in at 16.7 percent, while accuracy over a knowledge graph, a representation of the data as business entities and relationships defined by an ontology, a formal machine-readable model of business concepts, reached 54.2 percent, better than a threefold improvement from context alone [7][9]. A follow-up study added an ontology-based check that validates each generated query against the business model before execution and pushed accuracy above 65 percent [8]. Same model, same questions, same data. The variable was whether anyone had told the system what the data means.

This is why enterprise observability teams increasingly classify agent hallucination on internal data as a context failure rather than a model flaw [10][11]. A model asked about "enterprise customers" with no governed definition available will invent segmentation criteria, and it will do so with the same confident tone it uses when it knows the answer [10]. No benchmark measures the April-methodology-change scenario from the top of this guide directly, but the mechanism is identical: the agent lacked one piece of business context, and the answer failed in a way that looked authoritative.

A Semantic Layer That Stays in One Platform Cannot Cover Your Estate

Where a semantic layer lives sets a hard ceiling on what it can do for agents, because agents do their work across systems. An agent handling a single customer escalation might read the warehouse, check an on-prem policy database, and pull a document from object storage, and it needs the meaning of the data at all three stops. The market's semantic layers were mostly built for a narrower job.

The dbt Semantic Layer defines metrics in YAML files that live inside a dbt project, version-controlled next to the transformations, with the MetricFlow engine compiling metric requests into SQL [12][13]. For keeping BI dashboards consistent, this design earns its adoption, because a metric defined once stops being reimplemented differently in every tool. But the definitions exist at transformation time for analytics consumers. A Spark job reading the lake directly, an agent querying an operational system, and a mainframe extract landing in S3 never pass through MetricFlow, so none of them inherit the definitions.

BI-native semantic models have the same shape with a smaller perimeter. LookML governs dimensions and measures for queries that run through Looker [15], and AtScale, with its OLAP heritage, serves governed metrics to Excel and Power BI over MDX and DAX [14]. Inside the BI boundary, strong; outside it, invisible.

Data catalogs like Alation, Collibra, and Atlan attack the documentation half of the problem: inventorying data across many systems, attaching glossary terms and owners, and mapping lineage [16][17][19]. These are real capabilities, and enterprises get value from them. Two structural limits matter for AI, though. First, catalogs describe data, and enforcement stays in the engines: a Collibra policy is a workflow artifact, and nothing in Trino or Spark checks it at query time [18]. Second, the operational cost is heavy enough that coverage lags the estate; Collibra deployments can take up to a year to stand up [17], and every system added afterward is another connector to configure and curate. A catalog can hold the note that revenue methodology changed in April. It cannot make an agent read the note.

Databricks Unity Catalog is the strongest platform-native answer, one catalog governing tables, files, models, and functions with fine-grained permissions and lineage inside Databricks [20]. Its authority is scoped to the Databricks account and runtime by design [21], so enforcement rides on Databricks compute, and when a user, application, or agent reaches the data through another path, those protections no longer apply [22]. Databricks has been extending outward through open APIs and credential vending so external engines can read Unity-governed tables under short-lived credentials [23], which is real progress, but the extensions govern access to Databricks-managed data. Data that never enters Databricks, which in a typical enterprise includes the mainframe, the on-prem relational estate, and most of the SaaS exhaust, stays outside the envelope.

Context that lives in one platform behaves like a passport valid only inside the country that issued it. The moment your data, or the agent reading it, crosses a system border, the meaning stays behind, and enterprise agent workflows are border crossings by nature.

Which Data Platforms Offer the Best Semantic Layer for Contextualizing Business Data for AI Agents?

Each approach on the market is good in its lane, so the honest comparison is about reach: where definitions live, whether any engine enforces them, and whether an agent receives them at the point of access.

The knowledge graph row deserves a note, because the research behind it is the strongest evidence in this guide [7][8][9]. Ontology-grounded question answering works, and the teams that build such graphs see accuracy triple. The limit is operational: hand-built graphs cover the domain someone modeled, and keeping one synchronized with a moving estate of hundreds of systems is a project that never finishes. The architectural question is how to get knowledge-graph-grade context generated and maintained automatically, across everything, with enforcement attached.

How NexusOne Connects a Business Semantic Layer to Enterprise LLM and Agent Workflows

NexusOne approaches the problem from a different position. It is an AI-native data layer that lays horizontally across the entire estate, connecting on-prem systems, cloud warehouses, mainframes, object storage, and existing platforms like Databricks and Snowflake through one identity model, one governance envelope, and one operational layer. The semantic layer is a property of that horizontal position rather than a product bolted to one platform: every data product carries its lineage, business meaning, quality rules, and access policies with it, and every system and agent that touches the data receives that context, wherever the data physically lives.

The mechanism that makes meaning and enforcement inseparable is a propagation chain that starts in the catalog and ends in every engine. The open-source building blocks exist individually: Apache Ranger supports tag-based policies, where one policy governs every asset carrying a tag instead of thousands of per-resource rules [31][32], DataHub can propagate tags along lineage edges when configured [30], and DataHub ships an integration that lets Ranger control its authorization [29]. What no open-source assembly gives you is the automated wiring between them, and that wiring is the product. In NexusOne, a steward tags a dataset once in DataHub, and the platform's Keycloak-to-DataHub-to-Ranger sync generates the corresponding Ranger policies automatically, at bucket, schema, and table level, then enforces them identically in every engine that can reach the data.

Stage 5 is where the April revenue scenario gets prevented rather than reconstructed after the damage. When the recalculated column ships, the transformation lands in lineage, the methodology tag and glossary version attach to the restated data product, and everything derived from it inherits the change. Stage 6 is what turns that context into agent behavior. NexusOne exposes data products through Model Context Protocol (MCP) endpoints, the open standard Anthropic introduced in late 2024 for connecting agents to tools and data [27], so an agent discovers the revenue data product along with its provenance, its quality status, and the note that the recognition methodology changed in April. Asked the same question, the agent now has what the analyst's best colleague would have: it can answer on a like-for-like basis and say why the raw comparison misleads. Research groups running MCP-based data product marketplaces inside large enterprises report the same pattern, with agents discovering governed data semantically and contracts enforced before queries execute [28].

Building the semantic model in the first place is the part most enterprises dread, and it is where the estate-wide position pays off twice. NexusOne's AI-assisted semantic modeling, driven by CrewAI, classifies data across all connected source systems, including the mainframes and transaction engines that no catalog tool has cataloged, and proposes the mappings, glossary terms, and quality rules that become the governed model. AI-suggested classifications start you at 50 rather than zero, though a steward still reviews them before they become governed truth, and a messy estate takes real curation in the first pass. In production engagements the sequence runs five hours to deploy the layer, five days to connect source systems, and five weeks to a production semantic model spanning the estate. The conviction underneath the whole design, proven out in deployments that include a top-three US bank, is blunt: without a consistent data model, AI does not work, no matter which model you buy.

Agent requests themselves pass through the NexusOne AI & Data Control Plane, so the layer that carries meaning is the same layer that routes, governs, and logs every AI request, with early deployments underway that include a top-ten US bank. Meaning, policy, and enforcement come from one place, which is what keeps them from drifting apart.

How to Enable Natural Language Querying Through a Unified Business Semantic Layer

Natural language querying is a coverage problem before it is a model problem. The benchmark record shows models failing on enterprise schemas without context [4][6] and tripling their accuracy when a semantic model grounds them [7], so the practical question becomes which systems your semantic model spans, because the user's question does not respect system boundaries.

A federated query is a single query that spans multiple systems, executed where the data lives instead of after copying everything to one place. In NexusOne, a natural language question resolves against the estate-wide semantic model, compiles into a governed federated query, and can join the warehouse, an on-prem relational system, and Apache Iceberg tables in object storage in one statement under one policy. The semantic model supplies the join paths and metric definitions, so "net revenue by region, like for like" compiles against the governed definition rather than the model's best guess at your schema. Deterministic questions never touch an LLM at all: the control plane routes them straight to the query engines, which returns the number from the system of record at zero token cost and removes the entire class of errors the text-to-SQL benchmarks measure.

The governance half matters as much as the accuracy half. An analyst's ad hoc question and an agent's automated query run through the same identity model, the same Ranger policies, and the same audit trail, so opening natural language access widens who can ask without widening what anyone can see.

Why Not Just Standardize on One Platform's Catalog?

The strongest objection to estate-wide semantics deserves a straight answer: if the enterprise just consolidated onto Databricks, Unity Catalog would carry the context, so why add a layer?

For an estate that lives entirely inside one platform, that logic holds. A company whose data is all in Databricks-managed storage, whose pipelines run on Databricks compute, and whose agents only ever read Databricks tables should use Unity Catalog and skip the extra layer, and the equivalent is true for a pure-Snowflake shop. The platform catalogs are well built for their own territory [20].

The logic breaks on the estates most large enterprises run. Regulated industries keep core systems on-prem for sovereignty and latency, mainframes still process the transactions that feed everything else, acquisitions arrive with their own warehouses, and multi-cloud is the norm rather than the exception. Against that reality, consolidation is a decade-long program with a moving target, and your AI initiatives are funded this year. Meanwhile the AI workloads themselves are the least consolidated of all, since the whole point of an agent is to work across the systems a human would.

Standardizing on one platform's catalog also concedes a structural point most buyers notice too late: the catalog governs the platform's own territory, so every workload you place elsewhere, for cost, sovereignty, or fit, exits the semantic envelope. An estate-wide layer removes that tax on architectural freedom. And the two approaches compose rather than compete: NexusOne connects Databricks and Snowflake as first-class systems, reads and writes their catalogs through open interfaces, and carries their data products into the same cross-estate context model, so existing platform investments keep their value. With the Open Semantic Interchange specification now published [24][25], definitions written in one tool are becoming portable artifacts, which strengthens the case for a layer whose job is carrying them everywhere.

Put Any Semantic Layer Through This Eight-Question Test

Before you commit to any semantic layer for AI work, including ours, get written answers to these:

1. Do definitions reach every engine that touches the data, including Spark jobs and direct object storage reads, or only queries that pass through a BI or API gateway?

2. Is access policy generated from the same classification that carries the meaning, so enforcement and semantics cannot drift apart?

3. Does context propagate along lineage to derived datasets automatically, or does each downstream table need manual curation [30]?

4. Can it classify and model sources outside the modern stack, including mainframes, transaction engines, and file extracts?

5. Can an agent discover a data product with meaning, lineage, quality status, and policy attached, over an open protocol such as MCP [27]?

6. Does the same identity model govern an agent's access and a human's, on every system either can touch?

7. When a metric definition or methodology changes, does the change reach every consumer of every derived dataset, or only users of one tool?

8. Does natural language querying compile against governed definitions, or against raw schemas the model must interpret alone [7]?

Platform catalogs answer yes inside their own walls, catalogs and metrics layers answer yes for the consumers wired to them, and hand-built knowledge graphs answer yes for the domain someone modeled. If you need all eight across the estate your agents will roam, the semantic layer has to live in the infrastructure layer that connects those systems. To see your own estate's context gaps mapped live, schedule an expert consultation and the team will walk through your architecture with you. The enterprises getting agents into production in 2026 are the ones whose data already explains itself, and that is a property you can start building this quarter.

Frequently Asked Questions

What's the Best Enterprise Data Platform for Building a Business Semantic Layer for AI and LLM Applications?

It depends on the span of your estate. If your data lives entirely in one platform, that platform's native catalog, such as Databricks Unity Catalog, is the practical choice [20]. If your estate spans on-prem systems, mainframes, multiple clouds, and existing warehouse platforms, you need a layer that sits across all of them, because context scoped to one platform is invisible everywhere else [21][22]. NexusOne builds the semantic model across every connected system using AI-assisted classification, enforces it through one Ranger policy model in every engine, and reaches a production semantic model spanning the estate in about five weeks.

Which Data Platforms Offer the Best Semantic Layer for Contextualizing Business Data for AI Agents?

Judge candidates on whether context arrives at the agent's point of access with enforcement attached. Data catalogs like Alation, Collibra, and Atlan document meaning well but do not enforce it in compute engines [17][18], the dbt Semantic Layer defines metrics for analytics consumers wired to its APIs [12], and Unity Catalog contextualizes Databricks-managed data [20][21]. NexusOne attaches business meaning, lineage, quality status, and access policy to each data product and delivers that bundle to any engine or agent that touches the data, across every connected system, which is the property agent workloads need most.

Which Data Platforms Are Best for Connecting a Business Semantic Layer to Enterprise LLM and Agent Workflows?

Look for platforms that expose governed context over open agent protocols rather than proprietary SDKs. NexusOne publishes data products as Model Context Protocol endpoints with full metadata, lineage, and access policy attached [27], so any agent framework can discover what exists and query it under the invoking user's identity, and requests route through the NexusOne AI & Data Control Plane for policy checks and audit. Independent research on MCP-based data marketplaces shows the same architecture pattern holding up inside large enterprises, with contracts enforced before queries run [28].

Best Enterprise Platform for Enabling Natural Language Querying Through a Unified Business Semantic Layer?

The platform matters less than the grounding: research shows GPT-4 jumping from 16.7 percent to 54.2 percent accuracy on enterprise questions when a semantic model provides business context [7], while models without context score as low as 10 percent on realistic enterprise SQL workloads [4]. NexusOne enables natural language querying across the whole estate by compiling questions against its cross-estate semantic model into governed federated queries, spanning warehouses, on-prem systems, and object storage in one statement, with deterministic questions routed straight to query engines at zero token cost and every request governed by the same identity and policy model as human users.

References

1. Cube, "What Is a Semantic Layer?" Cube Blog. https://cube.dev/articles/what-is-a-semantic-layer

2. Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk," Gartner Newsroom, February 2025. https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk

3. Atlan, "Key Takeaways from the Gartner Data and Analytics Summit 2026." https://atlan.com/know/gartner/key-takeaways-from-gartner-da-summit-2026/

4. Lei, F. et al., "Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows," arXiv:2411.07763. https://arxiv.org/abs/2411.07763

5. Li, J. et al., "Can LLM Already Serve as a Database Interface? A Big Bench for Large-Scale Database Grounded Text-to-SQLs (BIRD)," arXiv:2305.03111. https://arxiv.org/abs/2305.03111

6. Chen, P. et al., "BEAVER: An Enterprise Benchmark for Text-to-SQL," arXiv:2409.02038. https://arxiv.org/html/2409.02038v3

7. Sequeda, J., Allemang, D., Jacob, B., "A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model's Accuracy for Question Answering on Enterprise SQL Databases," arXiv:2311.07509. https://arxiv.org/abs/2311.07509

8. Sequeda, J. et al., "Increasing the Accuracy of LLM-Powered Question Answering on SQL," IEEE Data Engineering Bulletin, December 2024. http://sites.computer.org/debull/A24dec/p109.pdf

9. International Institute for Analytics, "Knowledge Graphs Drastically Improve the Accuracy of Large Language Models." https://iianalytics.com/community/blog/knowledge-graphs-improve-accuracy-of-large-language-models

10. Atlan, "AI Agent Hallucination: Causes, Risks and Context Solutions." https://atlan.com/know/ai-agent-hallucination/

11. Glean, "Understanding LLM Hallucinations in Enterprise Applications." https://www.glean.com/perspectives/when-llms-hallucinate-in-enterprise-contexts-and-how-contextual-grounding

12. dbt Labs, "dbt Semantic Layer," dbt Developer Hub. https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl

13. dbt Labs, "How the dbt Semantic Layer Works with MetricFlow." https://www.getdbt.com/blog/how-the-dbt-semantic-layer-works

14. Cube, "Best Semantic Layer for AI and BI in 2026: Shortlist." https://cube.dev/articles/best-semantic-layer-for-ai-and-bi-2026

15. Google Cloud, "What Is LookML?" Looker Documentation. https://cloud.google.com/looker/docs/what-is-lookml

16. Atlan, "Best Semantic Layer Tools for BI and AI Agents: Top Picks 2026." https://atlan.com/know/best-semantic-layer-tools/

17. Atlan, "Alation vs. Collibra vs. Informatica: How to Choose in 2026." https://atlan.com/alation-vs-collibra-vs-informatica-vs-atlan/

18. Promethium, "Data Governance Tools Comparison: Collibra, Alation, Atlan, and Purview Evaluated." https://promethium.ai/guides/data-governance-tools-comparison-collibra-alation-atlan-purview/

19. Alation, "Data Governance Tools: 5 Leading Platforms Compared." https://www.alation.com/blog/data-governance-tools/

20. Databricks, "What Is Unity Catalog?" Databricks Documentation. https://docs.databricks.com/aws/en/data-governance/unity-catalog/

21. Atlan, "5 Unity Catalog Limitations to Overcome in 2026." https://atlan.com/know/databricks-unity-catalog-limitations/

22. TrustLogix, "Databricks Unity Catalog Security: Closing the Access Control Gaps." https://www.trustlogix.ai/blog/beyond-databricks-runtime-enterprise-data-access-control-governance-trustlogix-unity-catalog

23. Databricks, "Expanded Interoperability with Unity Catalog Open APIs," Databricks Blog. https://www.databricks.com/blog/expanded-interoperability-unity-catalog-open-apis

24. Snowflake, "Snowflake, Salesforce, dbt Labs, and More Revolutionize Data Readiness for AI with Open Semantic Interchange Initiative." https://www.snowflake.com/en/news/press-releases/snowflake-salesforce-dbt-labs-and-more-revolutionize-data-readiness-for-ai-with-open-semantic-interchange-initiative/

25. Open Semantic Interchange, "Updates." https://open-semantic-interchange.org/updates/

26. DataHub, "DataHub Joins the Open Semantic Interchange." https://datahub.com/news/datahub-joins-snowflake-open-semantic-interchange/

27. Anthropic, "Introducing the Model Context Protocol." https://www.anthropic.com/news/model-context-protocol

28. arXiv, "Data Product MCP: Chat with Your Enterprise Data," arXiv:2601.08687. https://arxiv.org/abs/2601.08687

29. DataHub, "Configuring Authorization with Apache Ranger," DataHub Documentation. https://docs.datahub.com/docs/1.1.0/how/configuring-authorization-with-apache-ranger

30. DataHub, "Propagating Tags Through Lineage," DataHub Support Portal. https://support.datahub.com/hc/en-us/articles/41912138274587-Propagating-Tags-Through-Lineage

31. Apache Software Foundation, "Tag Based Policy Requirements," Apache Ranger Wiki. https://cwiki.apache.org/confluence/display/RANGER/Tag+based+policy+requirements

32. Cloudera, "Ranger Tag-Based Policies," Cloudera Documentation. https://docs.cloudera.com/runtime/7.3.1/security-ranger-authorization/topics/security-ranger-tag-based-policies.html

33. Mordor Intelligence, "Agentic AI in Semantic Layer and Knowledge Graph Market Size and Growth Trends Report." https://www.mordorintelligence.com/industry-reports/agentic-artificial-intelligence-in-semantic-layer-and-knowledge-graph-market

34. Futurum Group, "Semantic Layer Set to Become the Next Piece of Critical Infrastructure." https://futurumgroup.com/press-release/semantic-layer-set-to-become-the-next-piece-of-critical-infrastructure/

35. Promethium, "Enterprise Text-to-SQL: What Accuracy Benchmarks Really Mean for Your Organization." https://promethium.ai/guides/enterprise-text-to-sql-accuracy-benchmarks-2/

36. Mysore, V., "The Text-to-SQL Performance Cliff (2026): Why Natural Language to SQL Breaks," Medium. https://medium.com/@visrow/the-text-to-sql-performance-cliff-2026-why-natural-language-to-sql-breaks-a7281a23dbea