What is context?
The difference between an agent that can see your database and one that understands your business.
Context is the difference between a system that can see your database and one that can understand your business.
A schema tells the system that a table has columns. Context tells it which table is canonical, what the columns mean, which joins are approved, which definitions your company trusts, and what has worked before.
That distinction matters because text-to-SQL does not usually fail because the model is not capable enough. It fails because the meaning it needs is scattered across warehouses, dashboards, SQL files, documentation, and individuals' knowledge.
Why schema is not enough
The system can read column names, types, and even semantic-layer definitions, but a schema does not tell the whole story:
status = 4means refundedloyalty_v3is the table your team actually uses- "monthly active users" excludes service accounts
- some joins are approved, while others produce misleading numbers
- some questions should be clarified before any SQL is written
Without that context, the system guesses. It selects a plausible table, writes plausible SQL, and returns a plausible answer. The demo appears correct; production is where the missing meaning becomes apparent.
The layers of context
To answer real business questions on real company data, the system needs several layers of context:
| Layer | What it answers | Examples |
|---|---|---|
| Structural | What data exists? | Tables, columns, types, keys, relationships |
| Semantic | What does the data mean? | Models, metrics, calculated fields, enum labels, canonical tables |
| Business | What does this company mean? | Active customer, revenue, churn, internal project names |
| Operational | How should this data be used safely? | Approved join paths, sanctioned queries, query-time governance |
| Behavioral | What worked before? | Confirmed natural-language-to-SQL pairs, examples, feedback |
The structural layer lets the system read the database. The semantic and business layers let it understand the business. The operational and behavioral layers help it act safely and improve over time.
Context vs. semantic layer
A semantic layer is one important part of context. It defines business-facing models, relationships, and reusable calculations so that people and tools do not query raw tables directly.
A context layer is broader. It includes the semantic layer, then adds the knowledge needed to operate reliably in production: which definitions are trusted, which tables to prefer, which values mean what, which joins are allowed, when to request clarification, and which past examples should guide the next query.
How NQRust Analytics represents context
Context is not a single hidden prompt. It is stored in explicit, reviewable pieces.
MDL: the semantic contract
Modeling Definition Language (MDL) is the core semantic contract. It describes models, relationships, calculated fields, and views in files your team can read and version. MDL helps the system map a question like "top customers by revenue" to the right models, joins, and calculations instead of reconstructing logic from raw warehouse structure.
Instructions: business and operational guidance
Project instructions capture guidance that may not belong in a model definition: preferred terminology, default filters, table-selection rules, and policies the system should follow. This is where business meaning starts to become operational.
Question–SQL pairs: examples that compound
A memory of confirmed natural-language-to-SQL pairs allows successful work to improve future work. Similar future questions can reuse proven examples, turning routine usage into a learning loop. The context layer becomes more useful as your team asks, corrects, and confirms more questions.
In short
- Schema tells the system what exists.
- Semantic layer tells it what the data means.
- Context layer tells it how the business uses the data, how to act safely, and what has worked before.