Point a capable model at a warehouse, hand it a business question, and it will answer. That is the part people notice in a demo. The part they miss is whether the answer is right, and whether anyone in the room could tell if it weren't.
For most of the last thirty years, someone could tell. An analyst would look at a number that felt off, frown, and quietly fix the join, or remember that the Oslo office books revenue a day later than London, or know that "active customer" means one thing in the report and something narrower in the board pack. None of that correction was written down. It lived in the analyst's head, in the gap between the query and the slide. do not have that head. They have the schema, the column names, and whatever you bothered to write down.
The argument is the opposite of the current instinct: AI raises the value of data modelling, it doesn't lower it. The better models get at turning a question into , the more the answer depends on the thing underneath (the structure, the definitions, the history, the rules) and the less it depends on a person silently catching the interpretation before it reaches anyone who matters.
That runs against the mood of the moment, which is roughly "the model figures it out." So it's worth making the case properly, starting further back than usual.
A short history, told for a reason
We did not always shape data for analysis. The first production databases were built to run a business, not to study it. IBM's IMS, written for the Apollo program in the late 1960s, was hierarchical: data hung off parent records in a tree, and to get anywhere you walked the tree pointer by pointer . The network databases that competed with it let records have multiple parents, which helped, but you still navigated the structure by hand.
Then in 1970 Edgar Codd, also at IBM, published a paper proposing that data be organised as relations (tables) with the logical structure separated from how it was physically stored . You asked for what you wanted and the system worked out how to get it. That idea won so completely that two generations of practitioners now treat it as the natural state of the world rather than an invention.
The three families of data model, simplified. Hierarchical and network databases made you walk the structure; the relational model let you ask for what you wanted. Author's illustration.
Relational databases were still built for transactions, though. The shift to modelling for analysis came later, and it had two camps. Bill Inmon defined the around 1990 and laid it out in Building the Data Warehouse in 1992: a subject-oriented, integrated, time-variant, non-volatile store, built to hold history and reconcile data across the business . Ralph Kimball's The Data Warehouse Toolkit arrived in 1996 with a different emphasis (, facts and conformed dimensions, the bus matrix) optimised for how people ask analytical questions . In 2000 Dan Linstedt published , with hubs, links, and satellites, putting auditability and resilience to source change ahead of everything else .
Dates: Codd (1970) [R1]; Inmon, Building the Data Warehouse (1992) [R3]; Kimball, The Data Warehouse Toolkit (1996) [R4]; Linstedt's first Data Vault articles (2000) [R5].
Inmon, Kimball, and Linstedt argued with each other for decades, and consultancies built whole identities on which camp they belonged to. But step back and the three methods agree on almost everything that matters. All of them keep history on purpose. All of them integrate data from multiple sources into shared concepts. And each treats the meaning of a column as something you decide deliberately, not something you discover by reading the column name. They disagree on the shape; they agree on the discipline.
That agreement is what's quietly eroding. Over the last five to ten years, data work got popular, which is good, and a lot of new practitioners arrived from software engineering, which is mostly good. They brought version control, testing, code review, and the idea that a pipeline is software and should be treated like software. made a generation of analysts comfortable with all of that. I don't want any of it back in the box.
What came with it, in some teams, was a thinner relationship to the data itself. If your instinct is to ship the code, the model is just a means to an end, and the fastest path is a fresh table that answers today's question. Cloud storage being cheap and schemas being easy to change removed the friction that used to force a decision. So instead of one integrated warehouse with conformed dimensions and honest history, you get forty loosely related datasets that each looked reasonable on the day they were built. Nobody decided to abandon integration. It just never happened, one reasonable shortcut at a time.
The trouble is how invisible the loss is. A poorly modelled warehouse doesn't fall over. It runs fine, returns numbers, and passes its tests. The cost shows up two years later when nobody can say which of the three "revenue" definitions the executive dashboard relies on, and the person who knew has left.
Why analytics is modelled differently in the first place
It helps to remember why we ever bothered to model data twice: once for running the business, once for understanding it.
A transaction system is tuned for safe, fast writes. You normalise so that every fact lives in exactly one place, because if a customer's address exists in five tables you will eventually update four of them. The design goal is consistency under change, and it usually throws history away: when an order ships, the row updates, and the previous state is gone unless someone deliberately kept it.
An analytical model wants the opposite things. It wants to answer "what was true at the end of last quarter," "how does this region compare with that one on the same definition," and "what changed between then and now". It wants to do that fast over large aggregates. That pushes you toward denormalised facts, dimensions you can slice by, conformed keys so two systems agree on what a customer is, and that keep old states around on purpose. The warehouse exists precisely to hold the history the transaction system discarded and to make separate systems speak a common language.
The same business, modelled twice. On the left, third normal form spreads a fact across many small tables so no value is stored in two places. On the right, the star pulls measures into one fact table and pushes descriptive context into dimensions. Author's illustration.
This is the bit that gets skipped when speed is the only virtue. If you point analytical questions at transaction-shaped tables, you can get answers, but you inherit every ambiguity the operational systems never had to resolve, because they never had to compare themselves to anything.
The "it'll figure it out" misconception
The pitch for natural-language analytics is that the model reads your tables and just works it out. On a clean schema, it nearly does. On a real one, the gap is larger than the demos suggest, and the numbers are public.
The standard test here is BIRD, a of natural-language questions against messy, real-world databases. Human experts score about 93% execution accuracy (they write SQL whose results match the intended answer) while the top leaderboard systems have long sat around 75%, the very best only recently nudging past 80% . And the benchmark's strict scoring is itself contested: the FLEX analysis (NAACL 2025) found that BIRD's execution-accuracy grading agrees with expert human judgment only about 62% of the time, mostly rejecting answers a person would have accepted . So the true gap is fuzzier than any single number, but it is real and it is not small.
| Human expert | Best systems | Strict grade vs. human |
|---|---|---|
| ~93% | ~75% to low-80s% | agree ~62% |
| execution accuracy on BIRD | top of the leaderboard, 2025–26 | strict scoring disagrees ~38% of the time |
Execution accuracy compares the result set of generated SQL against a reference query.
The more useful finding is buried in the same work. The schemas these systems handle best are the ones that are already well modelled: mostly one-to-many joins, two or three hops deep, no many-to-many tangles, and tables and columns with descriptive names. 's own 2026 analysis makes the point directly: hit ~95% practical accuracy on a clean, well-named schema with no at all . In other words, the model performs where a human modeller has already done the hard part. Where the schema is ambiguous (the exact place you most wanted help), performance falls.
text-to-SQL works best on schemas that were already modelled well. The technique doesn't remove the need for a good model; it rewards one and punishes its absence.
There's a 2026 strand of results that makes the point almost too neatly. Audits of BIRD found annotation errors in over half of the examples checked, and the systems that finally reached human-level accuracy did it less by being cleverer agents than by curating a verified dataset and retraining on it . Cleaner data beat a smarter model. If you only take one thing from the benchmark literature, take that.
What the analyst was doing in their head
The reason a model struggles on a real warehouse is that a competent analyst was performing a dozen silent corrections that nobody ever wrote down. Each is now something the model has to be told.
Grain. Is one row a transaction, a daily balance, or a customer-month? Get this wrong and every sum is wrong, confidently.
Synonyms. Customer, account, party, client, subscriber. In one bank I worked with, three of those words pointed at three different tables with three different keys, and which one was "right" depended entirely on the question. The analyst knew. The schema didn't say.
Time. Fiscal calendars that don't start in January. Time zones that move a transaction across a day boundary. Late-arriving data. The difference between "as of today" and "as of the close of the period." A surprising share of disputes between two reports come down to one of these and nothing more.
Exclusions. Test accounts, internal orders, the staff discount, the region that migrated mid-year and double-counted for six weeks. Every mature warehouse carries a list of things you quietly leave out, and that list is almost never in the data.
Source precedence. When the and the billing system disagree about whether a customer is active (and they always eventually disagree), which one wins? Someone decided that once. The decision is real; it's just not written anywhere the model can read.
The unwritten and the known-bad. "Ignore Q2 2019, the migration doubled the volumes." "Sales started logging that field properly in March, so anything before is noise." These facts live in people's memory and Slack history. An agent doesn't know what changed, because it has no memory of the business, only the data, which looks perfectly plausible right up until it isn't.
I once spent the better part of an afternoon on a wealth-advisory engagement chasing a that was off by a rounding error nobody could explain. It turned out a single feed posted in a different time zone, so a sliver of transactions landed in the wrong day. A person caught it because the number felt a day late. An agent would have reported the figure and moved on.
What breaks for an agent
Translate that into failure modes and the same gaps surface as wrong numbers. Two valid join paths between the same tables produce different totals, and the model picks one without telling you which. Revenue sits net of refunds in one table and gross in another, both called revenue, and the agent averages your credibility. The dashboard everyone trusts carries a WHERE clause that drops a customer segment; the agent queries the raw table, doesn't, and the two now disagree by exactly that segment. Three customer tables, none authoritative, turn each query into a coin flip dressed as analysis. And with no glossary the model can guess what a word means but can't ask, can't be told it guessed wrong, and has nowhere to put the answer even if someone knew it.
None of these are AI problems. They're the same modelling problems we've always had. What's new is the loss of the human who used to absorb them. The agent doesn't error on ambiguity. It resolves it, silently, and hands you a number.
bad modelling rarely produces an error message. It produces a plausible answer. With a person in the loop, plausibility gets a second look. With an agent acting on it, plausibility is the whole transaction.
What an AI-ready model contains
The good news is that there's nothing to invent. An AI-ready model is the discipline Inmon, Kimball, and Linstedt argued about for decades, with one change: the knowledge that used to live in the analyst's head has to be moved into the model, in a form software can read.
The shift that matters is the middle box. For twenty years the semantic layer existed to give dashboard builders a shared set of metrics and dimensions. Its job is changing: it's becoming the interface an agent reads instead of improvising. If active customer is defined once, in a place the agent consults, then every question that touches it inherits the right definition. If it isn't, the agent invents one: a reasonable one, probably, and a different one each time.
A checklist for making a model agent-usable
Not a maturity model, just the things I'd check before letting an agent answer questions a business will act on:
- Stable names and keys. If a concept matters, it has a durable identifier and a name that means the same thing everywhere.
- One definition per metric, where the agent reads it. Net revenue defined once, in the semantic layer or metric store, not re-derived in twelve .
- Grain stated explicitly. Each table says what one row is. In words, in the description, not just implied by the keys.
- Descriptions on tables and columns. Treat them as documentation the agent will now consume, because it will.
- Exclusions encoded, not remembered. Test accounts and known-bad periods live in views, flags, or filters (somewhere structural), not in someone's memory.
- Source precedence declared. When systems disagree, the model says who wins, and why.
- Tests that fail loudly. , row counts, referential integrity, reconciliation against a trusted total. An agent can't sanity-check a number; the pipeline has to.
- Lineage exposed. When an answer is questioned (and it will be), you can trace it back to sources and transformations without a forensic dig.
- Permissions at the model, not the . What an agent can see is governed by the data layer, not by hoping the prompt holds.
Most teams have some of this. Very few have all of it written down where software can use it. That gap is the work.
The data-quality sibling argument, on what failing loudly looks like in practice:
What you can no longer leave in someone's head
Modelling was never warehouse ceremony, and the people who treated it as bureaucracy were wrong before agents arrived. It's the act of deciding what the business means (what a customer is, when a sale happened, which number wins) and recording those decisions somewhere durable. We used to get away with leaving half of them in people's heads, because there was always a person between the data and the decision.
That person is being asked to step back. The software discipline that flowed into data teams over the last decade is real progress, and I'd defend it against anyone who wants to romanticise the old hand-built warehouse.
Testing and version control applied to an unmodelled pile of tables just gives you well-tested confusion, delivered faster.
Where the line settles between the warehouse, the semantic layer, and whatever we end up calling the contract an agent reads, I don't know; that boundary is still moving. The direction is clear enough. Most teams won't experience it as an AI strategy at all. They'll just notice that when they finally pointed an agent at the warehouse, it already knew what the words meant.
Final thought
The organisations that kept doing the unglamorous parts (conformed dimensions, owned definitions, honest history, a glossary someone maintains) are the ones whose agents will be worth trusting.
The AI-Ready Data Model · June 2026 · Data. Benchmark figures are from published leaderboards and papers; anecdotes are anonymised by sector and shape. Full source records are in the References section above.
References9
- 1E. F. Codd, "A Relational Model of Data for Large Shared Data Banks", *Communications of the ACM*, 1970. dl.acm.org ↗
- 2IBM Information Management System (IMS), history including its use on the Apollo program (hierarchical model). en.wikipedia.org ↗ Accessed 2026-06-13
- 3Bill Inmon, *Building the Data Warehouse* (1992); subject-oriented, integrated, time-variant, non-volatile definition. en.wikipedia.org ↗ Accessed 2026-06-13
- 4Ralph Kimball, *The Data Warehouse Toolkit* (1996); dimensional modelling, conformed dimensions, the bus matrix. en.wikipedia.org ↗ Accessed 2026-06-13
- 5Dan Linstedt, Data Vault modelling (first articles 2000); hubs, links, satellites. en.wikipedia.org ↗ Accessed 2026-06-13
- 6J. Li et al., "Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs" (BIRD), arXiv:2305.03111, 2023, and the BIRD leaderboard (human expert execution accuracy 92.96%; top systems ~75%). arxiv.org ↗ · bird-bench.github.io ↗
- 7H. Kim et al., "FLEX: Expert-level False-Less EXecution Metric for Reliable Text-to-SQL Benchmark", NAACL 2025, arXiv:2409.19014 (strict execution accuracy agrees with human judgment ~62%). arxiv.org ↗
- 8Jin et al., "Pervasive Annotation Errors Break Text-to-SQL Benchmarks and Leaderboards" (annotation errors in over half of audited BIRD examples), arXiv:2601.08778, 2026, and "ReViSQL: Achieving Human-Level Text-to-SQL" (human-level via a verified dataset + retraining), arXiv:2603.20004, 2026. arxiv.org ↗ · arxiv.org ↗
- 9MotherDuck, "Your Data Model Is the Semantic Layer" (frontier LLMs reach ~95% practical accuracy on a clean schema; strict benchmark scores 58–64%), February 2026. motherduck.com ↗