Why Your AI Tool Picks the Wrong Column

When an AI tool filters on the wrong column, the usual cause is missing semantic context rather than a weak model. Schema structure tells it that a column called status exists and holds text. It does not say that 'completed' means paid and shipped, that 'closed' was the pre-2024 spelling of the same thing, or that orders_v2 is the live table and orders is an abandoned migration. That missing layer is what separates a tool that works on your data from one that writes fluent SQL against the wrong column.

If you have seen this happen

Anyone who has connected a natural-language analytics tool, watched it answer a question confidently and incorrectly, and wondered whether the model is bad. Usually it is not. Also for analytics engineers deciding how much curation is worth doing before rolling a tool out.

The two layers, and which one you control

Layer one: structure, which you get for free

Introspection reads table and column names, data types, primary keys, declared foreign keys, and nullability without anyone doing anything. Every tool in this category reads it, so it is not where quality differences between tools come from.

Layer two: meaning, which you have to supply

Databases mostly do not store meaning. It lives in a wiki, a dbt description: field nobody filled in, or an analyst’s memory. When it is absent, the model does what any competent stranger would do with your schema: it guesses from names.

What ambiguity costs

These are the failure shapes that recur:

Ambiguity	What the model does without context	What one line of context fixes
Status codes	Filters on the value that sounds right, or omits the filter entirely	status: order lifecycle — 'completed' means paid and shipped; use for revenue
Multiple amount columns	Picks amount over net_amount because the name is simpler	amount: gross, before refunds. Use net_amount for reported revenue
Deprecated tables	Queries the table with the cleaner name	orders: superseded 2024-03; use orders_v2
Test and internal rows	Counts them	customers: includes internal test accounts where is_internal = true — exclude for reporting
Undeclared join paths	Infers a join from naming convention; sometimes wrong	Declare the relationship, or correct the inferred one
Grain confusion	Sums a column that is already an aggregate	daily_revenue: pre-aggregated per day — do not sum across the same day
Timezone-mixed timestamps	Compares fields stored in different zones	created_at: UTC. local_ordered_at: store-local, not comparable

None of these are model failures. Each is a question the schema does not answer, resolved by the model committing to one reading.

What one line of context actually changes

Take the first row. The question is “what was revenue last month?”, against a fictional retailer’s demo schema where orders.status holds 'completed', 'pending', and 'cancelled'.

With no description on status, nothing in the schema says cancelled orders are not revenue, so nothing filters them out:

SELECT SUM(amount) AS revenue
FROM orders
WHERE ordered_at >= date_trunc('month', now() - interval '1 month')
  AND ordered_at <  date_trunc('month', now());

Now add one line of context to status: order lifecycle; 'completed' means paid and shipped, use it for revenue. The same question now produces:

SELECT SUM(amount) AS revenue
FROM orders
WHERE ordered_at >= date_trunc('month', now() - interval '1 month')
  AND ordered_at <  date_trunc('month', now())
  AND status = 'completed';

Both queries are valid SQL and both run without error. The first one silently includes cancelled orders, so it reports a higher number — and nothing about the answer looks wrong. That is the whole argument for curation: the cost of missing context is not a failure, it is a plausible number.

What to describe first: curation in priority order

Describing everything is how curation projects stall. Rank instead:

1. Every column you would filter on. Status, type, category, flag columns — these decide which rows are counted.
2. Every column with a sibling. amount and net_amount, created_at and updated_at, user_id and account_id. Ambiguity between near-identical columns is the most expensive kind.
3. Deprecated or shadowed tables. One line saying “do not use this” prevents a whole class of wrong answers.
4. Join paths that are not declared as foreign keys. Especially in warehouses like Snowflake where keys are informational and often never declared at all — covered in ask Snowflake questions in plain English.
5. Mark your key tables. Fact tables and core dimensions. When a schema is large enough that context has to be truncated, marked tables survive the cut, so the model keeps the ones that matter.

Everything else can wait. An auto-generated description is a starting draft, not a finished one: where it only restates the column name, it adds nothing the model could not already read. The value comes from editing the columns in the list above.

Curation is not a semantic-layer project

A common objection: “this is just building a semantic layer with extra steps.” A semantic layer computes metrics — it owns the definition of revenue and produces it consistently. Semantic context describes what already exists so a query can be written correctly against it. If you have a semantic layer, keep it; the best configuration is to point the conversational tool at the marts your semantic layer produces, so questions inherit definitions instead of re-deriving them. That is the setup argued for in building self-service analytics without replacing your stack.

If you do not have one, curation is not a substitute — but it is cheaper: describing the columns you filter on is a per-schema task, not a modelling project.

Context governance: keeping it true

Descriptions rot faster than schemas do, and a confidently wrong description is worse than none: it converts a coin-flip into a reliable error.

• Keep a reviewed source of truth. Descriptions you enter in a tool are easy to change and easy to forget. Keep the canonical wording where your models are reviewed — a dbt description:, a COMMENT ON, a file in the repo — so a change is visible to the team, and re-apply it when the schema moves. Datarelix does not import existing database comments or dbt descriptions today; descriptions are entered against the connection.
• Re-check on schema change. A renamed column with a stale description is the worst case.
• Watch for contradiction. When a generated query filters on something that surprises you, the description is usually the thing that is wrong.
• Give ownership per schema. Without a named owner, descriptions stop being updated when the schema changes.
• Verify against known answers periodically. Ask questions whose answers you already know; the point of an evidence trail is that drift is visible — the routine is in how to verify an AI-generated data answer.

Curating context in Datarelix

When you connect a database, Datarelix introspects structure directly — tables, columns, types, primary keys, declared foreign keys, nullability. An optional AI schema analysis (metered per month — see pricing) then proposes descriptions and infers relationships from naming conventions where foreign keys were never declared. It works from schema structure only; it is not shown sample rows.

Everything it proposes is editable, which matters because inference is sometimes wrong. On the schema page you can rewrite descriptions, mark tables as key tables, correct or dismiss inferred relationships, override primary keys, and exclude columns from context entirely. Very large schemas do not fit in a single request, so the context is trimmed — tables you mark as key tables are kept.

The resulting context is what accompanies each question, alongside the question itself. Rows are not part of it, with one honest exception: a single-row answer value can carry into follow-up conversation context so that “and how does that compare to last year?” resolves. Result tables do not. “Never your data” would therefore be an overstatement, which is why this guide does not make it. The full pipeline is in text-to-SQL explained, and the credential side is in how credentials stay out of the model.

What curation cannot fix

Curation raises the floor; it does not make interpretation deterministic. An ambiguous question over a perfectly described schema is still ambiguous — “top customers” can still mean revenue or order count — which is why the query is shown with every answer rather than hidden behind confidence language.

Descriptions cannot repair a genuinely broken model. If two tables disagree about what a customer is, no amount of prose reconciles them; that is a modelling fix. Very large schemas will be truncated no matter how well described, so scoping a connection to the schema that matters beats describing everything. And inferred relationships are hypotheses — check the joins in early answers before trusting a number, especially on schemas you did not model yourself.

Notes on the examples

Product statements describe Datarelix as shipped in August 2026 — including the deliberate disclosure that single-row scalars can enter follow-up context, which is stated here because the alternative absolute would be false. The security page states the execution boundaries canonically. Example descriptions use a fictional retailer’s schema and are illustrative. The ambiguity table is drawn from recurring patterns in production schemas, not from a published study; it is offered as a checklist rather than a measured ranking.

Describe ten columns and re-ask

Pick your busiest schema and describe the ten columns you filter on most. Then follow the quickstart, ask five questions you know the answers to, and read the WHERE clauses. Your first 14 days run at Pro limits, no credit card required.