The Context Problem: Why LLMs Need Your Schema, Synonyms, and Business Rules
An LLM knows SQL. It doesn't know that in your company 'active' means something specific, or that revenue lives in three tables. Closing that gap is the real work.
Here's a truth that surprises people building AI over their data: the model already knows SQL. Fluently. Every dialect, every join type, every window function. Syntax is the easy part.
What the model doesn't know is your business. And that gap, not SQL skill, is where AI-generated queries go wrong. We call it the context problem, and it's the central challenge of making natural-language-to-SQL actually work.
Three things the model can't guess
Your schema. A model has never seen your database. It doesn't know you split customers across accounts and organizations, that orders joins to line_items on a non-obvious key, or that half your tables carry a deleted_at you have to filter on. Without the real schema, it invents a plausible one, and plausible-but-wrong is the most dangerous kind of answer.
Your vocabulary. People don't ask questions in column names. They say "customers," "signups," "MRR," "active users." Your database says org_id, created_at, mrr_cents, and "active" isn't a column at all. It's a condition someone in your company defined. The gap between how people talk and how the data is labeled is a translation problem, and translation needs a dictionary.
Your rules. Every business carries definitions that live in people's heads. "Revenue" excludes refunds and internal test accounts. "Churn" means cancelled or 90 days inactive. "This quarter" follows a fiscal calendar that doesn't start in January. These aren't in the schema. They're institutional knowledge, and a query that ignores them is confidently, invisibly wrong.
Why generic prompting can't close the gap
The common workaround is to shove the schema into the prompt and hope. It helps with table names, but it doesn't carry the vocabulary or the rules, and it gives the model no stable, curated place to learn what "active user" means for you. Every query starts from scratch, re-guessing the same definitions.
The result is a tool that's right when the question happens to match the schema's literal shape and wrong the moment it requires knowing something only your team knows. That's not a model you can trust with a real question.
Context as a first-class layer
Cazper treats per-database context as its own layer, not an afterthought stuffed into a prompt. Each connected database carries stored context: descriptions of what tables and columns actually mean, synonyms that map business language to schema names, and business rules that encode your definitions.
When Cazper generates a query, it generates against that context. "Active users" resolves to your condition, not the model's guess. "Revenue" applies your exclusions. The schema is real, not invented. The SQL comes out grounded in how your business is actually shaped.
Context is also a boundary
There's a second reason context is its own layer: it's sensitive, and it has to stay put. The way you define churn, the synonyms that reveal how you model your business, that's proprietary. So each database's context is walled off. It informs that database's queries and never bleeds into another's session, even within the same organization. Correctness and confidentiality come from the same design.
The takeaway
The race in natural-language-to-SQL isn't for a model that writes better SQL, since models already write excellent SQL. It's for the system that best captures what your data means. Syntax is commodity. Context is the moat.
That's why Cazper is built around your database's context, not just a clever prompt. The model brings the SQL. Your context brings the truth.