Every AI-assisted modeling tool now makes the same promise: a better diagram, delivered faster. Before you buy one, ask the question none of them raises, which is who the diagram is actually for.

In 2023, Benn Stancil predicted where this ends: “If that happens, data models won’t get built for people, but for LLMs.” He was half right. Models are being built for machines today, and those machines read meaning. What he missed is the half that matters to your work. The model for people never goes away, because the deciding never goes away. Someone still has to decide whether billing’s customer is the order system’s customer.

A data model always did two jobs

Think about what a model does in a room. Someone draws Customer Account on the whiteboard and says, “It’s identified by company code and customer number, and the order system issues both.” Someone else objects that billing has its own customer number. An hour later, the diagram holds the agreement they reached. That’s the first job: a sentence about your business that a room of people can argue over until it’s right.

Then the second job started. A load pattern, a query optimizer and a reporting tool all had to use that agreement, and while every one of them could read a table, none of them could read a sentence. So you poured the sentence into structure, and the physical data model became the place where meaning lived. Third normal form bent every source into one agreed shape. Data Vault wrote the same sentence as hubs, links and satellites.

The restructuring was never the point. It was the price you paid so the machines could read what the room had decided.

Now the machine reads the sentence

That price has been dropped, and we can now measure by how much.

In 2026, Daniel Su and colleagues ran a controlled experiment on text-to-SQL. They held the questions and the data fixed and varied two things. The first was structure, ranging from a single wide table to third normal form with every join path spelled out. The second was naming, ranging from anonymous codes to descriptive identifiers. Meaningful names made up for missing structure, but added structure never made up for opaque names. Their conclusion fits in one clause: “the practical bottleneck is semantic grounding rather than relational exposure.”

Read that again as a modeler. The model didn’t fail to find the join. It failed to know what the column meant.

A second study arrives at the same point from the other side. Michael Rumiantsau and Ivan Fokeev gave three frontier models a retail schema and 100 analyst questions. Then they ran the test again with one hand-written document placed in front of the schema. It was a few pages long and covered:

  • which tables to start from
  • the join paths
  • what the codes mean
  • how the metrics are calculated
  • a dozen rules for the agent

Accuracy rose by 17 to 23 points on every model, and nothing in the data moved. In their words, “Whether the model has the semantic layer matters more than which model it is.”

You’d raise two caveats, so here they are. The first is that the authors sell a semantic layer, which is the trade’s name for a document like that one. The second is that 68 percent, where all three models landed with the document, isn’t a number you ship. It’s what one unrevised document bought. Both caveats are reasons to write a better document, not to rebuild the tables.

What do you hand the machine?

Look at what that document contained. It named the business things there are, what identifies each one, and which system issued that identifier. It described how those things relate and in which role. Every column got a meaning, a unit, and the code list it answers to, and every table got a statement of how much history it keeps.

That is your diagram, every box and every line on it, written as sentences a machine can read. Written that way, it’s an ontology for AI. A data model for AI is the same model rendered twice: once as a diagram for the meeting, and once as a briefing for the agent. Neither rendering asks the data to move. What the briefing holds, table by table, is the subject of The agent reads the contract.

Isn’t that just a semantic layer? It’s the same move, made earlier. A platform’s semantic layer annotates tables after they land, inside that platform, for that platform’s dashboards. The model you hand the machine is written once, before any platform, in the place where the old methods used to restructure.

The deciding stays

Here’s the half Stancil missed. The model for people doesn’t go away, because the deciding doesn’t go away. Someone still has to decide whether billing’s customer is the order system’s customer. Someone also decides how long history is kept and which columns an agent may never see.

A 2026 study by Aravind Sasidharan Pillai tested that claim directly. A language model given only the business definitions still leaked data it shouldn’t have returned, and the study counts that leak as one of its six kinds of hallucination. The measured hallucinations reached zero only when the model also had governed rules, checked on every query, along with permission to refuse. So who writes those rules? The people in the room do.

Structure keeps one job as well. A sum over a flat table double counts, so a table built to answer a question still has a grain, and the question decides what that grain is. That’s a decision about the number rather than about the meaning, and the meaning is what you’ve been pouring into tables for twenty years.

So the modeling tool that draws your diagram faster has automated the one step that needed you, and skipped the step that needed the machine.

Try it on one diagram

  1. Write the sentences behind one diagram. Pick a diagram your team argued over and write out what it says: what each box is, what identifies it and in which system, how the lines relate and in which role, and what each column means.
  2. Ask with the sentences. Give those sentences to the model your platform already runs, alongside the raw schema, and ask it a question you’d put to an analyst.
  3. Ask without them. Take the sentences away and ask the same question again.

The difference between those two answers is the second job of a data model, done without moving a single table.

In DeltaVault, the business model you draw on the canvas is the same metadata the AI reads. Its entities, attributes and relationships are catalog rows, not boxes in a drawing tool.