Every tidy text-to-SQL demo works. Very few survive a real warehouse schema, because the hard part was never the language.
Ask a language model a question about eight tidy tables and it can often write useful SQL. A working warehouse is different. Consider an illustrative schema where quantity appears on nine tables, status on twenty and total_quantity on five. One version of that total may even be stored as text, so it cannot be added without cleaning. Several columns may look like the order arrival time, while several tables appear to hold orders.
Now ask: How much did we receive last month?
There is no language problem in that sentence. The problem is business meaning. “Received” could point to several quantity fields, and a model cannot know which one the operation trusts unless that choice has already been defined. It may select a field, produce valid SQL and return a convincing number from the wrong table.
A query that errors is easy to catch. A query that quietly uses the wrong join can put a false figure into a client review.
More context is not the same as more certainty
A common response is to send the model more material: every table definition, long descriptions and sample rows. That can increase cost and response time. It can also give the model more plausible fields to choose between without resolving which one is correct.
Sample rows create a separate data-handling question. Whether operational data reaches a model provider depends on the actual architecture and agreement. Teams should confirm what leaves their systems, what is retained, and which controls apply instead of assuming privacy from the interface.
The useful context is not the largest possible schema dump. It is a smaller, tested map of the concepts needed for the question.
Decide the data meaning once
The alternative is not simply a cleverer prompt. It is to resolve the hard questions about the data before people start asking questions.
- Which quantity field records goods received?
- Which tables record events, and which record current state?
- Which columns represent moments in time?
- Which tables genuinely relate, in which direction, and at what row cardinality?
- Which warehouse terms map to which fields?
- Which duplicate, staging or unused tables should be excluded?
Measure relationships against the data instead of guessing from matching column names. Review the proposed meanings with the people who operate the warehouse and the people responsible for the source system.
These choices do not need to be made again for every question. Once confirmed, the model has a smaller job: match the user’s words to a limited set of concepts whose business meaning and relationships are already known.
Let the model handle words and the engine handle maths
Interpreting a sentence is language work. Selecting rows, applying filters and adding numbers are deterministic database work. A reliable design gives each part to the system suited to it.
- The language layer maps the question to confirmed concepts.
- The query layer builds a constrained request using approved fields and joins.
- The database selects rows and performs the calculation.
- The answer layer explains the result, source, time window and working.
In an architecture designed this way, the model does not need a full schema or raw sample rows for every question. The precise data flow still needs to be checked for the real implementation. When the data and definitions have not changed, the same constrained calculation should produce the same result.
This split also keeps the model’s task smaller. Cost depends on the chosen provider, model, context and deployment, so it should be measured rather than promised.
Build more than a fluent query box
A confirmed map of moments, measures and relationships can support more than questions. It can help define the time between two operational events, show where a process branches, identify work waiting between stages and check whether two measures can honestly be compared.
It can also support warnings when a measure moves towards a target. That is still evidence for investigation, not proof of why the change happened or a guarantee that a breach will occur.
Natural-language querying is the most visible feature built on this layer. Build only the query box and you may end up with a fluent interface over an unresolved database—the demo that fails when it meets a real warehouse schema.
Three questions worth asking
What happens when the schema doubles? If cost, delay and error risk rise with every added table, the system may be doing the data-resolution work again on each question instead of maintaining a confirmed map.
What operational data leaves on each question? Ask whether the system sends schema, sample rows, selected records or only a calculated result. Confirm the answer against the implemented architecture and agreement.
What happens when a question cannot be resolved? A trustworthy system should name the missing definition, relationship or field. A fluent guess is not a safe fallback.
Where Hatu fits
Hatu is a decision layer over the warehouse data you already run. Ask Hatu answers in plain language and keeps the source, working and time window available for review. Its Data Directory and setup process establish business names, relationships and usable definitions before those concepts are used in a question.
Hatu also uses the mapped layer for Watch Tower, KPI diagnosis and Early Warning. These features help a team prioritise and investigate work. They do not prove causality or replace the people responsible for operational decisions.
Start with known questions and low-consequence decisions. Check the calculation, filters, time window and source. Expand only when the team can explain where each answer came from and recognise when the system should decline.