Ask an LLM to design a Data Vault for 13 tables from a bank's core banking, card and risk systems, with names like LOAN, COLLATERAL and COUNTERPARTY, and you get an answer in a minute. Ask it again and you may get a different one. That is fine for a chat assistant and a real problem for a data model a bank will run for years.
In short: most data modeling choices have a known set of answers, so a System 1 decision model can make them in milliseconds, repeatably and with calibrated confidence. An LLM works as the agent that reads the business context and talks to the team. VaultSpeed combines them: an LLM analyzes the sources, a decision model decides the modeling pattern, and for Data Vault a rule engine generates the code. Every decision is stored and versioned in the enterprise context store.
Most of data modeling is a long series of small choices, each with a known set of possible answers. Choices like that suit a different kind of AI, the System 1 decision model, named after the fast, intuitive thinking Daniel Kahneman called System 1. An LLM reasons step by step and writes text, while a System 1 decision model answers a typed question in a single pass. Below I compare the two on data modeling work and show how they work together.
System 1 and System 2. In his book Thinking, Fast and Slow (2011), Nobel laureate Daniel Kahneman describes two modes of thinking. System 1 is fast, automatic and intuitive, like recognizing a familiar face or knowing that 2 + 2 is 4. System 2 is slow, deliberate and effortful, like filling in a tax return or comparing two mortgage offers. AI now has both. An LLM that reasons step by step works like System 2. A System 1 decision model answers a typed question in one pass, the way an experienced modeler recognizes a hub at a glance.
Look closely at how a data model gets built and you see hundreds of decisions, most of them small. Is this table a hub, a link or a satellite? Which column is the business key? Other decisions concern personal data, cardinality and how often an attribute changes. In dimensional modeling they become fact or dimension, grain and SCD type.
In a small test case on a banking source, 13 tables from three systems produced 204 of these decisions. Each has a finite set of valid answers: a column holds personal data or it does not, and a table becomes one of a handful of object types. The hard part is picking the right answer for this source, in this company, consistently across thousands of tables. In machine learning terms, that is a classification problem.
A decision model is a trained model that chooses from a fixed set of answers. Some vendors write "System One models"; this article follows Kahneman's own notation, System 1. It takes a description of each case, either as a set of features or as a short text, much like a credit check works from income, debt and payment history. In data modeling that description covers the object being decided. For a column, it can be the name, data type, share of empty and distinct values, and whether the column sits in a key. For a table, it can be the keys, foreign keys, row count and how often rows change. From there it returns a probability for each possible answer. It never writes free text, so it cannot invent an answer that is not on the list.
That fits data modeling well. The same input always gives the same output, which matters when an auditor asks why a column was flagged.
Its scores can also be calibrated, so a 90% answer is right about nine times out of ten and the confidence can decide what happens next. A decision takes milliseconds and costs a fraction of an LLM call, whether the decision model runs on your own hardware or as a hosted service billed per call.
A PII flag is a yes or no question. Hub, link or satellite is a pick from a list, and a change rate is a level on a scale.
| Kind of decision | What comes back | Data modeling example |
|---|---|---|
| Yes or no | The probability that the answer is yes | Does this column hold personal data? Is this satellite multi-active? |
| One from a list | The chosen option, with a probability for every option | Hub, link or satellite? SCD type 1, 2 or 3? |
| A level on a scale | A position on an ordered scale, with a probability per level | Change rate: static, slow, daily or real time |
Some decisions take a combination. A column that may hold several kinds of personal data becomes one yes or no question per kind. Picking a business key becomes a choice whose options are that table's own columns. Machine learning knows more task types, such as predicting a number or ranking a long list of candidates, but modeling decisions rarely need them.
| System 1 decision model | LLM | |
|---|---|---|
| What it produces | One answer from a fixed list, with a probability for each | Free text: code, explanations, new structures |
| Best at | Making many similar choices consistently | Reading business documents, naming, open questions |
| Repeatability | Same input, same output | Answers can vary between runs |
| Confidence | Probabilities you can calibrate and act on | Stated confidence tends to run high |
| Cost per decision | Milliseconds, a fraction of an LLM call | Tokens on every call, seconds per answer |
| Learning from your team | Retrained on accepted and corrected decisions | Guided through prompts and context, rarely retrained |
| Main risk | Can only choose from answers it knows | Can sound right and be wrong |
In practice you want both, each on the work it does best.
Software has made typed decisions for decades. Logistic regression goes back to the 1940s, and CART decision trees (1984) learned yes or no and one from a list answers from labeled data. Banks have scored credit with the FICO score since 1989, and the DMN standard from the Object Management Group gave business rules and decision tables a shared notation. Random forests and gradient boosting, packaged later in libraries such as XGBoost and LightGBM, became the standard tools for classifying rows in a table.
Each of those models is trained for a single question on its own labeled data, and the latest generation changes exactly that. This is the System 1 generation that this post compares with LLMs. Research from 2019 showed models classifying text against labels they had never seen. In 2026 the idea became products: TypeSafe's Jev opened the category as a hosted API, and Cloudflare's Clef and AWS's Strands Decider followed with open weights. They read text or JSON, take the question and its answer options in plain language at request time, and return probabilities in one pass, with no training. TabPFN does something similar for tables, predicting from labeled rows passed in at prediction time.
For data modeling, the two generations work well together. A team can start on day one with a pretrained decision model, then calibrate it or train its own as accepted and corrected decisions build up.
Calibration needs decisions with known right answers, and this is where history becomes an advantage. VaultSpeed has encoded the modeling decisions made across dozens of enterprise Data Vault 2.0 implementations running in production, including the edge cases that only show up at that scale. A pretrained decision model or an open source library starts from general knowledge. Calibrated and trained against that history, it proposes the way experienced Data Vault modelers actually work.
Calibration itself is a separate step on top of the decision model, whether you trained that model yourself or call a pretrained System 1 model as a service. It matters most for the pretrained ones: an independent benchmark found them overconfident, and their calibration varied from one dataset to the next. A probability is only as good as its calibration on your own decisions. You run the decision model on past decisions it has never seen, where the right answer is known, and compare its scores with how often it was actually right. If its 90% answers turn out correct only 76% of the time, a small correction curve learns that.
From then on, every decision passes through two steps in milliseconds: the decision model scores the alternatives, and the curve turns those scores into honest probabilities. Every accept and override from your team adds a new example, so the curve can be refitted often, per decision type, without touching the decision model itself. That also works for a hosted decision model you could never retrain.
Inside a modeling tool, the LLM runs as an agent that manages the work, and the decision model is one of the tools it calls. The agent plans the job and talks to the team, much like a lead modeler, while the decision model makes the individual calls. A typical session runs like this:
Because the agent leaves every finite choice to the decision model, the expensive LLM calls are kept for the language work.
VaultSpeed gives each decision to the cheapest method that can answer it with confidence. For Data Vault, that splits the work three ways. An LLM analyzes the sources and the business context. A decision model decides which modeling pattern applies to each source structure, choosing from a fixed catalog of patterns. A rule engine then generates the code, so the same data model always produces the same code.
AgentLLMAnalyzes sources andbusiness contextDecisionDecision modelPicks the modeling patternfor any methodDeterministicRule engineData Vault: same input, same codeAgentLLMStar schema, 3NF: reviewed in GitShared context layerEnterprise context store (metadata graph)Business concepts, the data model, and every decision with its confidence and history One flow for every modeling method. Only the code step changes.The same split works for other modeling methods. For a star schema or 3NF, the LLM does the same analysis and the decision model handles the finite choices, such as fact or dimension, grain and SCD type. These methods have fewer fixed code patterns, so the LLM generates the code and the team reviews it in Git. The principle stays the same: deterministic where the pattern allows, agentic where it does not.
Underneath sits the shared context layer: the enterprise context store, a metadata graph. Every step reads from it and writes back to it: the business concepts, the data model, and every decision with its confidence and history. That shared context is what keeps LLM generated code grounded and reviewable, and it means a team can add a second modeling method without starting over.
Whichever method makes a proposal, it comes back in the same shape: a set of alternatives, each with a confidence score. Above a threshold the decision is applied, and below it the decision goes to a person.
Confidence scores change how review works. A modeler no longer reads a full data model line by line. They see the handful of decisions below the threshold, with the alternatives and their probabilities next to them. In the banking test case, 144 of the 204 decisions went through on confidence, 50 came back for a quick confirmation and 10 needed a real call: business keys at around 50% confidence, such as whether COLLATERALID or LOANNUMBER is the key, and the object type of LOAN_TRANSACTION and CARD_TRANSACTION. Those are exactly the decisions a modeler wants to see first. Agents review too: an LLM agent can flag a classification that contradicts the business glossary before anyone else sees it.
Those reviews are also training data. When a modeler accepts a proposal, the decision model gains confidence. When a modeler overrides one, it learns where it was wrong. A team that only clicks accept teaches it nothing, which is why a good modeling tool points people to the marginal calls first. Over time the proposals start to look like the team's own work.
LLMs made it easy to generate a data model in minutes. Trusting that data model across thousands of tables requires decisions that are repeatable and calibrated, which System 1 decision models provide. That only holds if every decision is stored and versioned over time: what was proposed, with what confidence, who accepted or overrode it, and when. That history is the context the next proposal, the next calibration run and the next agent all work from, and it lets a team see why the data model looks the way it does today.
VaultSpeed's agentic data modeling platform supports this approach, and teams can shape it to their own needs by adapting the skills and plugins that run it. Agents propose the data model and confidence scores decide which decisions need a person. The approved data model and every decision behind it are stored and versioned in the enterprise context store, VaultSpeed's metadata graph, where data products and other agents build on it.
A System 1 decision model is a trained model that chooses from a fixed set of answers in a single pass and returns a probability for each one. It never writes free text, so it cannot invent an answer that is not on the list. The name comes from the fast, intuitive thinking Daniel Kahneman called System 1.
A decision model gives one answer from a fixed list, with a probability for each, and the same input always gives the same output. It answers in milliseconds at a fraction of the cost of an LLM call. An LLM writes free text such as code and explanations, and its answers can vary between runs. In data modeling you use both, each on the work it does best.
No. Logistic regression goes back to the 1940s, CART decision trees to 1984 and the FICO credit score to 1989. What is new is pretrained decision models such as Jev, Clef and Strands Decider, which take the question and its answer options in plain language at request time and need no training.
You run the decision model on past decisions it has never seen, where the right answer is known, and compare its scores with how often it was right. A small correction curve then turns the scores into honest probabilities. Every accept and override from your team adds a new example, so the curve can be refitted often without retraining the decision model, which also works for a hosted one.
The LLM runs as an agent that reads the business context, plans the work and talks to the team. For every finite choice, such as a PII flag, an object type or a business key, it calls the decision model. Confident decisions are applied and the rest go to a person for review.
In VaultSpeed, every decision is stored and versioned in the enterprise context store, the metadata graph. That includes what was proposed, with what confidence, who accepted or overrode it, and when. The next proposal, the next calibration run and the next agent all work from that history.