Semantic Layer vs. Business-Context Layer: Two Answers to the Same NL-to-SQL Problem

Spend time in the natural-language-to-SQL space and you'll notice everyone agrees on the diagnosis: an LLM writes fluent SQL but doesn't understand your business, and that gap is where answers go wrong. The disagreement is about the cure. Two schools have emerged, and the difference is worth understanding if you're choosing a tool.

The shared problem

An LLM doesn't know that "revenue" excludes refunds at your company, that "active user" is a specific condition, or that customers span three tables. Someone has to close the gap between how your business thinks and how your database is shaped. The two approaches close it in fundamentally different ways.

Approach one: the semantic layer

The semantic-layer approach says to model your business formally, up front. You define metrics, dimensions, entities, and relationships in a structured modeling layer, often as code or config. "Revenue" becomes a named metric with an explicit definition. "Active user" becomes a formally specified dimension. The AI then generates queries against this clean, curated model rather than against raw tables.

The strength is precision and governance. Definitions are explicit, version-controlled, and consistent, so everyone querying "revenue" gets the same "revenue" because it's defined once, formally. For organizations that want a single governed source of metric truth, this is powerful.

The cost is the modeling itself. Someone has to build and maintain that layer. It's real data-modeling work, it has to keep pace with a changing schema and evolving definitions, and until it's built, the tool can't answer much. It front-loads the effort.

Approach two: the business-context layer

The business-context approach says to teach the AI about your database rather than rebuilding it into a formal model. You attach context to each connected database: descriptions of what tables and columns mean, synonyms mapping business language to schema names, and business rules encoding your definitions. The AI generates SQL against your actual schema, grounded by that context.

The strength is that it meets your database where it is. There's no parallel model to construct and keep in sync, since you're annotating the real thing. Context can start light and deepen over time, and it maps naturally to how people already describe their data. It lowers the barrier to getting useful answers quickly.

The trade-off is that it's guidance rather than rigid specification. Context steers generation toward the right definitions instead of compiling queries from a formal model. In practice that flexibility is a feature, because it tolerates messy, evolving, real-world schemas, but it's a genuinely different philosophy from formal modeling.

Where Cazper sits

Cazper takes the business-context path. Each database carries its own stored context, including schema descriptions, synonyms, and business rules, and generation is grounded in that context against the live schema. We chose it because enterprise databases are rarely clean enough to model formally without a large project first, and the value of asking your data a question shouldn't wait on that project.

Context is also isolated per database: what teaches the AI about one database never bleeds into another's session. You get grounding without building, and without cross-database leakage.

Which is right for you?

If your organization already invests in formal metric governance and wants one rigidly-defined source of truth, a semantic layer aligns with how you already work. If you want to point AI at your real databases and get grounded answers without a modeling project standing in the way, a business-context layer fits better.

They're two honest answers to the same problem. The question isn't which is universally correct. It's which matches how your data, and your team, actually work today.