What the Model Cannot Infer: Semantic Layers, Master Data and Readiness for AI-Assisted Decisions

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

When someone types a question about the business into a BI tool and an answer comes back, the conversation about it tends to start with the model: which one, how large, how recent. I start somewhere else, with the path the question travels. Asked where master data sits in that path, I answered with one line:

Data -(Mastering Process)> Master Data -(Semantic Layer)> Reporting and AI Systems

Read the arrows as the work. Raw data becomes master data through the mastering process. Master data reaches the people and the machines that use it through the semantic layer. And reporting and AI systems sit together at the end of the same chain. The AI system does not get a road of its own to the data. It reads what a report reads, through the same layer, over the same mastered records.

That one line carries the whole argument of this piece. A natural-language answer is only as good as the two steps in front of it, and the model is the last and least decisive thing in the path. If the mastering has not happened, the semantic layer is defining terms over duplicates. If the semantic layer is incomplete, the model is guessing at what the business means. Neither fault is the model's, and no model, however capable, repairs either of them from where it sits.

I have argued before that a semantic layer is a translation, not an honesty layer, in The Number Was Never Doing the Work, and that an agent needs nothing from master data that a well-served analyst does not, in Ideally, Nothing. This piece puts the two together and asks three questions: where it breaks, what the layer has to carry, and what tells you an organisation is not ready.

Where it breaks

Asked where the path fails, my answer was short:

The semantic layer sits between the agent and the data. It tends to break when the semantic layer is incomplete, wrong or configured improperly.

The answer locates the failure in the layer, not the model, and the research on question answering over enterprise data has been converging on the same place for three years.

The early measurement is Juan Sequeda, Dean Allemang and Bryon Jacob's benchmark over an enterprise SQL schema in the insurance domain. Put to GPT-4 with zero-shot prompts directly over the SQL database, its questions were answered with an accuracy of 16%; posed over a knowledge graph representation of the same database, the same questions reached 54% [1]. Six months later Allemang and Sequeda added an ontology-based check that caught faulty queries and had the model repair them, and reported overall accuracy of 72% with a further 8% of answers returned as "I don't know", an error rate of 20% [2]. The model did not change between those results. What changed was how much of the business's meaning sat between the model and the tables.

The cleanest recent test of that is Michael Rumiantsau and Ivan Fokeev's, published in April. They put a hundred questions about a retail dataset to three current frontier models, each twice: once with the warehouse schema alone, and once with the schema plus a four-kilobyte document "describing the dataset's measures, conventions, and disambiguation rules" [5]. The document added 17 to 23 percentage points for every model. Without it the three models were statistically indistinguishable at 45.5 to 50.5%; with it they were indistinguishable again, at 67.7 to 68.7%. Their summary is the sentence I would have written: "The presence of the semantic-layer document accounts for essentially all of the significant variance; model choice within tier does not" [5]. They also name the cause of the failures in terms that match mine: the model "is forced to infer business semantics that the schema does not encode" [5].

A disclosure before the vendors speak, because what follows assesses their 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 and of Profisee, whose chief data officer is quoted below: weigh anything favourable I say about either below my criticism of them. Profisee is aligned with Microsoft's data platform, so the same interest runs toward Microsoft's products; weigh what I say in their favour with that in mind. Google's Looker competes with Microsoft's Power BI, and Snowflake and Databricks sell data platforms that compete with Microsoft's, which gives me a reason to be hard on all three; discount my criticism of them accordingly.

The vendors say the same about their own products. Google reports that its internal testing found Looker's semantic layer "reduces data errors in gen AI natural language queries by as much as two thirds", and warns that "When applied directly to ungoverned data, gen AI can produce impressive, but fundamentally inaccurate and inconsistent results" [12]. Snowflake's documentation for its natural-language analyst says generic AI solutions "often struggle with text-to-SQL conversions when given only a database schema, as schemas lack critical knowledge like business process definitions and metrics handling" [8]. Those are vendors describing why their own semantic products are needed, and they should be read as that.

The case that the model is catching up

The strongest objection is that this is a snapshot, and the models are moving faster than any semantic layer is being built.

It has evidence. dbt Labs, which sells a semantic layer and so has an interest in this result, re-ran eleven of the Sequeda benchmark's questions, twenty times each, this spring with current models. Text-to-SQL with no semantic layer "nearly doubled, from 32.7% to 64.5% on the full question set", and the post concedes in bold that "Models are getting much better at text-to-SQL" [6]. Spider 2.0, a benchmark built from enterprise workflows, launched in 2024 with its authors' own agent, built on o1-preview, solving "only 21.3% of the tasks" [3]; on the narrower Snowflake setting its leaderboard now shows agents above 96, and on the Lite setting above 76 [4]. If models are closing the gap that quickly, the argument for spending months on a semantic layer weakens every quarter.

Two details in the same sources keep the gap open. The first is what the leaderboard is measuring. The setting with the 96s is described as "a self-contained text-to-SQL task that includes well-prepared database metadata and documentation" [4]. Those agents were handed prepared metadata and documentation, the raw material a semantic layer is built from, and the leaderboard shows what models do with it, not what they do from a bare schema.

The second is in dbt's own table. On the questions the semantic layer was modelled to answer, both current models scored 100% through it, against 51.2% and 62.5% writing SQL directly [6]. On questions outside what had been modelled, the semantic layer scored zero, because it returns an error rather than a guess. dbt states the trade plainly: "the Semantic Layer can only answer questions that fall within the scope of what's been modeled" [6]. Then it names the difference that matters to anyone acting on an answer: "With text-to-SQL, failure looks like a plausible but incorrect answer. With the Semantic Layer, failure looks like an error message" [6]. On the out-of-scope questions, text-to-SQL answered 70% and 100% correctly, which is real; the difference is that a wrong answer there would have looked exactly like a right one. dbt's headline figures come after a further step, taken up in the next section: an LLM wrote three new models, and with those in place text-to-SQL reached 90.0% and 84.1% against 98.2% and 100% through the semantic layer [6].

That is my position with its edge sharpened, not its defeat. Models have got much better at writing SQL. Nothing published shows them recovering what the business means by a number without being told, and the one measurement that holds the model fixed and varies only the business semantics shows the semantics doing the work [5]. An incomplete layer does not make the model worse. It makes the model's guesses invisible, because a plausible wrong number looks exactly like a right one. I am usually brought in after the decision that number fed, which is a poor vantage point from which to admire fluency.

That position can be proved wrong, and it says how: if a model given only the schema ever matches one given the business's semantics, the claim falls. Rumiantsau and Fokeev ran that comparison on three current models over a hundred retail questions, with the business's measures, conventions and disambiguation rules as the only variable, and found the gap where the claim says it should be [5]. On the evidence published this year, it has not closed. The practical rule follows from dbt's coverage trade: ask the layer the questions it models, and treat any answer from outside them as unverified until someone has written down what the right answer would be.

Where the meaning has to come from

From here the argument rests more on my own experience than on measurement: what a semantic layer has to carry, and why.

What does the layer have to hold that no model can work out for itself, however good it gets? My answer named the thing itself and then what I would want tied to it:

What the data actually is and what it means. Ideally there would be a tie-in with the Data Catalogue as well which would contain lineage, calculations, derivations, sanity checks (valid domain) and, most importantly why it was calculated and generated the way it was as well as what business purpose the data serves.

Two layers of answer are in that, and they are not equally contestable. The first is what the data is and what it means. The second is the catalogue: where a value came from, how it was calculated and derived, what range of values is valid, and, ranked above the rest, why it was calculated that way and what business purpose it serves. "Ideally" is doing real work in that sentence. I do not claim most organisations have the catalogue joined to the layer. I claim it is what the layer should carry, because the model has no other way to get it.

The case that the model can write the layer

The first half of that answer is under real pressure, and I would rather meet it than pretend otherwise.

Niklas Wretblad and colleagues had language models write descriptions of the columns in a public text-to-SQL benchmark, and found that "incorporating such generated column descriptions consistently enhances text-to-SQL model performance"; more striking, one model's descriptions "outperform manually curated gold descriptions, suggesting that models benefit from more detailed metadata than humans expect" [7]. Snowflake now sells a feature that builds semantic views for you: it "uses clustering algorithms that analyze query patterns and natural language questions to identify consensus business logic", and moves the work "from coding into curation" [9]. If a model can write the descriptions and infer the consensus definitions, then "what the data is" is something a model can, increasingly, work out.

I concede that part. A model reading column names, sample values and a few years of query logs will recover a good deal of what a column holds and how people usually aggregate it. Where the definitions are plain, it may do it better than a tired analyst writing descriptions at the end of a project.

What the same sources do not claim is the part I ranked first. Wretblad's team found the models "struggle with columns that exhibit inherent ambiguity, highlighting the need for manual expert input" [7]. Snowflake's feature finds consensus by reading what people already did, and says where it looks hardest: "The highest-confidence source is often existing BI dashboards, where years of business logic already live" [9]. That is inference from definitions somebody already wrote. It can find the most common way revenue has been calculated. It cannot find out why the business chose that way, whether the choice still holds, or which of two competing calculations the finance team would sign. Those facts live in decisions, not in data, and a model reading the data has nothing to read them from. The long history of asking data questions in English says the same: The Vocabulary Outlived the Interface found that across fifty years no interface removed the need for somebody to write down what the business's words meant. dbt's own update makes the same point from the other side: with three models an LLM wrote, joining tables the benchmark already defined, text-to-SQL rose to 90.0% and 84.1% and the semantic layer to 98.2% and 100% [6]. A model can write the plumbing of a layer, and that closes most of the gap on questions whose definitions nobody disputes; none of those eleven questions asked it to decide which definition was right, or why. Databricks puts the human role in a sentence: "The curator's job is to bridge the gap between Genie's general world knowledge and the specialized language used in a specific domain or company" [10]. Microsoft's guidance for Copilot says that "When data is unstructured or ambiguous, AI systems can struggle to correctly interpret it. Outputs might be generic, inaccurate, or even misleading", and adds that its preparation features cannot guarantee an outcome because "AI behavior is nondeterministic" [11].

There is a second reason the "why" matters, and it comes from my own earlier position. I have called semantic layers anything but honest: an overlay of aliases and abstractions that recasts the data into the form its consumer prefers, and that presents curated stories as facts (The Number Was Never Doing the Work argued it at length). I still hold that. The catalogue tie-in is the answer to it, not a retreat from it. A translation that carries its lineage, its derivation, its valid domain and its reason can be inspected; a reader can see the curation and decide whether to trust it. A translation that carries none of that is the curated story with the label removed. Put a model in front of the second kind and the story is retold fluently, at scale, to people who were never told it was a story.

So the position, stated precisely, is this. A model can increasingly infer what the data is. It cannot infer what the business decided it should mean, or why, because that was never written into the data. A semantic layer that holds only the first is a layer a model could have written for itself, which is the reason it adds little.

Where master data sits

The chain at the top of this piece puts the semantic layer over master data, not beside it, and that is the claim in this piece most likely to be disputed by people who build these products.

The vendor documentation does not require it. Snowflake's semantic views are built from "Logical tables that represent business entities (such as customers, orders, or products)", dimensions, facts, metrics and the relationships that join them [8], and nothing on that page asks whether the customer table has been mastered. None of the other semantic-layer vendor pages cited here ([9], [10], [11], [12]) asks for it either: the layer is defined over whatever tables the warehouse holds. A semantic layer over raw source tables works, in the narrow sense that it runs.

The more serious objection comes from a vendor on the other side of the stack. Atlan, which sells a metadata catalogue, argues that master data and the context layer are peers: "A golden record alone doesn't solve this: an agent still needs to know what the resolved entity's data means before it can act on it", and "Neither answer alone is enough" [17]. On the first point it is right, and it is the point of the previous section. Where I part from it is order. "Neither alone is enough" describes two things that are both needed. My chain says one feeds the other, and the order matters for a reason the peer model hides: a semantic layer defines its terms over records, and a term defined over unmastered records counts the duplicates.

Take the simplest definition a semantic layer holds: the number of active customers. Define it over three source systems, each holding its own copy of the customer, and the layer will give an answer that is consistent, repeatable and wrong, because the same customer appears three times under three spellings. Every consumer of the layer, the dashboard and the agent alike, inherits the count. Nothing the model does can correct it, because the model sees the layer's definition and has no way to know the records beneath it overlap. Gartner's definition of the discipline names the property at stake: master data management exists to ensure "the uniformity, accuracy, stewardship, governance, semantic consistency and accountability of the enterprise's official shared master data assets" [18]. Semantic consistency is in the definition of mastering, before any semantic layer is built.

Profisee's chief data officer, Malcolm Hawker, puts the division of labour in one line: "The ground truth provided by MDM tells you which customers are real" [16]. He is our partner's executive making the case for our partner's category, so discount it as I asked above; I quote it because it is the clearest statement of the distinction, not because it proves it. The proof is the arithmetic of the duplicate customer, which needs no vendor.

That is also why reporting and AI sit at the same end of the chain. An agent asking the layer a question needs nothing from master data that an analyst asking the same layer does not. I said as much when asked what agentic AI changes about trusted master data, and the short answer was that, ideally, it changes nothing (Ideally, Nothing carries the full argument and its costs). A separate path for the AI system, built straight to the source tables because the warehouse team was slow, is the most common way I would expect this chain to be broken in practice: the report and the agent end up reading different records, and the next section describes what happens when they do.

Drawn out, the chain is a sequence with two places to fail, and both of them are upstream of the model.

The tell

Organisations ask what to buy to become ready for AI-assisted decisions. Asked the other way round, what tells me an organisation is not ready whatever it has bought, my answer had nothing to do with tools:

Multiple definitions for the same data element in multiple systems that refuse to agree on a standard or coexist. With that level of in-fighting, attempting to add AI is a recipe for a conflagration rather than convergence.

The words that carry it are "refuse to agree on a standard or coexist", and both halves matter. Multiple definitions are not the problem on their own. I have said before that semantic layers will often give different answers to different groups, because each group reports and categorises to its own requirements, and that the trouble starts only when those groups compare notes and the answers conflict (The Number Was Never Doing the Work carries that argument). A sales count of customers and a finance count of customers can both be right if each is defined, named for what it is, and reconciled with the other. That is coexistence, and it is a perfectly governable state. The tell is the refusal: two definitions of one element, each defended by a group that will neither adopt a standard nor accept that the other exists alongside it.

The reason that refusal disqualifies an organisation for as long as it lasts, and not merely slows it, is in the chain. The semantic layer has to hold one definition of each term it exposes, or several clearly labelled ones. An organisation whose definitions are in open conflict cannot write that layer, because writing it means deciding the dispute, and the dispute is exactly what nobody with the power to settle it has yet settled. Put a model on top and it does not stay neutral. It picks one definition, or blends them, or chooses differently on different days, because, as Microsoft's own documentation says, its behaviour is nondeterministic [11]. Each side then gets an answer the other side rejects, delivered with the authority of the machine. That is the conflagration.

The industry has noticed the symptom. In September 2025 Snowflake, Salesforce, dbt Labs and others announced the Open Semantic Interchange, on the premise that "Today, every tool interprets business metrics and metadata differently — causing confusion, slowing adoption, and eroding trust in AI-driven insights" [13]. Gartner, this spring, predicted that "by 2027, organizations that prioritize semantics in AI-ready data will increase their agentic AI accuracy by up to 80% and reduce costs by up to 60%", and that "Traditional schema-based data models alone no longer suffice for agentic AI because they lack business context and data meaning" [14]; in March it called developing a universal semantic layer "a must‑do for D&A leaders either leading or supporting AI" [15]. Neither release states a method, and both are forecasts or advice, but they point at the same place this piece does.

What none of them can do is the thing the tell is about. An interchange standard makes definitions portable between tools; it does not make two departments agree on one. A universal semantic layer is a container for decisions, and if the decisions have not been made, the container is empty or, worse, filled by whoever got to it first. Those are tools, and the tell is precisely the case where tools do not help. The fix is a governance decision, made by someone with the authority to make it and the power to enforce it, and that is why it shows up as in-fighting and not as a missing feature.

Who makes that decision, when the groups will not? Asked exactly that, I answered:

This is stupidly axiomatic, but, the 'decider' decides. What I mean by that is the person with the authority and, more importantly, the enforcement power is the one who makes the ultimate decision and the other group(s) have to deal with and accept it.

The axiom is the point, and the sentence that carries it is the second one. Authority on paper is not enough; the decider is the person who holds the authority and, more than that, can enforce it, and the other groups live with it. A definition approved by someone who cannot make it stick is not a settlement, only one more version in the argument. For the semantic layer, that settles what the layer encodes. It holds the definition the decider chose, labels any others the decider allows to coexist, and holds no other definition, and the model reads that and nothing else. An organisation is not ready for AI-assisted decisions until that has happened, before the model is switched on, and it stays unready while the decision is still waiting for someone with the power to enforce it.

What to check before the first question

These are not steps in an order. They are questions to put to an estate before anyone asks it a question in English.

Does the AI system read through the same semantic layer as reporting? If it has its own route to the source tables, the report and the agent will disagree, and the agent will be believed.

Is the semantic layer defined over mastered records? If "customer" means three source tables joined, every count built on it includes the duplicates mastering exists to remove.

For each term the layer exposes, can someone say what it is, what it means and why it was defined that way? The first two a model can increasingly help write. The third only the business can supply, and it is the one that makes the layer inspectable.

Where two groups define the same element differently, are the definitions labelled and reconciled, or contested? Labelled and reconciled is coexistence and can be governed. Contested is the tell.

When the layer cannot answer, does it say so? A refusal is a better failure than a plausible wrong number, and a design that falls back to the model writing its own SQL has chosen the second.

Under the hood

The phrase "AI-assisted decision making" puts the model at the centre, and most of the discussion follows it there. Under the hood the model is the last step in a chain, and the two steps before it decide what it can say. Mastering decides which records are real. The semantic layer decides what they mean. The measurement that holds the model fixed shows the layer accounting for essentially all of the significant variance, and the measurements that show models improving show them improving at writing SQL over meaning someone has already written down, not at supplying it.

A model will keep getting better at writing SQL and at describing what a column seems to hold. It will not get better at knowing why the business defined a number the way it did, because that reason was never in the data, and it cannot settle a dispute about a definition that the business itself refuses to settle. An organisation is not ready for AI-assisted decisions until it has made those decisions itself and written them down where the model can read them, over records it has mastered. Until then, whatever it has bought, the model will only make the disagreement louder.

References

[1] Juan Sequeda, 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, 13 November 2023. Read 2026-10-07 (abstract) through a rendering fetch; not stored locally. Cited for the 16% and 54% figures quoted in the body; the model is GPT-4 and the schema a single insurance database, so the numbers are an early measurement, not current accuracy. https://arxiv.org/abs/2311.07509

[2] Dean Allemang and Juan Sequeda, "Increasing the LLM Accuracy for Question Answering: Ontologies to the Rescue!," arXiv:2405.11706, 20 May 2024. Read 2026-10-07 (abstract) through a rendering fetch; not stored locally. Cited for the 72% accuracy, 8% "I don't know" and 20% error-rate figures. https://arxiv.org/abs/2405.11706

[3] Fangyu Lei, Jixuan Chen, Yuxiao Ye and others (corresponding author Tao Yu), "Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows," arXiv:2411.07763, November 2024, revised March 2025. Read 2026-10-07 (abstract) through a rendering fetch; not stored locally. Cited for the 21.3% launch result quoted in the body. https://arxiv.org/abs/2411.07763

[4] Spider 2.0 leaderboard, XLANG Lab. Read 2026-10-07 through a rendering fetch; a live page that changes. Cited for the Snow setting description quoted in the body ("a self-contained text-to-SQL task that includes well-prepared database metadata and documentation", 547 examples; the Lite setting carries the same description) and for the top scores on the day read: Spider 2.0-Snow 96.70 and 96.53; Spider 2.0-Lite 76.23. The 21.3% launch result in [3] is on the original agentic setting, not on Snow or Lite. https://spider2-sql.github.io/

[5] Michael Rumiantsau and Ivan Fokeev, "Semantic Layers for Reliable LLM-Powered Data Analytics: A Paired Benchmark of Accuracy and Hallucination Across Three Frontier Models," arXiv:2604.25149, 28 April 2026. Read 2026-10-07 (abstract, in full) through a rendering fetch; not stored locally. Cited for the design, the 17-23 point gain, the two accuracy bands and the two sentences quoted in the body. One dataset (Contoso retail) and 100 questions. https://arxiv.org/abs/2604.25149

[6] Jason Ganz and Benoit Perigaud, "Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update," dbt Labs blog, 7 April 2026. Read 2026-10-07 through a rendering fetch; not stored locally. dbt Labs sells a semantic layer. Cited for the headline table (with three LLM-written models: text-to-SQL 90.0% Sonnet 4.6 and 84.1% GPT-5.3 Codex; semantic layer 98.2% and 100.0%) and the earlier results table (text-to-SQL 32.7% in 2023 to 64.5% on the full set; in scope, semantic layer 100% against 62.5% and 51.2% for text-to-SQL; out of scope, semantic layer 0% against 70.0% and 100.0%), and the sentences quoted in the body. Eleven questions from the ACME Insurance benchmark of [1], twenty runs each. https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026

[7] Niklas Wretblad, Oskar Holmström and others (Linköping University), "Synthetic SQL Column Descriptions and Their Impact on Text-to-SQL Performance," NeurIPS 2024 Workshop (TRL); arXiv:2408.04691, current version (earlier versions carry a different title and abstract). Read 2026-10-07 (abstract of the current version, in full) through a rendering fetch; not stored locally. Cited for the three findings quoted in the body. https://arxiv.org/abs/2408.04691

[8] Snowflake, "Cortex Analyst," Snowflake documentation. Read 2026-10-07 through a rendering fetch; not stored locally. Vendor documentation. Cited for the sentence quoted on generic tools and for the listed contents of a semantic view. https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst

[9] Abhinav Vadrevu and Nick El-Rayess, "Snowflake Semantic View Autopilot: AI-Powered Semantic Modeling in Minutes," Snowflake blog, 3 February 2026. Read 2026-10-07 through a rendering fetch; not stored locally. Vendor page. Cited for the three phrases quoted in the body. https://www.snowflake.com/en/blog/semantic-view-autopilot/

[10] Databricks, "Curate an effective Genie Agent," Databricks documentation, updated 8 July 2026. Read 2026-10-07 through a rendering fetch; not stored locally. Vendor documentation. Cited for the sentence quoted in the body. https://docs.databricks.com/aws/en/genie/best-practices

[11] Microsoft, "Prepare your data for AI to improve Copilot results (preview)," Power BI documentation, Microsoft Learn, updated 30 May 2026. Read 2026-10-07 through a rendering fetch; not stored locally. Vendor documentation (Microsoft is aligned with our partner). Cited for the two passages quoted in the body. https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-prepare-data-ai

[12] Richard Kuzma and Jesse Sherb, "How Looker's semantic layer enables trusted AI for business intelligence," Google Cloud blog, 7 May 2025. Read 2026-10-07 through a rendering fetch; not stored locally. Vendor page; the two-thirds figure is the vendor's own internal testing, with no method published. Cited for the two sentences quoted in the body. https://cloud.google.com/blog/products/business-intelligence/how-lookers-semantic-layer-enhances-gen-ai-trustworthiness

[13] Snowflake, "Snowflake, Salesforce, dbt Labs, and More, Revolutionize Data Readiness for AI with Open Semantic Interchange Initiative," press release via Business Wire, 23 September 2025. Read 2026-10-07 through a rendering fetch; not stored locally. Cited for the sentence quoted in the body. https://www.businesswire.com/news/home/20250923902448/en/Snowflake-Salesforce-dbt-Labs-and-More-Revolutionize-Data-Readiness-for-AI-with-Open-Semantic-Interchange-Initiative

[14] Gartner, "Gartner Says Lack of Semantics Causes Inaccurate AI Agents and Wasted Spending," press release, 11 May 2026 (Rita Sallam). Read 2026-10-07 through a rendering fetch; not stored locally. A prediction; the release states no method. Cited for the two sentences quoted in the body. https://www.gartner.com/en/newsroom/press-releases/2026-05-11-gartner-says-lack-of-semantics-causes-inaccurate-artificial-intelligence-agents-and-wasted-spending

[15] Gartner, "Gartner Announces Top Predictions for Data and Analytics in 2026," press release, 11 March 2026 (Rita Sallam quoted). Read 2026-10-07 through a rendering fetch; not stored locally. Cited for the phrase quoted in the body. https://www.gartner.com/en/newsroom/press-releases/2026-03-11-gartner-announces-top-predictions-for-data-and-analytics-in-2026

[16] Malcolm Hawker, "The Smartest AI Company on Earth Just Rebuilt Master Data Management (Without Realizing It)," Profisee blog, 6 August 2026. Read 2026-10-07 through a rendering fetch; not stored locally. Vendor page (the vendor we partner with). Cited only for the sentence quoted in the body, as a statement of position; the post's account of another company's internal work is not relied on and was not verified. https://profisee.com/blog/the-smartest-ai-company-on-earth-just-rebuilt-master-data-management-without-realizing-it/

[17] Emily Winks, "Reltio vs Atlan: MDM and the Context Layer Compared [2026]," Atlan, 4 September 2026, updated 18 September 2026. Read 2026-10-07 through a rendering fetch; not stored locally. Vendor page (Atlan sells a metadata catalogue). Cited for the two sentences quoted in the body. https://atlan.com/know/ai-agent/reltio-vs-atlan/

[18] Gartner, "Master Data Management: Definition, Process, Framework and Template," Gartner topic page, undated. Gartner's former glossary address for MDM now redirects here; the definition quoted in the body appears on this page, in its FAQ "What is master data management?". Read 2026-10-07 through a rendering fetch; not stored locally. https://www.gartner.com/en/data-analytics/topics/master-data-management