The Names Were the Guard-Rails: What Early Smart BI Left the AI That Calls It

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

I was asked to look back at the "smart" business intelligence that came before anyone could type a question in English: the data mining models bolted onto warehouses, the exception alerts and "intelligent" dashboards, the first semantic layers. The question offered three waves and asked me to pick the one I knew best. I answered from where my career actually sat, almost entirely in operational support systems and analytical reporting:

In my experience, early ‘AI’ attempts were focused on translating the machine-focused information—metadata, data types, nullability, keys, etc—into human-readable information. This was strongly correlated to early naming conventions and coding standards that were rigorously enforced because they were the only guard-rails present that facilitated the automated output reports.

That is not the history the question expected, and it changes what this piece can be. The usual retrospective on early AI in analytics is a story about discovery: the machine was going to find the pattern nobody had seen, mostly it did not, and now a language model finally will. The work I did and watched was not mostly discovery. It was translation. The database already knew a great deal about itself: what each column held, whether it could be empty, which keys joined which tables. None of that was readable by the people paying for the reports. The "intelligence" was whatever turned the machine's description of its data into something a business person could use, and the thing that made that translation possible was a set of naming rules strict enough that a program could rely on them. My answer did not take up one of the three waves I was offered, the exception alerts and "intelligent" dashboards, and this piece does not either.

Some of that wave was retired outright, and I will come to what. Most of it was absorbed into the products we use now, and the AI being sold into business intelligence today is built on top of it. That is worth knowing before you buy the next layer.

The machine described itself; somebody had to translate

Every relational database carries a catalogue of itself: tables, columns, data types, whether a column may be null, which keys point where. That catalogue is precise and complete, and to anyone outside the team that built the schema it is close to useless. A column called CUST_ACQ_DT of type DATE, not nullable, tells a program everything it needs and tells a sales director almost nothing.

The first automation in reporting worked from that catalogue. A generator could read the column list and produce a report layout, a load routine or a query, provided it could tell from the name what each column was. That is where the naming conventions came from, and why they were enforced the way they were. The international standard for naming data elements, ISO/IEC 11179-5, first published in 1995, set out "rules and guidelines for naming and identification of data elements", and it was explicit about their status: "Rules are mandatory and testable for compliance" [1]. It specified that each context should have a naming convention, "usually a set of rules", governing which words could appear in a name, in what order, from what controlled list [1]. Its "representation term", "a component of a data element name which describes the form of representation of the data element" [1], is the class word commonly written as a suffix: the _DT, _AMT, _QTY, _NM on the end of a column.

In practice, testability was the point: a rule a program can test is a rule a program can rely on. If every date column ends in _DT and every amount in _AMT, a generator can format, total and label them without a person telling it which is which. Break the convention once and the generated report quietly does the wrong thing. That is why the standards were policed so hard in the shops I worked in. They were not style. They were the only guard-rail the automation could use, and what stood between it and a wrong number on somebody's desk.

Rules engines and metadata-driven processing, where a pipeline's behaviour is read from tables of rules and metadata rather than written into its code, were my niche for more than a decade. I have written about what that looked like on the governance side in Same Work, New Tools. On the reporting side the dependence ran the same way: everything the engine produced was only as good as the names and metadata it was handed. A good deal of what we built in that era was what the practice later learned to call layered warehouse design, built that way before the labels existed, because nothing else served the business as well.

The first semantic layers were the same translation, made into a product. In 1991 Bernard Liautaud, a co-founder of Business Objects, and Jean-Michel Cambot filed the patent that became US 5,555,403, granted in 1996. Its first sentence describes a system that "allows information system end users to access (query) relational databases without knowing the relational structure or the structure query language (SQL)" [2]. The problem it names is the one I have been describing: "Querying a relational database implies a good knowledge of Structured Query Language (SQL) and a good understanding of relational data structures" [2]. And its answer is translation, stated plainly: "Instead of presenting a user with data organized in a computer-oriented way (columns, rows, tables, joins), the user sees information through terms that he is familiar with in his daily business" [2]. Those terms were "business objects", and a set of them for a group of users sharing a vocabulary was "a universe" [2].

Notice what the universe did not do. It did not infer the business meaning of a column. A designer wrote it, object by object, from the schema and from whatever the naming convention made legible. The intelligence was in the mapping, and the mapping was built by hand on top of the names. What a semantic layer does today, and where it breaks, I covered in What the Model Cannot Infer: it sits between the agent and the data, and it fails when it is incomplete, wrong or configured improperly. This piece is about its ancestor, and the ancestor's lesson is that the layer was never smarter than the names beneath it and the person who wrote it.

Built to de-skill

A disclosure first, because this section judges products, with the direction of each interest. The practice behind this publication is a Profisee partner with a referral agreement, and its services revenue depends on business intelligence and master data software being bought at all, so weigh anything favourable I say about Profisee or the category below my criticism of it. Microsoft is a vendor Profisee is aligned with, since Profisee markets itself as a native workload in Microsoft Fabric, so weigh praise of Power BI and Fabric the same way. This publication is also drafted with the help of Anthropic's model, whose documentation I cite later as a record of what it runs, so weigh my praise of AI tools down accordingly.

The translation layer was the start. The ambition was larger:

Rules engines, dynamically generated code, recursive scoping and low-code/no-code interfaces were developed—at great effort—to democratize and de-skill the Business Intelligence world. To a certain degree, they worked and the tangible proof of that is products like Profisee, PowerBI, and Fabric.

"De-skill" is my word and I meant it. The goal was to let people who could not write SQL, could not read a schema and would never learn a load tool get the reports they needed without waiting on someone who could. That is democratisation described from the supply side. It took a great deal of engineering, and most of it was generation of one kind or another: code written by programs from metadata.

The clearest surviving record of that style in the Microsoft stack is Biml, the Business Intelligence Markup Language, which its maker describes as "an XML dialect that describes Microsoft Business Intelligence assets: SSIS packages, SSAS dimensions and cubes, and supporting database objects" [3]. The interesting part is the script around it: "The script can read external metadata, loop over rows, evaluate expressions, and emit further Biml. That is what turns a static markup language into a generator" [3]. Its own justification is the standard one: "Most enterprise SSIS portfolios contain repetitive packages", and "Once a pattern is in BimlScript, scaling it is a matter of adding rows to the metadata, not files to the project" [3]. Adding rows to the metadata works only if the rows mean what the generator assumes they mean, which brings us back to the names. Biml's own worked examples carry prefixed object names, and the generated packages carry them through [3]. A generator that loops over metadata can only be as regular as the names it loops over.

I named Profisee, Power BI and Fabric as the tangible proof that the de-skilling effort worked to a certain degree, and I stand by both halves of that sentence. When Microsoft announced in 2015 that Power BI would be "generally available July 24th", it described the desktop tool as "a free-form canvas for drag-and-drop exploration of your data" [4]. By Microsoft's own account, written more than eight years later, the product "has empowered self-service business analysts to discover insights quickly and easily without a dependency on IT" [5]. In late 2023 Microsoft renamed the Power BI dataset to the "semantic model", because, in its words, "the term semantic model better reflects the rich functionality of Analysis Services data models, upon which Power BI reports are based" [5]. That rename is the idea in one line. Microsoft traces the semantic model to its own Analysis Services, not to Business Objects, but the idea the 1991 patent described, a business-term layer over the schema, is now the named foundation of the product, and the self-service user it was built for is now the product's main audience. Profisee belongs on the list for the master data side of the same story: matching, stewardship and rules that once had to be hand-built are configured in a packaged product. The products exist, and they are used. That is the "worked".

The "to a certain degree" is the part a buyer should not skip, and the record on it is not kind. In 2008 TDWI Research reported that "more than 90% of all organizations have spreadmarts", which it defined as "data shadow systems in which individuals collect and massage data on an ongoing basis to support their information requirements or those of their immediate workgroup" [6]. One of its interviewees described "the classic situation of two people presenting ostensibly the same data at a board meeting with different figures, which they got from different spreadmarts" [6]. In 2015 Gartner predicted that "through 2016, less than 10 percent of self-service BI initiatives will be governed sufficiently to prevent inconsistencies that adversely affect the business", and named the result "analytic sprawl — an inconsistent or incomplete use of data, capricious development of metrics and formulae, and either too-restrained or unrestrained sharing of results" [7]. That was a prediction, not a measurement, but Microsoft's own adoption guidance for Fabric reads like its confirmation. Roll out the tools first and govern later, it says of one approach, and "a governance effort begins, usually to bring order to an unacceptable level of chaos since the self-service user population didn't receive sufficient guidance"; the challenges it lists include "Sprawl of data and reports" and "Inconsistent reports produced without sufficient data validation" [8].

Read together, those sources do not say the de-skilling failed. I read them as saying it worked exactly as far as the guard-rails went with it; they document the failures, not the successes, so the positive half is my reading. Where the names, the standards and the governed meaning travelled with the tool, people who could not write SQL got reliable answers. Where the tool travelled alone, they got fast answers that disagreed with each other. That distinction is the whole of my "to a certain degree", and it is the distinction the next wave is about to be tested on.

What did not carry over

Before going further I should be fair to the question I was asked, because not everything from the earlier wave was absorbed. Some of it was retired.

The data mining models bolted onto the warehouse are the clearest case, and the one I can speak to only from the record:

I did no explicit data mining, so I can't speak to that.

The record is clear enough. Microsoft put data mining inside its business intelligence server with SQL Server 2000 and said so proudly: "SQL Server has been a leader in predictive analytics since the 2000 release, by providing data mining in SQL Server Analysis Services", and "Integrating data mining into business intelligence solution helps you make intelligent decisions about complex problems" [9]. That was real statistical learning, not translation: the product shipped decision trees, clustering, neural networks and time series among its algorithms [9]. It is also gone. The same page now opens with a notice: "Data mining was deprecated in SQL Server 2017 Analysis Services and now discontinued in SQL Server 2022 Analysis Services" [9]. The discovery feature built into the BI server did not become a feature of its successor. People who still do that work do it elsewhere, in general-purpose tools.

The earlier natural-language feature is going the same way. Power BI's Q&A, which let users type a question against a model and which I would count among the last of the pre-language-model attempts, is being retired: "We are announcing the deprecation of Q&A, our legacy natural language tool, which will take place in December 2026", with users pointed instead to "Power BI Copilot, which provides a more advanced and integrated solution for querying your data with natural language" [10]. The longer history of asking a database a question in English, from 1971 on, I told in The Vocabulary Outlived the Interface; I will not retell it here.

So "absorbed, not replaced" needs narrowing, and here is the narrowing. At the level of features, the earlier wave was frequently replaced: the mining engine discontinued, the natural-language box swapped for a copilot. At the level of what those features ran on, the earlier wave was inherited almost whole: the semantic model, the names in it, the descriptions and the governed meaning behind them, and, as the next section shows, the libraries. The features were the part vendors marketed. The foundations were the part that survived.

The libraries the AI still calls

The third thing I said in my answer is the one most open to checking, so I will put it here and then check it:

Automated and systematized data analytics libraries have found great success in rapidly identifying and classifying large incoming data sets—they’ve had so much success that they’re still the tools AIs pick when asked to perform those analyses.

The libraries that fit that description, and the ones today's AI tools document, are the general-purpose ones that turned statistical analysis into a few lines of code, rather than the mining engine inside a BI server. Their own founding papers date them. pandas was described in June 2010 as "a new library which aims to facilitate working with these data sets and to provide a set of fundamental building blocks for implementing statistical models" [11]. scikit-learn was published in 2011 as "a Python module integrating a wide range of state-of-the-art machine learning algorithms for medium-scale supervised and unsupervised problems", with a stated aim that fits this piece exactly: "bringing machine learning to non-specialists using a general-purpose high-level language" [12]. That is the de-skilling ambition again, carried out of the BI server and into a library anyone could install.

Now the check. Do today's AI assistants analyse data themselves, or do they call those libraries? Their makers' documentation answers that directly. OpenAI says that "for some data-analysis tasks, ChatGPT writes and runs Python code in a stateful Jupyter notebook environment", and that the environment "can display pandas DataFrames as interactive tables" [13]. Anthropic's documentation for its code execution tool lists what it pre-installs for the model: "Data science: pandas, numpy, scipy, scikit-learn, statsmodels" and "Visualization: matplotlib, seaborn" [14]. The research community measures the same thing the same way: DS-1000, a code-generation benchmark presented at ICML in 2023, tests models on "a thousand data science problems spanning seven Python libraries, such as NumPy and Pandas", collected from real StackOverflow questions [15]. That benchmark measures fluency in those libraries by construction, so it cannot show that the libraries deserve to win. What it shows is that one of the field's main yardsticks measures an AI's ability to analyse data as its ability to write code against those libraries.

One precision belongs here, so that the claim is not stronger than its evidence. Part of the reason the assistants call these libraries is that their makers put the libraries in the sandbox. That is a choice, but it is not an arbitrary one: for classifying tabular data, a benchmark study in 2022 found that "tree-based models remain state-of-the-art on medium-sized data (~10K samples) even without accounting for their superior speed" [16], and those models are what the libraries provide.

The counter-evidence is real, and it is worth knowing where it points. Language models can classify table rows directly: TabLLM serialised rows into text and found that "even zero-shot classification obtains non-trivial performance", competitive with gradient-boosted trees "especially in the very-few-shot setting" [17]. ChatGPT, given instructions, a two-step prompt and no training, annotated what each column of a table contained at "F1 scores of over 85%" [18], which is exactly the job naming conventions used to do for a generator. And a tabular foundation model reported in Nature in 2025 "outperforms all previous methods on datasets with up to 10,000 samples by a wide margin", in a paper that concedes in the same breath that "gradient-boosted decision trees have dominated tabular data for the past 20 years" [19]. Every one of those results is on small data, few labels, or column typing. None shows a language model displacing the libraries on the large incoming data sets my answer was about. So I would put it this way. On large data the libraries are still the tool and the AI is still calling them; that is my judgement rather than a measured finding, because nothing I found tests it either way. On small data the field is moving, so check again in a year.

The guard-rail, measured

The part of my answer that matters most for anyone buying AI for analytics today is the first part: the names were the guard-rails. If that was true of the generators, is it still true of the model?

The best current evidence says yes, with a qualification. A study presented at SIGMOD in 2025, SNAILS, measured how the naturalness of table and column names affects language models writing SQL across several databases and models from OpenAI, Meta and Google. Its finding is simple: "We find that generally more natural database schemas yield more correct queries" [20]. Identifier naturalness was "moderately and positively correlated with both schema linking and execution accuracy", and the worst damage to schema linking came from the lowest tier, names whose "meaning cannot be inferred by non-experts due to indecipherable acronyms or abbreviations" [20]. The authors' advice could have come from a 1995 naming standard: "Avoid obscure acronyms and abbreviations" [20]. Those abbreviations are not rare. An EMNLP 2023 paper on expanding column names calls them "pervasive", and says they "can negatively impact performance on various data search, access, and understanding tasks" [21]. A separate study had language models write column descriptions: adding those descriptions "consistently enhances text-to-SQL model performance", but the models writing them "struggle with columns that exhibit inherent ambiguity, highlighting the need for manual expert input" [22].

The vendor of the products I named says the same thing in its product guidance. Microsoft's page on preparing a semantic model for Copilot tells you to "make column names unambiguous and self-explanatory", to "avoid IDs or codes that require further lookup without context", and to give measures "names that clearly reflect their calculation and purpose"; its examples of what to rename, ProdID, CustNo, AvgRating, are the abbreviations a naming standard existed to forbid [23]. It adds a detail I would underline for anyone writing the descriptions: "Copilot uses only the first 200 characters" [23]. The Fabric guidance for its data agent goes a step further, and in the right direction: names such as CustomerOrders and order_submission_date "give the agent more useful signals than names such as Table1, date1, and value", but "Don't rely on naming alone. Even a clear technical name might not communicate the object's business meaning, level of detail, units, or valid values" [24].

Now the qualification, because the strongest counter-evidence I found is about exactly this. A robustness study published in 2023, Dr.Spider, perturbed questions and database schemas, including abbreviating column names. It found that "even the most robust model suffers from a 14.0% performance drop overall" [25]. But in its results tables, an in-context language model lost far less to abbreviated names than the fine-tuned model of the previous generation did. The database change that hurt most was not renaming at all. It was the same meaning stored as different values [25]. SNAILS agrees that the strongest current models are the least sensitive to naming differences between ordinary and somewhat cryptic names [20]. The models have got better at guessing what a bad name means.

So here is where I land, and it is a narrowing of my own first answer rather than a retreat from it. For the generators I built, the names were the only guard-rail, because the program could read meaning nowhere else. For a language model, the name matters less than it did and still matters, and what matters more is the meaning behind the name: what the column is for, what unit it is in, which values are valid, whether two systems that hold "the same" field hold the same thing. The guard-rail has moved from the name to the governed meaning the name used to stand in for. What I cannot tell you is whether that last step holds as the models improve. Their sensitivity to bad names has already fallen; tests of descriptions present against descriptions absent, such as the column-description study above, show that today's models still benefit from them. Whether that need falls across model generations, as the sensitivity to names did, is the open question, and I found no study that tracks it.

That is the same distinction the self-service wave drew. Where meaning travelled with the tool, the tool worked. Where it did not, the board saw two numbers.

What I would take from it

The earlier wave of smart BI was not a failed attempt that AI has now got right. Its discovery features were mostly retired, and they were never the point. Its translation layer and its de-skilling tools worked to a certain degree and became the products the industry runs on; its ambition to put analysis in anyone's hands passed to general-purpose libraries. Both are now the ground today's AI stands on. A language model in Power BI reads the semantic model. A language model analysing a file writes pandas. Neither one replaced what came before; each one calls it.

That gives a buyer three practical things to do before the next demonstration.

First, audit the names and the descriptions before you switch on the copilot. Microsoft's own guidance amounts to a naming standard and a data dictionary with a 200-character limit. If your models carry CustNo and an empty description field, the AI will guess, and the research says it guesses better than the old generators did, which is not the same as guessing right.

Second, treat the semantic model as the product and the AI as a client of it. The universe in 1991 was written by a person who knew the business; nothing in the present evidence says that job has gone away. Where a column is genuinely ambiguous, the description study's phrase is the right one: it needs "manual expert input" [22].

Third, when a vendor tells you what their AI can find in your data, ask what it reads and what it calls. If the answer is the names in your model and the libraries in its sandbox, then the quality of what it finds depends on work your organisation does, not only on the model, and that work is the same work the naming standards were enforcing thirty years ago.

The names were the guard-rails because they were all the machine could read. The machine can read more now. It still reads them, and it still needs the meaning behind them.

References

[1] ISO/IEC JTC 1, "ISO/IEC 11179-5:1995 Information technology — Specification and standardization of data elements — Part 5: Naming and identification principles for data elements," first edition, 1995-12-01. Read 2026-11-04 from the publisher's free preview sample (front matter and Clauses 1 to 6.1.1.3 only; the remainder was not read). https://cdn.standards.iteh.ai/samples/1758/5c4568bb1a8f4583966d5826b128d8cf/ISO-IEC-11179-5-1995.pdf

[2] Jean-Michel Cambot and Bernard Liautaud, "Relational database access system using semantically dynamic objects," US Patent 5,555,403, filed 1991-11-27, granted 1996-09-10. Abstract, background and description read 2026-11-04; the claims were not read. https://patents.google.com/patent/US5555403A/en

[3] Varigence, "Why Biml: An Introduction," Biml documentation, undated. Read 2026-11-04. https://docs.varigence.com/bimlscript/walkthroughs/the-why-of-biml/

[4] Microsoft, "Announcing Power BI general availability coming July 24th," Power BI Blog, 2015 (the migrated page shows "11 years ago" and no date). The opening and the Power BI Desktop section read 2026-11-04. https://community.fabric.microsoft.com/blog/fbc_pbiupdatesblog/announcing-power-bi-general-availability-coming-july-24th/5175677

[5] Microsoft, "Datasets renamed to semantic models," Power BI Updates Blog (opening paragraphs read), and "Rename of Power BI datasets to semantic models," Microsoft Learn (opening section read). Read 2026-11-04. https://community.fabric.microsoft.com/blog/fbc_pbiupdatesblog/datasets-renamed-to-semantic-models/5174619 and https://learn.microsoft.com/en-us/power-bi/connect-data/service-datasets-rename

[6] Wayne W. Eckerson and Richard P. Sherman, "Strategies for Managing Spreadmarts," TDWI, 27 May 2008. Read 2026-11-04. https://tdwi.org/articles/2008/05/27/strategies-for-managing-spreadmarts

[7] Gartner, "Gartner Says Power Shift in Business Intelligence and Analytics Will Fuel Disruption," press release, 27 January 2015. Read 2026-11-04. https://www.gartner.com/en/newsroom/press-releases/2015-01-27-gartner-says-power-shift-in-business-intelligence-and-analytics-will-fuel-disruption

[8] Microsoft, "Fabric adoption roadmap: Governance," Microsoft Learn. The governance-timing and challenges sections read 2026-11-04. https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-governance

[9] Microsoft, "Data Mining (SSAS)" and "Data Mining Algorithms (Analysis Services - Data Mining)," Microsoft Learn. The notice, introduction and algorithm list read 2026-11-04. https://learn.microsoft.com/en-us/analysis-services/data-mining/data-mining-ssas and https://learn.microsoft.com/en-us/analysis-services/data-mining/data-mining-algorithms-analysis-services-data-mining

[10] Microsoft, "Deprecating Power BI Q&A," Power BI Updates Blog, announced December 2025 (per the page's own timeline; the post carries no date). The opening and rationale read 2026-11-04. https://community.fabric.microsoft.com/blog/fbc_pbiupdatesblog/deprecating-power-bi-qa/5173970

[11] Wes McKinney, "Data Structures for Statistical Computing in Python," Proceedings of the 9th Python in Science Conference (SciPy 2010), 28 June 2010. The abstract read 2026-11-04; the paper's body was not read. https://proceedings.scipy.org/articles/Majora-92bf1922-00a

[12] Fabian Pedregosa, Gaël Varoquaux, Alexandre Gramfort et al., "Scikit-learn: Machine Learning in Python," Journal of Machine Learning Research 12, 2011, pp. 2825–2830. The abstract read 2026-11-04; the paper's body was not read. https://jmlr.org/papers/v12/pedregosa11a.html

[13] OpenAI, "Data analysis with ChatGPT," OpenAI Help Center, updated October 2026. Read 2026-11-04. https://help.openai.com/en/articles/8437071-data-analysis-with-chatgpt

[14] Anthropic, "Code execution tool," Claude Platform documentation. Read 2026-11-04. https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool

[15] Yuhang Lai, Chengxi Li, Yiming Wang et al., "DS-1000: A Natural and Reliable Benchmark for Data Science Code Generation," Proceedings of the 40th International Conference on Machine Learning (ICML 2023), PMLR 202, pp. 18319–18345. The abstract read 2026-11-04; the paper's body was not read. https://arxiv.org/abs/2211.11501

[16] Léo Grinsztajn, Edouard Oyallon and Gaël Varoquaux, "Why do tree-based models still outperform deep learning on tabular data?," 2022. The abstract read 2026-11-04; the paper's body was not read. https://arxiv.org/abs/2207.08815

[17] Stefan Hegselmann, Alejandro Buendia, Hunter Lang, Monica Agrawal, Xiaoyi Jiang and David Sontag, "TabLLM: Few-shot Classification of Tabular Data with Large Language Models," 2022 (revised 2023). The abstract read 2026-11-04; the paper's body was not read. https://arxiv.org/abs/2210.10723

[18] Keti Korini and Christian Bizer, "Column Type Annotation using ChatGPT," 2023. The abstract read 2026-11-04; the paper's body was not read. https://arxiv.org/abs/2306.00745

[19] Noah Hollmann, Samuel Müller, Lennart Purucker, Arjun Krishnakumar et al., "Accurate predictions on small data with a tabular foundation model," Nature, January 2025. The abstract read 2026-11-04; the paper's body was not read. https://www.nature.com/articles/s41586-024-08328-6

[20] Kyle Luoma and Arun Kumar, "SNAILS: Schema Naming Assessments for Improved LLM-Based SQL Inference," Proceedings of the ACM on Management of Data 3(1), Article 77 (SIGMOD 2025), February 2025. The abstract and findings read 2026-11-04 from the authors' PDF, with the authors' blog post read in full; the ACM page was not read. https://adalabucsd.github.io/papers/2025_SNAILS_SIGMOD.pdf and https://adalabucsd.github.io/research-blog/snails.html

[21] Jiani Zhang, Zhengyuan Shen, Balasubramaniam Srinivasan, Shen Wang, Huzefa Rangwala and George Karypis, "NameGuess: Column Name Expansion for Tabular Data," EMNLP 2023. The abstract read 2026-11-04; the paper's body was not read. https://arxiv.org/abs/2310.13196

[22] Niklas Wretblad, Oskar Holmström, Erik Larsson et al., "Synthetic SQL Column Descriptions and Their Impact on Text-to-SQL Performance," 2024. The abstract read 2026-11-04; the paper's body was not read. https://arxiv.org/abs/2408.04691

[23] Microsoft, "Optimize your semantic model for Copilot in Power BI," Microsoft Learn, updated 29 September 2026. The introduction and guidance tables read 2026-11-04. https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-evaluate-data

[24] Microsoft, "Best practices for improving data agent query generation," Microsoft Fabric documentation, Microsoft Learn, updated 28 August 2026. The naming and description guidance read 2026-11-04. https://learn.microsoft.com/en-us/fabric/data-science/data-agent-configuration-best-practices

[25] Shuaichen Chang et al., "Dr.Spider: A Diagnostic Evaluation Benchmark towards Text-to-SQL Robustness," ICLR 2023. The abstract and results read 2026-11-04. https://arxiv.org/abs/2301.08881