> ## Content Index > Fetch the complete content index at: https://wi.senterprises.com/llms.txt > Use this file to discover other available public pages before exploring further. # Precise and Wrong: Master Data, Semantic Layers and the Next Decade of Natural-Language Answers - URL: https://wi.senterprises.com/articles/precise-and-wrong-master-data-before-the-semantic-layer/ - Published: 2026-10-22T08:00:00.000Z - Updated: 2026-11-06T03:09:42.000Z - Description: A semantic layer built first makes natural-language answers exact, repeatable and traceable; it does not make them true. Why master data quality comes first, why a useful measurement of the gap is already a project plan, and why the machines will write the semantic layer long before anyone agrees… - Author: Jeffrey Shabel - Tags: AI + BI, Natural Language Interfaces & AI in BI, 2026, October 2026, 2026-W43, AI: Central, #wi-art_01KVZKVTFNX71DQZPWEJCPNQY3 *Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary* A business that wants a question box in front of its data, and wants the answers to be right, has two foundations it can spend on first: the quality of its master data, or the semantic layer that tells the machine what its numbers mean. The question was whether to fund master data or the semantic layer first: > As pedestrian as it is, Master Data Quality is the Foundation upon which all Semantic Layers are built. If you focus on the Semantic Layer first, you’ll get NLQ precision at the cost of accuracy. You’ll be able to trace the problem back to the precise records that caused it, which will then, still, require the attention of the Master Data Steward. The ranking is the plain part, and "pedestrian" concedes something. Master data quality is not the investment anyone wants to present to a steering committee in a year when every slide is expected to say AI. It is the one I put first anyway, and the reason is in the second sentence, which turns on two words that are often used as if they meant the same thing. They do not. Precision, as I use the word here, is an answer that is exact and repeatable: the same question returns the same number every time, in every tool, from every person who asks it, and the number can be traced to the precise records that produced it. Accuracy is whether that number is true of the business. A semantic layer built first buys the first. It does not buy the second, and the third sentence of my answer says what happens next: the trace leads, with great exactness, back to the records that were wrong all along, and somebody who knows the domain still has to fix them. This piece follows that ranking in three directions. What a semantic layer actually delivers, and why the published accuracy numbers mostly measure the precision half. Whether my ranking is measured or judged, and why the honest answer to that question is more useful than a number would be. And where it is heading: over the next decade the machines will write semantic layers well before they can master the hard records beneath them, and well before they can do the thing that makes a semantic layer worth having at all, which is getting the people who own the definitions to agree on them. That last gap is already being exploited, and I will describe how. A natural-language answer breaks where the model has to [work out for itself what a number means](https://wi.senterprises.com/articles/semantic-layer-what-the-model-cannot-infer/), and the demonstration that wins the funding is not [the system that has to survive the whole company asking it questions](https://wi.senterprises.com/articles/natural-language-query-the-demo-and-the-system/). This piece is about order, and about time. ## Precise is not the same as true The distinction is older than any of the software involved. Metrology, the science of measurement, defines measurement accuracy as the "closeness of agreement between a measured quantity value and a true quantity value of a measurand" [\[1\]](#ref-1), and measurement precision as the "closeness of agreement between indications or measured quantity values obtained by replicate measurements on the same or similar objects under specified conditions" [\[2\]](#ref-2). One compares a result with the truth. The other compares results with each other. The international vocabulary goes out of its way to add a warning in a note: "Sometimes "measurement precision" is erroneously used to mean measurement accuracy" [\[2\]](#ref-2). Put the two words side by side over a natural-language system and the failure shows itself. A semantic layer fixes the definition of every term it exposes. Ask it for revenue by region on Monday and on Friday, from a dashboard and from a chat window, and it runs the same calculation over the same tables and returns the same figure. That is precision, and it is valuable: an organisation whose reports disagree with each other cannot even begin to ask which of them is right. But if a customer's region is recorded wrongly, or the same customer sits in the table three times under three spellings, the layer computes the wrong figure in exactly the same way every time. The answers cluster tightly, and they cluster in the wrong place. Figure 1 puts the two questions on separate axes, and the precision axis here reaches beyond repeated runs of one measurement to agreement across tools and groups. ![A two-by-two grid. Across: whether the answers agree across runs, tools and groups. Up: whether the answer is true. A semantic layer built first over unmastered records sits where answers agree but are not true. Every label is written out below.](https://wi.senterprises.com/assets/diagrams/FIG012_AIBI_Precise_Is_Not_True_v1_0.png) Figure 1: Precision and accuracy are separate questions. A semantic layer built first answers the first; only true records answer the second. **Precise is not the same as true** A note across the top reads: Concepts, not measurements: no count, share or accuracy figure is shown. Below it, a two-by-two grid. The vertical axis is headed **Accuracy: is the answer true of the business?**, with the upper row labelled **True** and the lower row **Not true**. The horizontal axis is headed **Precision: do the answers agree across runs, tools and groups?**, with the left column labelled **Reports disagree (different definitions)** and the right column **Answers agree, in every tool, every time**. Upper left: **Mastered records, definitions not agreed**, noted **true records, but each group's definition gives a different answer**. Upper right, highlighted: **Mastered records, agreed definitions, semantic layer**, noted **precise and true: the goal**. Lower left: **Reports that disagree, over unmastered records**, noted **the disagreement at least invites the question**. Lower right: **Semantic layer first, over unmastered records**, noted in bold **precise and wrong: every tool agrees; the trace leads to the steward**. The two axis questions follow the article's definitions of the two words. Where each arrangement sits in the grid is this article's reading, not a measurement. I have watched governed data turn up a regional supplier filed in the wrong region, and the point of that example here is how unremarkable the error is. A semantic layer would have reported the supplier's spend under the wrong region with complete consistency, in every tool, for as long as the record stayed wrong. Nothing in the layer could have told anyone, because the layer's job is to apply a definition faithfully, and it did. This is the sense in which semantic-layer-first buys precision "at the cost of" accuracy, and the phrase deserves to be read carefully. The layer does not make the data less accurate than it was. The cost is subtler. Precision makes a wrong answer look settled. Before the layer existed, two reports that disagreed were an invitation to ask why; after it, every report agrees, and the agreement is easy to mistake for verification. I have said before that a semantic layer is a set of aliases and abstractions that recasts the data into the form its consumer prefers, and that it will often answer different groups differently according to their reporting needs. Built well, it removes the second problem. It leaves the records underneath exactly as true or false as it found them. ## What a semantic layer buys A disclosure first, because from here the argument assesses vendors' products. The practice behind this publication is a Profisee partner: clients pay us for deployment work, a licence sale we refer earns us a referral fee from the vendor, and our services revenue depends on master data management being bought at all. That interest runs toward praise of the category. It runs the same way as this piece's central ranking, which our revenue would like you to accept. So give the ranking, and anything favourable I say about the category, less weight than my criticism of it. Profisee is aligned with Microsoft's data platform, so the interest runs toward Microsoft's products too. Snowflake and Databricks sell platforms that compete with Microsoft's, which gives me a reason to be hard on them, so discount my criticism of them. dbt Labs sells the semantic layer whose documentation I cite and has its own interest in how it is described. The vendors describe what a semantic layer delivers, and read closely, they describe precision. dbt Labs says that "By centralizing metric definitions, data teams can ensure consistent self-service access to these metrics", that moving the definitions into the modelling layer lets teams "feel confident that different business units are working from the same metric definitions, regardless of their tool of choice", and that a changed definition is "refreshed everywhere it's invoked and creates consistency across all applications" [\[3\]](#ref-3). Databricks describes its metric views as "a centralized way to define and manage business metrics", so that teams "define metrics once and query them at runtime" [\[4\]](#ref-4). Consistency, sameness, definition once: every one of those is a claim about results agreeing with each other. Neither page makes a claim about the records the definitions run over, and the dbt page, as read on 18 October 2026, says nothing about validating the quality of the data underneath [\[3\]](#ref-3). That is not a criticism of the products. It is an accurate description of what a semantic layer is for, and it is the reason I rank it second rather than nowhere. Consistency is worth paying for. It is what makes the trace possible: when the definition is fixed and shared, a wrong answer can be followed back to the records that produced it instead of being argued about as a difference of opinion between two reports. A business that has the trace can find its master data problems. What it cannot do is skip them, because the trace ends at the steward's desk. My own record has a cost attached to the other order. Organisations I have worked with that produced their client lists before the records underneath were right ended up [paying for the correction out of other projects' time and budget](https://wi.senterprises.com/articles/mdm-who-owns-the-data-really/), and more than one rewrote the report's business logic more than once within the same project as errors underneath surfaced and were fixed. A semantic layer is report logic with a longer reach. Build it over records that are still being corrected and the definitions will be revised as the corrections land, and every revision propagates, by design, to every tool and every agent that reads the layer. Starting from accurate records, the definitions get written once. ## What the benchmarks hold fixed The obvious way to settle a ranking like mine would be to read the published accuracy numbers. There are a great many of them, and they are improving quickly. Take BIRD, a cross-domain text-to-SQL benchmark built on large databases with dirty values. A 2025 critique of how such benchmarks are evaluated, by Cedric Renggli, Ihab Ilyas and Theodoros Rekatsinas, found two problems in the evaluation itself: poor data quality in the evaluation sets, largely because benchmarks do not allow for the ambiguity of a question or for the several valid queries that answer it, and bias from the imperfect match functions used to judge whether two queries are equivalent [\[7\]](#ref-7). BIRD was built because earlier benchmarks had few rows of database contents; it covers 95 databases across 37 professional domains, and its authors stress that the database values "typically retain their original and frequently "dirty" format" [\[5\]](#ref-5)[\[6\]](#ref-6). When the paper was published, the best model it tested reached 40.08% execution accuracy against 92.96% for people [\[5\]](#ref-5). On the leaderboard on the day I read it, the best systems on the test set had reached about 83% [\[6\]](#ref-6), which is a real and fast improvement. Now look at what "execution accuracy" compares. A system's query is run against the database and its result is compared with the result of a reference query written by a person, over the same database. If a value in that database is wrong, the reference query returns the wrong value too, and a system that reproduces it is scored correct. The dirty values in BIRD are values the system has to read through, in their original, inconsistent formats; they are not errors the system is asked to detect. That makes these benchmarks, in the metrologists' terms, measures of how closely a machine's answer agrees with an expert's answer over the same records. They measure something close to precision. They cannot measure accuracy in my sense, because the benchmark has no access to the world the records are supposed to describe. Figure 2 draws what is compared with what. ![Two queries, one written by the system and one by a person, run over the same benchmark database, and their results are compared with each other. The world the records describe sits outside the comparison. Every label is written out below.](https://wi.senterprises.com/assets/diagrams/FIG013_AIBI_What_The_Benchmark_Compares_v1_0.png) Figure 2: Execution accuracy compares two results computed from the same records. Whether those records are true of the business is not part of the comparison. **What execution accuracy compares** A note across the top reads: Structure, not results: no score is shown. Below it, inside one panel, a flow from top to bottom. At the top, side by side: **The system's query**, noted **written by the model from the question**, and **The reference query**, noted **written by a person for the same question**. Both run over a single box in the middle, **One benchmark database**, noted **the records as given: dirty values, and any wrong ones, included**. From the database come **The system's result** and **The reference result**, and both feed the highlighted box **The two results, compared with each other**, noted **a match is scored correct**. Below the panel, outside it and connected to nothing: **The world the records describe**, noted in bold **outside the comparison: a wrong value gives the same wrong result to both queries, and the match is still scored correct**. The structure follows how the benchmark scores execution accuracy [\[5\]](#ref-5)[\[6\]](#ref-6). Reading what it measures as close to precision is this article's argument, not a measurement. Researchers in the field have started to say as much about their own instruments. The same authors warn of "the potential risks of relying on aggregate metrics in existing benchmarks" [\[7\]](#ref-7). Their concern is the benchmarks' own reference answers, not an enterprise's master data, but the lesson carries: a single accuracy percentage hides what was compared with what. The closest thing I found to a direct test of the data-before-questions half of the order runs the way my ranking does, with limits a reader should know before weighing it. A team at Hagia Labs describes a natural-language query system deployed over 240,000 employee records, in which an automated cleaning stage (translation, spelling correction, merging of duplicate institutions and cities, rule validation) runs before any question is answered. They report that without the cleaning pipeline, "Schema compliance fell to 81.3% due to entity mismatches and inconsistent field values", against 95.1% with it, and that "System performance became acceptable only after implementing automated cleaning" [\[8\]](#ref-8). It is a preprint describing the authors' own system at one unnamed organisation; the ablation reports schema compliance, not whether the answers were true; the paper does not state the query count behind the 81.3% figure, or that it was measured on the same queries as the 95.1%, so read the pair as indicative, not like-for-like; the paper's own six-month deployment table reports 15.6% schema compliance over 347 queries, far below the 95.1% headline [\[8\]](#ref-8); and the headline correction rate comes from a sample of 5,000 records. It is one case, and I cite it as one case. The forecasters, meanwhile, have put their weight on semantics. Gartner predicted this year that by 2027 organisations that prioritise semantics in AI-ready data "will increase their agentic AI accuracy by up to 80%" and "reduce costs by up to 60%" [\[9\]](#ref-9). The release states no method, its accuracy figure is for agents rather than query interfaces, and a prediction is not a measurement. It is also not in conflict with my ranking as much as it first appears. A semantic layer will make agents more consistent, and much of what passes for an accuracy gain on a fixed test set is a consistency gain. Nothing in the release says the records underneath become more true. ## Measured or judged So is my ranking a measurement? My answer was that the question contains its own difficulty: > It is challenging to measure the differences because any measurement that provides sufficient value is, itself, a road map to fix the Master Data Errors in the Data. So, a useful report is going to double as a Project Proposal to fix the underlying Master Data Issues. I hold that, and it needs unpacking, because it can sound like an excuse for not measuring. It is the opposite. Think about what a measurement of the gap between precision and accuracy would require. To know whether a natural-language answer is accurate, somebody has to know the true answer: the real number of active customers, the real spend with that supplier, in the right region. Building that answer key means checking the records the answers depend on, and checking them is the work of finding which ones are wrong. By the time an organisation can say "our answers are wrong this often", it holds at least a sample of the records that make them wrong, the classes of error those records fall into, and the systems they came from. That is the start of the remediation plan. The report and the project proposal are the same document. The best-known cheap method for measuring data quality makes the point without intending to. Tadhg Nagle, Thomas Redman and David Sammon had managers assemble 100 records their own department had created, mark the obvious errors in each, and count the records with none; across 75 executives' scores, "On average, 47% of newly-created data records had at least one critical error" [\[10\]](#ref-10). The number is the headline, and it is an alarm, not a plan. But to produce it, each manager went through a hundred records and marked what was wrong with them. The marks are the first page of the work list, and they are the part of the exercise anyone can act on. The study's own limits are plain: a hundred records per department, errors judged by the people who created them, a sample of executives rather than of companies. As a measurement it is rough. As a demonstration that the useful product of measuring data quality is the list rather than the rate, it is exact. There is a version of measurement that is not a roadmap, and I concede it: a vendor's or an analyst's estimate of what bad data costs organisations in general. It produces a number without identifying a single record, and for that reason it does nothing for the organisation reading it except, perhaps, persuade someone to commission the other kind. A measurement of your own NLQ accuracy that is good enough to defend in front of a funding committee cannot avoid naming your bad records. That is the narrower thing I mean, and it still rules something out: it says no one will hand you a credible accuracy figure for your own estate without, in the same act, handing you the start of the plan to fix it. So I will not give you a number. The ranking is my judgement, the argument above is why I think a number would not change it, and the place to spend the measurement budget, if there is one, is on the measurement that doubles as the project. ## Which half the machines will write first From here the argument rests more on what I have watched than on what the sources show, and it should be read as pattern rather than law. The third part of my answer looked at the next decade. AI, I said, makes progress on both, at different speeds, for a reason that has nothing to do with how clever the models get: > Over the next decade, AI is going to make great strides in both, but Semantic Layers and Data Transformation/Restatement is always going to lead, to my mind, Master Data Automation. There’s just too much specialized Domain Knowledge that Data Stewards possess that can’t be easily documented or transmitted to AI models. Semantic Layers, on the other hand, being primarily declarative, have no such limitations. The vendors are already demonstrating the first half. Snowflake's Semantic View Autopilot lets a user "describe what you want and Autopilot generates the logical tables, relationships, and metrics", drawing on the query history the creating role can see, with descriptions "based on the column names and sample values" [\[11\]](#ref-11). dbt Labs says its Copilot "helps you generate SQL, documentation, tests, and semantic models in the dbt platform" [\[12\]](#ref-12). Microsoft's Copilot writes DAX queries from a plain-language request, using "the model metadata (tables, columns, measures)" of the semantic model in front of it [\[13\]](#ref-13). Gartner predicts that by 2030 "universal semantic layers will be treated as critical infrastructure, alongside data platforms and cybersecurity", and that half of organisations will "use autonomous AI agents to interpret governance policies and technical standards into machine-verifiable data contracts" [\[14\]](#ref-14). Whether or not the dates hold, the direction is unmistakable: the writing of definitions, in the form a machine can execute, is becoming something a machine does. The reason it gets there first is the one in my answer: a semantic layer is declarative. It says what a term means and how to compute it. Everything it needs is either in the schema, in the query history, or in someone's head in a form that person can say out loud. That last condition is the one master data work fails. David Autor's account of why some work resists automation opens with Michael Polanyi's observation that "We can know more than we can tell", and describes the paradox as one where "our tacit knowledge of how the world works often exceeds our explicit understanding" [\[15\]](#ref-15). A steward deciding whether two supplier records are the same company, whether a product belongs in a category the hierarchy does not yet have, or whether a value that passes every rule is nonetheless wrong, is drawing on knowledge of exactly that kind: the history of an account, the habits of the people who key it, what a region meant before a reorganisation. Most of it was never written down because nobody needed it written down. The strongest objection comes from the research on data cleaning, and it is substantial. Ralph Peeters, Aaron Steiner and Christian Bizer found that "the best LLMs require no or only a few training examples" to match entities and perform "comparably to PLMs that were fine-tuned using thousands of examples", with "higher robustness to unseen entities" [\[16\]](#ref-16). Avanika Narayan and colleagues showed that large foundation models, given data-cleaning and integration tasks as prompts, "achieve SoTA performance" without being trained for them [\[17\]](#ref-17). The deployment described above automated de-duplication and correction across 240,000 records and reported 97.8% correction accuracy on its sample [\[8\]](#ref-8). And Autor himself names the route around his own paradox: "Contemporary computer science seeks to overcome Polanyi's paradox by building machines that learn from human examples" [\[15\]](#ref-15). I concede most of that. Routine matching, standardisation and correction are being automated, much of them already well, and I expect the share of master data work that needs a human to keep falling. What the same sources do not show is the part my answer turns on. The benchmarks are public datasets; Narayan's team names "challenges with private and domain specific data" as the open problem [\[17\]](#ref-17). A machine that learns from human examples needs the examples, and the decisions a steward makes on the hard records are rarely recorded with their reasons. So the claim I will defend is this one: the declaration of a semantic layer will be automated well ahead of the decisions on the master data records that depend on knowledge nobody has written down. That still rules something out. If, within the decade, the hard records (the ambiguous merges, the new categories, the plausible values that are wrong) are routinely resolved without a steward approving them, as a product's default, I am wrong. If AI-drafted definitions are routinely adopted as enterprise standards without the owners signing them off, and the dispute does not return, I am wrong about agreement. ## Declaring is not agreeing There is a tension in my own answer. I have said elsewhere that an organisation is not ready for AI-assisted decisions while its systems hold several definitions of one element and refuse either to agree a standard or to coexist, and that the bare minimum for a natural-language system worth trusting starts with full agreement on definitions. Agreement is tacit, political work if anything is. So if semantic layers are declarative and therefore automatable, what happens to the agreement? On whether AI automates the writing of a semantic layer but not the agreement behind it, I went further: > Yes, that's exactly what I mean. Business units are already scrambling to be the first to provide an AI-designed Semantic Layer to fill the vacuum and imply that their standards are the Enterprise standards simply because they got there first. The first sentence settles the tension. A semantic layer has two parts that the word hides: the declaration, which says what a term means in a form a machine can run, and the agreement, which is the decision by the people who own the term that this is what it will mean. The machines are taking over the first. Nothing in the vendor pages above claims the second, and it is the hard part of the work, though it was rarely the part anyone tried to skip. In dimensional modelling, the conformed dimensions that let a data warehouse share definitions across its subject areas are "defined once in collaboration with the business's data governance representatives" [\[18\]](#ref-18). Vijay Khatri and Carol Brown put metadata, which carries "the meaning or 'semantics' of data", among the decision domains of data governance, and define governance itself as "who holds the decision rights and is held accountable" for those decisions [\[19\]](#ref-19). A definition, on that view, is a decision with an owner. Automating its syntax does not supply the owner. [The meaning a model cannot infer](https://wi.senterprises.com/articles/semantic-layer-what-the-model-cannot-infer/), the reason a number was defined one way and the business purpose it serves, is the same thing the agreement settles. An AI that drafts a semantic layer from query history is drafting from what people did, which is evidence of a consensus at best and of the loudest user's habits at worst. Whether it is a consensus is a question for the people who own the term. ## The land-grab The second sentence of that answer is the new thing, and I have watched it at clients and see it across the market. When declaring a semantic layer took months of modelling, few units declared one casually; the cost of writing it forced the conversation about who owned it. Once a tool can produce a credible-looking layer in an afternoon from a unit's own tables and query history, the cost of declaring falls to almost nothing, and the cost of agreeing does not fall at all. The gap between the two is a vacuum, and the business units that move first fill it, with the implication that arriving first made their definitions the enterprise's. The consequence, as I read it, follows from how these layers are used: the first layer declared is the one the agents and the chat windows are pointed at, and every later unit meets it as the incumbent. Nobody decided it was the enterprise's standard. I have seen the collision: one group tried to plant its flag and ran into another group that had already planted its own, with stronger executive backing, and it went badly for the losing side. Put that next to the first half of this piece and the cost is plain. A unit's AI-designed layer brings perfect precision to the unit's definitions, over the unit's records, and serves both to everyone who asks. If those records carry the unit's errors, the enterprise now has those errors answered consistently, in every tool, with the authority of the official layer. Precise and wrong, at the scale of the whole organisation. The tooling already draws the line the land-grab blurs. Microsoft Fabric distinguishes three endorsements: an item marked **Promoted** means "the item creators think the item is ready for sharing and reuse", and "Any user with write permissions on an item can promote it"; an item marked **Certified** means "an organization-authorized reviewer has certified" it, and "only users specified by a Fabric administrator can actually certify items"; and only those specified users can label an item as **Master data**, "the authoritative, single source of truth" for data such as customer lists [\[20\]](#ref-20). Promotion is a declaration by the author. Certification is the sign-off of a reviewer the organisation chose. In a governance programme, that sign-off is where the agreement can be checked. The land-grab works by letting the first be read as the second, and a governance programme that wants to resist it can start by refusing to let a promoted semantic model answer questions on the enterprise's behalf until someone with the authority to certify it has done so. Figure 3 draws the two routes. ![A unit's AI-drafted semantic layer goes from promoted, through agreement and certification, to answering for the enterprise. A dashed shortcut, the land-grab, goes from promoted straight to answering. Every label is written out below.](https://wi.senterprises.com/assets/diagrams/FIG015_AIBI_Declared_Is_Not_Agreed_v1_0.png) Figure 3: Promotion is the author's declaration; certification follows an agreement. The land-grab lets the first stand in for the second. **Declared is not agreed** A note across the top reads: A path, not a measurement: no count, share or outcome is shown. Below it, five boxes run from top to bottom, joined by solid arrows. **A business unit drafts a semantic layer**, noted **AI writes the declaration from the unit's own tables and query history**. Then **Promoted**, noted **its author says it is ready to share**. Then **Agreed**, noted **the owners of each term decide what it will mean across the enterprise**. Then **Certified**, noted **by a reviewer the organisation authorised**. Last, highlighted, **Answers questions for the enterprise**, noted **agents and chat windows are pointed at it**. To the right, a dashed arrow leaves **Promoted**, passes through a box headed **The land-grab**, noted in bold **first there, so read as the standard: agreement and certification skipped**, and enters **Answers questions for the enterprise** directly, bypassing Agreed and Certified. The difference between promoted and certified follows Microsoft Fabric's endorsement documentation [\[20\]](#ref-20). The path and the shortcut are this article's reading of the land-grab described above, not a measurement. The strongest objection to calling this a grab is that domain ownership of data is a design, not a usurpation. Zhamak Dehghani's data mesh argues that "the ownership and serving of the analytical data should respect these domains" [\[21\]](#ref-21), and I would not argue with a unit owning the definitions that are only its own. But the same design gives the decisions that cross domains to "the federation of domain data product owners and data platform product owners", who set "global rules", for one purpose: "creating interoperability" [\[21\]](#ref-21). A unit that declares its definitions to be the enterprise's has skipped the federation, which is the part that makes domain ownership safe. Where two units cannot agree, the enterprise chooses between their standards or sets one of its own above them; that choice is the enterprise's, and arriving first is not a vote in it. The market is also busy making declarations portable. Snowflake and others announced the Open Semantic Interchange in 2025 to address "the lack of a common semantic standard", with the aim of "a common, vendor-agnostic semantic model specification and query API" [\[22\]](#ref-22). A common format is useful. It also means that a unit's layer, once declared, travels into every tool that reads the format, carrying its definitions with it. Portability solves the problem of tools disagreeing; it does nothing about people disagreeing, and it makes whichever definition got there first harder to dislodge. Gartner expects that "boards will increasingly treat semantic governance as both a strategic risk and a competitive opportunity" [\[9\]](#ref-9). On the evidence of the land-grab, the risk will arrive first. Who settles it is the same as for definitions in general: the person with the authority and, more to the point, the power to enforce the decision decides, and the other groups live with it. What the land-grab changes is the timing. That decision used to be forced before the layer could be built, because building it was expensive. Now the layer can be built first, and the decider is presented with a definition already in use, already answering questions, already embedded in agents, and asked to ratify it. ## What to fund, in what order Pulled together, the ranking and the forecast give an order of spend that I would defend to a finance chief. Fund master data quality first, for the domains the questions will be asked about. It is the foundation, and it is the only investment on the list that makes answers more true rather than more consistent. If you need a measurement to justify it, commission one that checks your own records against reality for the questions that matter, and treat its findings as the work plan they will turn out to be. Let the machines write the declarations. The vendor tools that draft semantic models from schemas and query history are real and will improve, and there is no virtue in modelling by hand what a tool can draft for review. But point them at mastered records, and treat what they produce as a proposal. Keep the agreement and the certification with people who can enforce them. Before an AI-designed layer answers questions for the enterprise, someone with the authority to say what a term means across the enterprise has to have said so. Where the tooling separates promotion from certification, use the separation; where it does not, build it into the process. Expect the semantic layer to show you your master data errors, precisely. That is its value in this sequence. When it does, the records go to a steward, and no layer, however well written, takes that step away. ## Precision is the easy part Over the next decade the cost of declaring what a business's numbers mean will fall toward zero. The cost of making the records true will fall too, more slowly, as the routine parts of stewardship are automated. The cost of getting the owners of a definition to agree on it will not fall, unlike the others, and the market is already finding ways to step around it. Figure 4 sketches the three, as a concept and not as data. ![A concept chart, not data. From one starting point, the cost of declaring what a number means falls steeply, the cost of making the records true falls more slowly, and the cost of getting owners to agree stays level. Every label is written out below.](https://wi.senterprises.com/assets/diagrams/FIG016_AIBI_Three_Costs_Over_The_Decade_v1_0.png) Figure 4: Three costs over the next decade, as a concept and not as data. Declaring falls toward zero, making the records true falls more slowly, and getting the owners to agree does not fall. **Three costs over the next decade** A note across the top reads: Concept, not data: the curves show direction and relative speed only. No axis carries a number, and the curves share a starting point only so their shapes can be compared. Below it, one chart. The vertical axis is headed **Cost of the work** and the horizontal axis **The next decade**; neither carries a number. All three curves start at one marked point, labelled **Today**. A solid curve, labelled **Declaring what a number means**, noted **falls toward zero**, drops steeply and flattens near the bottom. A dashed curve, labelled **Making the records true**, noted **falls too, more slowly**, declines gradually and ends well above the first. A dotted line, labelled **Getting the owners to agree**, noted **does not fall**, stays level at the starting height. The shapes are this article's forecast, stated in its closing section, not a measurement. A natural-language system built on an AI-written semantic layer over unmastered records will be the most convincing wrong-answer machine an organisation has ever owned: fast, fluent, consistent in every tool, and traceable, with great exactness, to the records that made it wrong. I am usually brought in after a decision built on a confident answer has already been acted on, and the people who acted on it have gone. Precision will not prevent that; it will make the wrong answer more persuasive. The order I would fund is the one that makes the answers true first, and lets the machines make them consistent afterwards. ## References \[1\] JCGM (Joint Committee for Guides in Metrology), *International vocabulary of metrology — Basic and general concepts and associated terms (VIM)*, JCGM 200:2012, entry 2.13 "measurement accuracy", online edition. Read 2026-10-18 (the entry and its notes). Cited for the definition quoted in the body. \[2\] JCGM, *International vocabulary of metrology (VIM)*, JCGM 200:2012, entry 2.15 "measurement precision", online edition. Read 2026-10-18 (the entry, its notes and the 2014 annotation). Cited for the definition and Note 4 quoted in the body. \[3\] dbt Labs, "dbt Semantic Layer," dbt Developer Hub, updated 29 September 2026\. Read 2026-10-18\. Vendor documentation (dbt Labs sells the Semantic Layer it describes). Cited for the three passages quoted in the body and for what the page does not claim. \[4\] Databricks, "Unity Catalog metric views," Databricks on AWS documentation, updated 11 September 2026\. Read 2026-10-18\. Vendor documentation. Cited for the phrases quoted in the body. \[5\] Jinyang Li, Binyuan Hui, Ge Qu and others, "Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs," arXiv:2305.03111, v3, 15 November 2023 (NeurIPS 2023 Datasets and Benchmarks). Read 2026-10-18 (abstract). Cited for the benchmark's scope and the 40.08% and 92.96% figures. \[6\] BIRD-bench leaderboard, "BIRD-SQL." Read 2026-10-18; a live page that changes. Cited for the "dirty" values sentence quoted in the body and the top test-set execution accuracy on the day read (82.95%, 26 September 2026 entry). \[7\] Cedric Renggli, Ihab F. Ilyas and Theodoros Rekatsinas, "Fundamental Challenges in Evaluating Text2SQL Solutions and Detecting Their Limitations," arXiv:2501.18197, 30 January 2025\. Read 2026-10-18 (abstract; the point that several valid queries can answer one question comes from the paper body, read via the PDF the same day). Cited for the two evaluation problems the body describes (data quality of the evaluation sets, and imperfect match functions) and for the one phrase quoted. \[8\] Sedat Bin Vedat, Enes Kutay Yarkan, Meftun Akarsu and others (Hagia Labs), "RAG-Driven Data Quality Governance for Enterprise ERP Systems," arXiv:2511.16700, 18 November 2025\. Read 2026-10-18 (the HTML edition). A preprint describing the authors' own system at one unnamed organisation; no venue stated. Cited for the deployment's design, the ablation sentence and the sentence on acceptable performance quoted in the body, the deployment table's schema-compliance figure (Table IV, read 2026-10-20), and the 97.8% sample correction rate. \[9\] Gartner, "Gartner Says Lack of Semantics Causes Inaccurate AI Agents and Wasted Spending," press release, 11 May 2026 (Rita Sallam). Read 2026-10-18\. Predictions; the release states no method. Cited for the two predictions and the boards expectation quoted in the body. \[10\] Tadhg Nagle, Thomas C. Redman and David Sammon, "Only 3% of Companies' Data Meets Basic Quality Standards," *Harvard Business Review*, 11 September 2017\. Read 2026-10-18\. Cited for the method described in the body and the finding quoted; 75 executives' self-assessed scores, 100 records each. \[11\] Snowflake, "Semantic View Autopilot," Snowflake documentation. Read 2026-10-18\. Vendor documentation. Cited for the two passages quoted in the body and the query-history input. \[12\] dbt Labs, "dbt Copilot," dbt Developer Hub, updated 1 September 2026\. Read 2026-10-18\. Vendor documentation. Cited for the sentence quoted in the body. \[13\] Microsoft, "Write DAX queries with Copilot," DAX documentation, Microsoft Learn, updated 10 December 2024\. Read 2026-10-18\. Vendor documentation (Microsoft is aligned with our partner). Cited for the phrase quoted in the body. \[14\] Gartner, "Gartner Announces Top Predictions for Data and Analytics in 2026," press release, 11 March 2026\. Read 2026-10-18\. Predictions; the release states no method. Cited for the two predictions quoted in the body. \[15\] David Autor, "Polanyi's Paradox and the Shape of Employment Growth," NBER Working Paper 20485, September 2014\. Read 2026-10-18 (abstract). Cited for the three passages quoted in the body. \[16\] Ralph Peeters, Aaron Steiner and Christian Bizer, "Entity Matching using Large Language Models," arXiv:2310.11244, v4, 18 October 2024\. Read 2026-10-18 (abstract). Cited for the three phrases quoted in the body. \[17\] Avanika Narayan, Ines Chami, Laurel Orr, Simran Arora and Christopher Ré, "Can Foundation Models Wrangle Your Data?," arXiv:2205.09911, v2, 24 December 2022 (VLDB 2023). Read 2026-10-18 (abstract). Cited for the two phrases quoted in the body. \[18\] Kimball Group, "Conformed Dimensions," Kimball Dimensional Modeling Techniques. Read 2026-10-18\. Cited for the phrase quoted in the body. \[19\] Vijay Khatri and Carol V. Brown, "Designing Data Governance," *Communications of the ACM* 53(1), January 2010\. Read 2026-10-18 (the CACM web edition, which does not print the authors or issue; those are from the print citation). Cited for the two phrases quoted in the body. \[20\] Microsoft, "Endorsement overview," Microsoft Fabric documentation, Microsoft Learn, updated 11 July 2024\. Read 2026-10-18\. Vendor documentation (Microsoft is aligned with our partner). Cited for the passages quoted in the body. \[21\] Zhamak Dehghani, "Data Mesh Principles and Logical Architecture," martinfowler.com, 3 December 2020\. Read 2026-10-18\. Cited for the passages quoted in the body. \[22\] Josh Klahr, Khushboo Bhatia and Nick El-Rayess, "Snowflake Unites Industry Leaders to Unlock AI's Potential with the Open Semantic Interchange Initiative," Snowflake blog, 23 September 2025\. Read 2026-10-18\. Vendor page. Cited for the two phrases quoted in the body (the first is Christian Kleinerman's, as the post quotes him).