The fastest way to get a confident, well-written, completely wrong answer out of an AI system is to point it at a production database and ask a business question.
- Business problem
- Pointing a capable model at a production database and asking it a business question is the fastest way to get a confident, well-written, completely wrong answer.
- Why it matters
- The failure mode is fluency, not refusal. A broken join throws an error; a misunderstood column returns a number. Column meaning, calculation rules, units, and validity windows usually live outside the data — in policy documents and the heads of the people who built the pipeline — and no amount of added context recovers them.
- Architecture response
- Resolve meaning once, deterministically, in a layer the model reads from: canonical models, metric definitions, units and validity windows, and bounded tool interfaces — rather than enlarging the context window and hoping the model infers it.
- What Databright Cloud Solutions does
- We design canonical models, metric definitions, bounded tool interfaces, provenance and lineage, and the governance that makes an AI answer explainable instead of merely fluent.
The pitch for pointing an LLM directly at raw data is genuinely appealing: skip the modeling work, skip the semantic layer, let the model read the schema and figure it out. It demos well. It fails quietly at scale, and the way it fails is the problem.
The failure mode is fluency, not refusal
A broken join throws an error. A missing column throws an error. A misunderstood column returns a number.
That asymmetry is the entire argument. Traditional data bugs announce themselves; semantic bugs are laundered into prose. When a model joins customer_status from a system where inactive means “churned” against one where it means “not yet onboarded,” nothing crashes. A retention figure comes out, correctly formatted, sourced to a real table, and wrong in a direction nobody can see.
What happens when models meet real schemas
This is measurable, and the measurements are not close.
The BIRD benchmark was built specifically to test language models against real databases rather than clean academic ones—95 databases across 37 professional domains, deliberately retaining what the authors call “dirty” database contents and requiring external knowledge to bridge the gap between a question and the values on disk. ChatGPT reached 40.08% execution accuracy. Humans reached 92.96%.1
Spider 2.0 raised the realism further, drawing 632 problems from enterprise data applications on BigQuery and Snowflake, where a single database often carries more than 1,000 columns. The same model that solves 91.2% of the older, cleaner Spider 1.0 tasks solves 21.3% of these.2
The model did not get worse. The scaffolding went away. That gap is a direct measurement of how much meaning a curated schema was silently supplying.
The missing knowledge is not in the data to begin with
The tempting reading of those numbers is that models will close the gap on their own. That misreads where the information lives.
Three kinds of knowledge a table does not contain:
What the field actually represents, which edge cases it includes, and which apparently similar field it must never be compared against.
How the value was produced—the formula, the exclusions, the rounding, the business-rule version in force when the row was written.
When the value was valid, which jurisdiction or market it belongs to, and whether it may be used for this purpose at all.
None of that is inferable from a column name and a thousand sample values, because it was never encoded there. It lives in policy documents, onboarding decisions, vendor contracts, and the working memory of whoever built the pipeline—a pattern documented field by field in our review of real estate semantics.3 Asking a model to reconstruct it is asking it to guess—and a system optimized to produce plausible continuations will produce a plausible guess rather than an admission that the question is unanswerable.
A model can infer structure from data. It cannot infer meaning that was never written down.
More context is not the same as more meaning
The common reflex is to fix this with volume: larger context windows, retrieval over the data dictionary, more sample rows in the prompt. These help, and they are not the same thing.
Retrieval finds documents that exist. If the definition of a metric was never written down, retrieval returns the next most similar paragraph and the model proceeds confidently. Larger windows let you paste more ambiguity into the prompt. Neither resolves a contradiction between two sources that each claim to be authoritative—something has to decide, and record that it decided.
There is also a straightforward engineering objection. Resolving semantics inside the prompt means resolving them again on every single call: non-deterministically, un-testably, un-auditably, and at token cost that scales with query volume. The same disambiguation, computed once in a governed layer, is deterministic, version-controlled, unit-testable, reviewable by a domain expert, and free at query time.
What the middle layer is actually for
The goal is not to sanitize data until it is bland enough for a model to handle. It is to make meaning explicit and machine-readable, so the model spends its capability on reasoning rather than on guessing what your columns mean.
Establish which real-world entity each record describes before any field on it can be trusted or compared.4
Ship the business definition, unit, time basis, and allowed values alongside the value—not in a wiki the model cannot read.
Record which formula and rule version produced a calculated value, and keep the source value beside it.
Not collected, not applicable, unknown, and false are four different assertions. Collapsing them into NULL destroys information; replacing NULL with false invents it.
Label metrics as directly comparable, normalized, approximate, or source-specific, so a model knows when a cross-market aggregate is invalid.
Source, observation type, effective date, and confidence travel with the value, so an answer can be explained and challenged.
Where it sits
The layer belongs between governed data and the model—not inside the prompt, and not inside the model.
In this arrangement the model stops being a data-cleaning engine and becomes what it is good at: interpreting a question, selecting the right governed metric, and explaining the result in context. The disambiguation it would otherwise improvise has already been made, once, by people accountable for it.
This also changes what a wrong answer costs. When meaning is resolved in a versioned layer, a bad number is traceable to a specific rule that a specific person can correct. When it is resolved inside a prompt, there is nothing to fix—only a different phrasing to try.
Where to start
You do not need a complete semantic model before connecting an LLM to anything. You need to know which fields are load-bearing.
Start with the handful of concepts that appear in the questions people actually ask—the status field, the primary date, the money amount, the count everyone reports on. Write the definitions down in a form the runtime can read. Mark the comparisons that are unsafe. Expose those concepts to the model as bounded tools rather than raw table access. Then widen coverage as the question volume tells you where the ambiguity is.
The organizations getting durable value from AI over their own data are not the ones with the largest context windows. They are the ones that decided what their data means before they asked a model to reason about it.
Give a model raw data and it will produce a fluent answer. Give it governed meaning and it will produce a defensible one.
Sources and industry references
- Li et al. — Can LLM Already Serve as a Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs (BIRD), NeurIPS 2023: dirty database contents, external knowledge, and the 40.08% vs. 92.96% human gap
- Lei et al. — Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows: 632 enterprise problems, 1,000+ column databases, and the 91.2% / 73.0% / 21.3% progression
- Databright Cloud Solutions — The Semantic Consistency Problem: When the Same Real Estate Field Means Different Things
- Databright Cloud Solutions — The Property Identity Problem: Why APNs, Parcel Numbers, Addresses, and MLS IDs Are Not Enough
This article provides data-architecture and technology perspectives, not legal, regulatory, or investment advice. Benchmark results reflect the figures reported by their authors at publication and change as models and methods improve.