The Vocabulary Outlived the Interface: Fifty Years of Asking the Data a Question

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

Every platform I have watched replaced

I have watched a lot of reporting platforms get switched off. At least half of the projects I have worked on involved moving a business off a platform that was being decommissioned, and every one of those moves stopped reports and data loads that somebody, once, had needed. A data strategy was generally not the reason. The platform went because of a reorganisation, an acquisition or a new CIO — and, more often than all three of those put together, because the licence cost too much or the software was going out of support.

Asked whether a data strategy had been what retired those systems, I said it generally had not, and then added the part that bears on this piece:

With that said, I have seen a number of realignments from one reporting platform to another—Crystal Reports to PowerBI to SAP to Oracle—and every project that’s spearheaded the migration has had a comprehensive reporting review that decommissioned dozens if not hundreds of reports and their associated back-end data models.

Read that as a statement about what survives. Dozens, sometimes hundreds, of reports did not survive each of those moves, and neither did the back-end models built to feed them. The interface was replaced on a schedule set by licensing and reorganisation, not by anyone's judgement about the data, and each replacement was the moment the estate found out how much of what it had built it was prepared to switch off.

That is the lens I want to put on the early attempts to put artificial intelligence in front of business data, because they have now been through the same cycle often enough to have a record. For fifty years, one generation after another has promised that a person could ask the data a question in their own words and get an answer back without knowing how the data was built. The promise has been made by a research laboratory, by the inventor of the relational model, by Microsoft twice and by Tableau. Each of those interfaces ended as a research prototype or a discontinued feature, or, in the case of Microsoft's second attempt, is being retired now.

Here is the claim I will defend. What killed them was never mainly the parsing of English. It was the vocabulary: the business's own words for its own data, which each interface needed somebody to write down before it could answer anything, and which no interface removed the need for. The interfaces were consumables. The vocabulary was the asset. For a master data or analytics programme about to buy the current generation, that is the lesson worth taking, and it is a narrower and more practical one than either the vendors or the sceptics usually offer.

Seventy-eight percent in 1971

Start where the record starts, because it is better than its reputation.

In 1971 a team at Bolt Beranek and Newman demonstrated a preliminary version of LUNAR, a system built to let lunar geologists ask English questions of the chemical analyses of the rocks brought back from the Moon [1][4]. The results were reported by the system's designer, William Woods, six years later: "78 percent of the questions asked of the system were understood and answered correctly, and another 12 percent failed due to trivial clerical errors such as dictionary coding errors in the not fully-debugged system" [1]. Only about one question in ten failed for reasons that had to do with understanding the English [1].

That is a remarkable number for a machine built half a century before anyone had heard of a large language model, and Woods was careful about what it covered. The questions were restricted to what the database actually held, comparatives were excluded because the system could not yet handle them, and beyond that the requests were typed in "exactly as they were asked" [1]. Behind the grammar sat "a dictionary of approximately 3500 words" and a table of chemical analyses with 13,000 entries [1].

Hold on to the dictionary, because it is the part of LUNAR that every later system reinvented. Somebody had to sit down and write out what a geologist meant by each word the geologist might use, and connect every one of those words to the columns that held the answer. The system understood English about as well as its builders had described the geology. And it could only ever talk about that one database: the standard survey of the field, written in 1995, says that LUNAR and its contemporaries "were each built having a particular database in mind, and thus could not be easily modified to be used with different databases" [4].

So the first honest result in this field is not a failure. It is a success whose cost was hidden in a word list.

The casual user was offered English twice

By 1974 the idea had reached the people who built the databases themselves. E. F. Codd, who had invented the relational model, argued that "if we are to satisfy the needs of casual users of databases, we must break the barriers that presently prevent these users from freely employing their native language", and he built a prototype called Rendezvous that would hold a clarifying dialogue with a user who knew nothing about database systems and very little about the database in front of them [2].

In the same years, also at IBM, Donald Chamberlin and Raymond Boyce designed a query language for the same audience — a structured English, not a free one. Chamberlin later wrote that they expected its main use to be "ad-hoc queries by planners and other professionals whose domain of expertise was not primarily database management", in a language "simple enough that ordinary people could 'walk up and use it' with a minimum of training" [3]. The language became SQL. And nearly forty years on, its co-designer was candid about where it actually went: "I have been surprised to see that SQL is more frequently used by trained database specialists to implement repetitive transactions such as bank deposits, credit card purchases, and online auctions", and it "has not proved to be as accessible to untrained users as Ray and I originally hoped" [3].

That is the first time the casual user was offered English, and by its co-designer's own account it did not reach them as he had hoped. Chamberlin is describing transactions, not analysts, so the analysts' side of this rests on my record rather than his. Asked why a conversational interface to the data struggles to find users among analysts, I gave two reasons. The first was temperament. The second was this:

Further, they are already sufficiently knowledgeable that they are already having those conversations in SQL, Python or R. Even the less technical tend to talk with Excel or Power BI.

Put that beside Chamberlin and the two halves fit. The language designed to be English for the casual user did not reach the casual user as he had hoped, and the people who do ask the data questions all day already hold that conversation in a formal language of their own, or in a spreadsheet. Every generation of question box since has been competing not with silence but with SQL, with a spreadsheet, and with the report somebody already built for themselves.

I have made the economic half of this argument before — why these pilots cost too much for what they deliver, and why they tend to fail by succeeding: everyone is pleased and nobody can defend the cost per answer (The Number Was Never Doing the Work). I will not rerun it. The point here is narrower. The population that asks the most questions of the data has had a formal interface of its own since before most of the products in this piece were conceived, and a new one has to do something that interface cannot.

The 1995 survey reached a similar verdict from the other side. Natural-language interfaces to databases, it said, "did not gain the expected rapid and wide commercial acceptance", and it named two reasons: the development of successful alternatives, "like graphical and form-based interfaces", and the intrinsic problems of the natural-language systems themselves [4]. Among those intrinsic problems it listed that "the system's linguistic capabilities are not obvious to the user", that users "assume that the system is intelligent, that it has common sense", and that such systems "usually require tedious and lengthy configuration phases before they can be used" [4].

The last of those is the one this piece is about.

The configuration phase nobody budgeted

A disclosure first, because this section assesses vendors' products. The practice behind this publication is a Profisee partner and holds a referral agreement with Profisee. Clients pay us for deployment work, and a licence sale we refer earns us a referral fee from the vendor. Beyond both, our services revenue depends on data management and analytics software being bought at all, so what I say about these products is said by people with a stake in the category. None of the products I examine below is Profisee's, and none of them competes with it: they are analytics tools, not master data management. Our stake in them runs toward wanting analytics software bought and used, which inclines us to optimism about this category rather than against it. Between the two vendors the stake is not neutral either: Profisee is closely aligned with Microsoft, and markets itself as a native workload inside Microsoft Fabric [21], so weigh what I say in Microsoft's favour below with that in mind. Weigh my criticisms above any praise.

The commercial generations followed the research ones, and each arrived promising that the configuration phase had been engineered away.

Microsoft's English Query shipped with SQL Server 2000 [6]. It turned an English question — the example in the trade press was "How many orders in March were for more than 500 dollars?" — into SQL, and to make that work somebody had to map the nouns and verbs of the business onto the tables of the database by hand [5]. The authoring guidance of the day reads like a data-modelling project, because it was one: collect the questions users want answered, sort them, build a semantic model of them, map it to the physical tables, and only then lay the structure out in the tool [6]. Then, in the next major release, the documentation said in its entirety: "English Query has been discontinued in this release. It cannot be installed or upgraded" [7]. Microsoft offered no reason [5].

Eight years after English Query was discontinued, Microsoft tried again. Q&A arrived with Power BI for Office 365 in 2013, and the company described it in the terms of its search engine: "we looked at how consumers experienced Bing search and used that knowledge to enable customers to query their enterprise data" [8]. Q&A lasted more than a decade. It also accumulated what its own documentation called Q&A Setup, "a suite of tools aimed at helping report authors improve the Q&A experience" — synonyms, phrasings and the rest of what a model needed to be told about a business's words [9]. In December 2025 Microsoft announced the retirement of both, to "reduce confusion between overlapping features" and to "accelerate innovation and delivery of new and modern AI capabilities" [9]. The date has since moved to February 2027, when "existing reports that contain Q&A visuals will display an error in place of the visual" [10].

Tableau's version was the most candid. Ask Data launched in February 2019 with the promise that there was "no need to have a deep understanding of the data structure or programming skills" [11]. Five years later Tableau retired it, from Tableau Cloud at version 2024.1 and from Tableau Server at 2024.2, and gave as one reason that customers found it "isn't 'natural' enough": "you still have to understand some fundamental data concepts, field names, keywords, and general analytical concepts" [12]. Tableau's own before-and-after is the clearest statement of the pattern I know. The launch said the data's structure would stop mattering to the person asking. The retirement said it had not.

None of this means the question box failed as a business. The strongest evidence against my reading is ThoughtSpot, which built a company on search over enterprise data and reported $150 million in annual recurring revenue and more than a thousand customers in 2023 [18]. Those are the vendor's own figures, but they are not nothing, and I would not tell anyone that nobody will pay for a way to ask the data a question. My claim is narrower: across fifty years of attempts, no interface removed the need for somebody to write down what the business's words meant, and the ones that were retired were retired with that work still owed.

What carried across, and what did not

If the vocabulary is the asset, the test of the claim is what happened to it when the interface went. Two current successors give different answers, and the difference is the most useful thing in this piece.

Microsoft carried it across. Q&A's successor is Copilot, and Microsoft's documentation for using Copilot with a semantic model says so plainly: "Power BI relies on the same linguistic modeling as the Q&A feature" [13]. The synonyms and relationship verbs a business wrote for Q&A are what Copilot reads, and the same page is blunt about what happens without them: Copilot "might be more likely to return unexpected results", and without preparation it "mainly produces low-quality and inaccurate outputs that might be incorrect or even misleading" [13]. It also puts a price on the work: "Setting up a linguistic model for your semantic model costs additional time and effort on top of your semantic model development tasks" [13]. On that account, a business that did the work for Q&A in 2015 would still have it in 2026. The interface changed; the vocabulary moved with the model it was stored in.

Tableau carried part of it. Its notice retiring Ask Data names Tableau Pulse as the replacement [12], and Pulse stands on the same foundation Ask Data did: "You create a metric definition by connecting to a published data source" [14]. The published data sources themselves, with the field names a business had given them, stayed in place for Pulse to build on. What has no documented path is the layer that belonged to Ask Data itself: the field and value synonyms that data source owners and administrators added in Ask Data's own tab, for a data source or for an individual lens [19], and the lenses, each with its chosen fields, its synonyms and its suggested questions for a particular audience [20]. Pulse's documentation makes the definition the centre of the new product — "Metric definitions are the set of metadata that functions as the single source of truth" [14] — and that is the right design. But neither the retirement notice nor the current documentation describes carrying Ask Data's synonyms or lenses into it [12][14][19][20]. I read what those pages say, not Tableau's internal migration tooling, so this is a statement about the public record rather than a proof that nothing moved. On that record, the part of the vocabulary a business had taught the question box itself was demanded again by the product that replaced it; the part it had kept in its data sources was not.

So the claim I began with needs one adjustment, and the adjustment is the lesson. The vocabulary outlives the interface only where it was kept somewhere the interface does not own. Where it lived inside the product's own feature, its survival was the vendor's decision. Microsoft carried its question box's vocabulary forward; Tableau carried the data sources underneath and left its question box's own layer behind. The narrower rule still rules something out: a programme that keeps its business vocabulary only inside a vendor's question box should expect to write it again at that box's retirement.

Every layer finds the one beneath it

From here the warrant changes: what follows rests on my own record of platforms and the layers built on them, offered as a pattern I have watched repeat, not as a law.

Asked once for an example of a business that had genuinely solved the problem of systematising its data — made it orderly all the way down — I could not give one, and explained why:

Systematizing something merely identifies a problem further up or down the chain. Systematize the delivery and ingestion and it surfaces that the groups downstream of it have their own problems; build the reporting layer on top and you discover the data underneath it was never as sound as everyone assumed. It is layers all the way down, and people spend entire careers at the same company peeling back the onion only to retire and hand the process to their replacement. It is the nature of the beast and inherent to the environment of business. The whole turn to outsourcing infrastructure is another example of systemization exposing that what was systematized was never really the problem. AI is going to do the same thing.

I said that about AI in general, and the history above is the most specific confirmation of it I could have asked for. Every question box was a systematisation of asking. Each one, put in front of the business, surfaced the layer beneath it: the business had never agreed what its own words meant. LUNAR needed a 3,500-word dictionary [1]. English Query needed its nouns and verbs mapped by hand [5]. Q&A needed a setup suite [9]. Ask Data needed users who already knew the field names [12]. Copilot needs "linguistic modeling" that "costs additional time and effort" [13]. The interface was sold as the end of the problem and turned out to be the instrument that found it.

The current generation is doing exactly that, and the benchmarks measure it. When the BIRD benchmark was published in 2023, built on 95 real databases totalling 33.4 gigabytes, ChatGPT, the most effective model its authors tested, reached 40.08% execution accuracy against a human 92.96% [15]. It is worth looking at what the benchmark hands the model with each question: "external knowledge evidence", written by expert annotators — "words or expressions that have the same or similar meanings" and "detailed descriptions of database values" [15]. That is a vocabulary. The benchmark's own design supplies the thing every earlier interface had to have written for it. A second study, on an enterprise-style insurance schema, found GPT-4 answering 16% of questions correctly against the raw SQL tables and 54% when the same questions went through a knowledge graph that encoded what the tables meant [16]; I have read that one only at the level of its abstract.

I would not overstate what that proves, and the strongest objection to my reading is sitting on BIRD's own leaderboard. The best system there now scores 82.39% [15], up from 40.08% in three years and closing on the human figure. If the question box was held back by parsing, it is not held back much longer. I accept that and it does not trouble the argument, because LUNAR answered 78% of the questions put to it in 1971, within the limits Woods described [1]. Parsing has never been the long pole. The benchmark scores rise when somebody has already written the definitions down; the enterprise's own definitions are the part no benchmark can write for it.

There is a second thing the layers do, and I have argued it at length before: the definitions do not have to be wrong to cause trouble. A semantic layer built properly to documented rules still gives different groups different answers according to their own reporting requirements, and the defect only shows when those groups compare notes (The Number Was Never Doing the Work). A conversational interface makes that worse in one particular way. A dashboard presents one group's answer to that group. A question box presents it to whoever asks, in a sentence, with nothing on the screen to say which group's definition produced it. That is one more reason to keep the definitions somewhere a person can open and read, rather than inside the model that answers.

The bill changed shape

The current interfaces have one property that no documentation I read attaches to the early ones, and it bears directly on how a programme should budget.

English Query shipped with SQL Server 2000 [6]. None of the documentation I read attaches a price to asking it a question, and I found no licensing terms for it at all, so that is an absence in what I read rather than a finding about how it was sold. What is documented is that the current successor is metered. Microsoft's billing documentation for Copilot in Fabric says that "each Copilot interaction is metered by the number of tokens processed", with output tokens charged at four times the rate of input, and works an example in which a single ordinary request consumes 400 capacity-unit seconds [17]. "Consumption is based on tokens" [17].

I have called the agentic version of this change a difference of degree rather than of kind, and the part of that verdict that matters here is the bill: what was a one-time expense has become a recurring one, and it still needs an architecture change and a project to implement it (Ideally, Nothing). The question box has made the same move. What had been a feature is now a meter, and the meter runs hardest on exactly the workload these interfaces were built for — a person asking a question in a sentence and getting a sentence back.

That changes the arithmetic of the vocabulary as well, in the vocabulary's favour. Microsoft's own guidance ties the two together: when field names are inconsistent or cryptic, "users are more likely to make mistakes in their prompts and Copilot gets confused" [13], and on a metered interface every confused exchange is paid for. The cost of not having written the definitions down is no longer only a configuration job avoided once. It can become a recurring charge, paid in retries.

The failures were there before the model

The last lesson rests mostly on my own record rather than on any vendor's documentation, and it needs narrowing before it can be used.

Asked what would go wrong as AI agents took over more of the reporting, I declined to call my answer a prediction and named three failures. The first was this:

Reporting drift—as AI ‘agents’ and other work flow automation tools are used to generate more and more reports for individuals, they’ll ‘learn’ to massage, read ‘correct,’ the data to meet the needs of their users and this will slowly drift the reports away from reality to what is asked for from the users.

The mechanism in that answer needs one correction, made when the argument was carried forward into agents in Ideally, Nothing: the drift needs no model that learns. Inside a session it comes from sycophancy, and across sessions from the person who keeps the phrasing that produced the welcome answer. The other two failures were runaway token costs and orphaned agents, still producing reports for people who have left, and I said at the time that all three had already happened with reporting systems before agents arrived. A retrospective is the place to check that backward claim, and for drift the published record supports less than I said.

What it shows is the precondition. In Tableau's own retirement notice, about a feature with no language model in it, a metric's definition "was dependent on the accuracy of the visualization", so "there could be multiple versions of the same Metric in a Tableau environment" [12] — several versions of one measure in a single environment. That is definitions multiplying, and it is what drift needs: once a measure exists in several versions, a report can slide toward the version its reader prefers without anything on the page saying that a choice was made. It is not the drift itself. I found no published pre-model case of a report being bent toward what its reader wanted to see, so the claim that it happened rests on my record, as I said it, and a reader is entitled to weigh it as a practitioner's pattern rather than a documented one. The consequence for a programme is the same either way: the control is one definition per measure, kept where every report and every question box has to use it. The orphans are on firmer ground, because the nearest thing to them is in my own record, in the realignment I quoted at the top of this piece. Every migration I described carried dozens, sometimes hundreds, of reports and their back-end models into a review that decommissioned them, and in my record that review came with the migration, not before it.

That gives a programme something concrete to do, and it is cheap. The review I described happened because a platform was being retired. The AI interfaces now come with retirement dates of their own, published in advance: Q&A's retirement was announced roughly fourteen months before the reports containing it start showing errors [9][10]. That notice period is a forced review, handed over for free. Use it the way the migrations used theirs: list what the retiring feature touches, find who still reads each thing, switch off what nobody does, and move the definitions somewhere the next interface does not own.

What I would fund

I began with the platforms I have watched get switched off, and with the observation that dozens, sometimes hundreds, of reports did not survive each switch. The early attempts to put AI in front of business data went the same way, on a faster clock. LUNAR and Rendezvous stayed research systems; English Query and Ask Data were discontinued or retired, and Q&A is being retired in February 2027 [7][10][12]; and an invited retrospective of the earlier waves puts their commercial record in five words: "Commercial products were given up" [2]. What each of them needed first, and what the current generation still needs, is the vocabulary: somebody's written account of what the business means by its own words.

So here is what I would fund, for a master data or an analytics programme deciding what to do about the current question boxes.

Fund the vocabulary as the asset. Definitions, synonyms, the agreed names of the things the business counts — kept in the governed layer the programme owns, the master data and the definitions beside it, where a person can open and read them and any interface can be pointed at them. That is the work every generation demanded, and on the record above it is the only part that has carried from one generation to the next.

Budget the interface as a consumable. Every one in this piece had a lifespan, and the most recent ones publish theirs. Before signing, ask the vendor the question that separated Microsoft's customers from Tableau's: when this feature is retired, what happens to the vocabulary we taught it?

Price the meter. The current interfaces charge per question, and the charge falls hardest where the vocabulary is weakest. A well-described model is cheaper to run, not only more accurate.

And use the retirement dates. The next forced review of the reporting estate does not have to wait for a reorganisation or a new CIO. The vendors are now announcing it.

None of this is an argument against asking the data a question in English. It is an argument about which half of that sentence to pay for. Fifty years of interfaces have come and gone. The words were always the part that lasted, whenever somebody wrote them down somewhere the interface did not own.

References

[1] Woods, W. A., Semantics and Quantification in Natural Language Question Answering, BBN Report No. 3687, Bolt Beranek and Newman Inc., November 1977 (DTIC ADA047600). https://apps.dtic.mil/sti/pdfs/ADA047600.pdf Read through a fetch-and-extract tool, September 27, 2026; the passages on the 1971 LUNAR demonstration and the system's dictionary and databases only. The PDF could not be saved locally (both available networks refused a direct download); the extracts used are stored at documents/wi/redrafts/sources/AIBI_w4/Woods_1977_BBN_Report_3687_Semantics_and_Quantification_LUNAR_CAPTURE.txt. The 1971 demonstration itself is reported in Woods (1973), which was not read; the figures are cited as Woods reports them in 1977.

[2] Koutrika, Georgia, "Natural Language Data Interfaces: A Data Access Odyssey," in 27th International Conference on Database Theory (ICDT 2024), LIPIcs vol. 290, pp. 1:1–1:22, doi 10.4230/LIPIcs.ICDT.2024.1. https://drops.dagstuhl.de/storage/00lipics/lipics-vol290-icdt2024/LIPIcs.ICDT.2024.1/LIPIcs.ICDT.2024.1.pdf Read through a fetch-and-extract tool, September 27, 2026: the history sections and the conclusion. Open access. The source for Codd's quoted words and for Rendezvous; Codd's own 1974 report, "Seven Steps to Rendezvous with the Casual User," was not read. Capture: documents/wi/redrafts/sources/AIBI_w4/Koutrika_2024_ICDT_Natural_Language_Data_Interfaces_CAPTURE.txt.

[3] Chamberlin, Donald D., "Early History of SQL," IEEE Annals of the History of Computing 34(4): 78–82, October–December 2012, doi 10.1109/MAHC.2012.61. Read from a copy filed as an exhibit in a US Patent Trial and Appeal Board proceeding: https://ptabdata.blob.core.windows.net/files/2019/IPR2019-00624/v34_Exhibit%201025%20-%20Early%20History%20of%20SQL.pdf Read through a fetch-and-extract tool, September 27, 2026; the passages on the intended and actual users of the language. Capture: documents/wi/redrafts/sources/AIBI_w4/Chamberlin_2012_Early_History_of_SQL_IEEE_Annals_CAPTURE.txt.

[4] Androutsopoulos, I., G. D. Ritchie and P. Thanisch, "Natural Language Interfaces to Databases — An Introduction," Natural Language Engineering 1(1): 29–81, 1995; arXiv cmp-lg/9503016. https://arxiv.org/abs/cmp-lg/9503016 Read through a fetch-and-extract tool, September 27, 2026: the abstract, the history of LUNAR, the advantages-and-disadvantages section and the passage on commercial acceptance. Capture: documents/wi/redrafts/sources/AIBI_w4/Androutsopoulos_Ritchie_Thanisch_1995_NLIDB_Introduction_CAPTURE.txt.

[5] Allen, Jonathan, "English Query Discontinued," InfoQ, October 10, 2006. https://www.infoq.com/news/English-Query-Discontinued Read in full through a fetch-and-extract tool, September 27, 2026. The source for the hand mapping of nouns and verbs, the example question, and the statement that Microsoft gave no reason; the article's own guesses at a reason are not used. Capture: documents/wi/redrafts/sources/AIBI_w4/Allen_2006_InfoQ_English_Query_Discontinued_CAPTURE.txt.

[6] "English Query — Part 1," SQL Server Reference Guide, InformIT (page dated March 28, 2003). https://www.informit.com/articles/article.aspx?p=31359&seqNum=224 Read through a fetch-and-extract tool, September 27, 2026. The source for English Query shipping with SQL Server 2000 and for the stages of authoring an English Query application. The guide's author is not named on the page as retrieved. Capture: documents/wi/redrafts/sources/AIBI_w4/InformIT_2003_SQL_Server_Reference_Guide_English_Query_CAPTURE.txt.

[7] Microsoft, "English Query," SQL Server 2005 Books Online (previous versions). https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2005/ms143754(v=sql.90) Read in full, September 27, 2026; the page is three sentences long. Capture: documents/wi/redrafts/sources/AIBI_w4/Microsoft_SQL2005_English_Query_Discontinued_CAPTURE.txt.

[8] Microsoft SQL Server Team, "Microsoft Updates Power BI for Office 365 Preview with New Natural Language Search, Mapping Capabilities," Microsoft SQL Server Blog, September 25, 2013. https://www.microsoft.com/en-us/sql-server/blog/2013/09/25/microsoft-updates-power-bi-for-office-365-preview-with-new-natural-language-search-mapping-capabilities/ Read through a fetch-and-extract tool, September 27, 2026. Capture: documents/wi/redrafts/sources/AIBI_w4/Microsoft_2013-09-25_PowerBI_for_Office365_QandA_CAPTURE.txt.

[9] Microsoft Power BI team, "Deprecating Power BI Q&A," Power BI Updates Blog, December 2025. https://community.fabric.microsoft.com/blog/fbc_pbiupdatesblog/deprecating-power-bi-qa/5173970 (the former address, https://powerbi.microsoft.com/en-us/blog/deprecating-power-bi-qa/, redirects here). Read through a fetch-and-extract tool, September 27, 2026. The deprecation timeline, the description of Q&A Setup and the three stated reasons are from this page. Capture: documents/wi/redrafts/sources/AIBI_w4/Microsoft_2025-12_Deprecating_PowerBI_QandA_CAPTURE.txt.

[10] Ali, Mohammad, "Power BI Q&A retirement reminder: February 2027 timeline update," Microsoft Fabric Community blog, September 2026. https://community.fabric.microsoft.com/blog/fbc_pbiupdatesblog/power-bi-qa-retirement-reminder-february-2027-timeline-update/5365841 Read through a fetch-and-extract tool, September 27, 2026. The page gives its date as a relative age; the month is inferred from that. Capture: documents/wi/redrafts/sources/AIBI_w4/Microsoft_2026-09_PowerBI_QandA_Retirement_Feb2027_CAPTURE.txt.

[11] Tableau Software, "Tableau Releases Ask Data, A New and Intuitive Way to Analyze Data With Natural Language," press release, Seattle, February 13, 2019. https://www.prnewswire.com/news-releases/tableau-releases-ask-data-a-new-and-intuitive-way-to-analyze-data-with-natural-language-300794815.html Read through a fetch-and-extract tool, September 27, 2026. Cited for what the vendor promised at launch, not as evidence of what the feature did. Capture: documents/wi/redrafts/sources/AIBI_w4/Tableau_2019-02-13_Ask_Data_Press_Release_CAPTURE.txt.

[12] Miller, Matthew, "Tableau Metrics and Natural Language Query Evolve with Tableau Pulse," Tableau blog, February 21, 2024. https://www.tableau.com/blog/tableau-metrics-and-natural-language-query-evolve-tableau-pulse Read through a fetch-and-extract tool, September 27, 2026. The retirement versions, the quoted reason for retiring Ask Data (the post gives three: not "natural" enough, generative AI as "a completely superior experience", and declining on-premises adoption), and the account of the legacy Metrics feature ("there could be multiple versions of the same Metric in a Tableau environment" because "the metric definition was dependent on the accuracy of the visualization") are from this post. Re-read at source September 27, 2026 for the revision; the post describes no migration of Ask Data synonyms or lenses. Capture: documents/wi/redrafts/sources/AIBI_w4/Miller_2024-02-21_Tableau_Pulse_Retires_Ask_Data_CAPTURE.txt.

[13] Microsoft, "Use Copilot with Semantic Models in Power BI," Microsoft Learn, last updated June 4, 2026. https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-semantic-models Read through a fetch-and-extract tool, September 27, 2026; the model-preparation sections. Capture: documents/wi/redrafts/sources/AIBI_w4/Microsoft_Learn_Copilot_Semantic_Models_2026-06-04_CAPTURE.txt.

[14] Tableau, "Create Metrics with Tableau Pulse," Tableau Cloud Help, current as read September 27, 2026. https://help.tableau.com/current/online/en-us/pulse_create_metrics.htm Read through a fetch-and-extract tool, September 27, 2026 (twice; the second read for the published-data-source sentence and for any mention of Ask Data synonyms, lenses or migration, of which there is none). Capture: documents/wi/redrafts/sources/AIBI_w4/Tableau_Help_Create_Metrics_with_Pulse_CAPTURE.txt.

[15] Li, Jinyang, and colleagues, "Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs" (BIRD), NeurIPS 2023 Datasets and Benchmarks Track; arXiv 2305.03111. https://arxiv.org/abs/2305.03111 — and the BIRD leaderboard, https://bird-bench.github.io/, read September 27, 2026. Abstract and the passages defining external knowledge evidence read through a fetch-and-extract tool; the experimental sections were not read closely. The 82.39% figure is the top test-set execution accuracy on the leaderboard on the day it was read and will move. Capture: documents/wi/redrafts/sources/AIBI_w4/Li_et_al_2023_BIRD_Benchmark_and_Leaderboard_CAPTURE.txt.

[16] Sequeda, Juan, Dean Allemang and Bryon Jacob, "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, November 13, 2023. https://arxiv.org/abs/2311.07509 Abstract only, read September 27, 2026; the paper itself was not read. Capture: documents/wi/redrafts/sources/AIBI_w4/Sequeda_Allemang_Jacob_2023_KG_LLM_Benchmark_CAPTURE.txt.

[17] Microsoft, "Copilot consumption, usage, and billing in Fabric," Microsoft Learn, last updated June 11, 2026. https://learn.microsoft.com/en-us/fabric/fundamentals/copilot-fabric-consumption Read through a fetch-and-extract tool, September 27, 2026. Capture: documents/wi/redrafts/sources/AIBI_w4/Microsoft_Learn_Copilot_Fabric_Consumption_2026-06-11_CAPTURE.txt.

[18] ThoughtSpot, "ThoughtSpot Experiences Historic Year of Growth as Customers Around the World Realize Unprecedented Value from AI-Powered Analytics," press release (GlobeNewswire), September 21, 2023. https://www.globenewswire.com/news-release/2023/09/21/2747321/0/en/ThoughtSpot-Experiences-Historic-Year-of-Growth-as-Customers-Around-the-World-Realize-Unprecedented-Value-from-AI-Powered-Analytics.html Read through a fetch-and-extract tool, September 27, 2026. Vendor-reported figures, cited as the strongest evidence found against the article's reading and not independently checked. Capture: documents/wi/redrafts/sources/AIBI_w4/ThoughtSpot_2023-09-21_Growth_Press_Release_VENDOR_CAPTURE.txt.

[19] Tableau, "Add Synonyms for Ask Data," Tableau Desktop and Web Authoring Help (page carries the retirement notice "Ask Data and Metrics features were retired in Tableau Cloud in February 2024 and in Tableau Server version 2024.2"). https://help.tableau.com/current/pro/desktop/en-us/ask_data_synonyms.htm Read through a fetch-and-extract tool, September 27, 2026. The source for synonyms being set in the Ask Data tab for a data source or an individual lens, for field-name and field-value synonyms, and for who could add them; the page says nothing about synonyms carrying to another feature. Capture: documents/wi/redrafts/sources/AIBI_w4/Tableau_Help_Ask_Data_Synonyms_and_Lenses_CAPTURE.txt.

[20] Tableau, "Create Lenses that Focus Ask Data for Specific Audiences," Tableau Cloud Help (same retirement notice). https://help.tableau.com/current/online/en-us/ask_data_lenses.htm Read through a fetch-and-extract tool, September 27, 2026. The source for lenses being built only on separately published data sources and configuring fields, synonyms and suggested questions for a particular audience. Capture: as for [19].

[21] Profisee, "Microsoft Fabric" (solution page, headline "The Only Native MDM Workload in Microsoft Fabric"). https://profisee.com/solutions/microsoft-enterprise/microsoft-fabric/ Read through a fetch-and-extract tool, September 27, 2026. Cited in the partner disclosure only, for the practice's partner's alignment with Microsoft: the page describes the workload as "embedded directly into the Microsoft Fabric interface, just like first-party applications such as Azure Data Factory or Power BI". Vendor self-description. Capture: documents/wi/redrafts/sources/AIBI_w4/Profisee_Microsoft_Alignment_CAPTURE.txt.