A natural-language analytics system.
English in, SQL against the real schema, a result, a chart. The hard part is not generating the query, it is being safe enough to aim at a production database and legible enough that a wrong answer is debuggable.
A generated query is an untrusted query.
A language model writing SQL is a program accepting instructions from a user and emitting code that runs against a database. Framed that way the security question answers itself: generated SQL is untrusted input, and it has to be treated exactly as hostile as anything else crossing a trust boundary, no matter how reasonable it looks.
The second problem is trust of a different kind. A chart with a number on it and no visible derivation is unfalsifiable. The reader cannot tell a correct answer from a confidently wrong one, and the confidently wrong one is the failure mode this category actually has.
Both push the same way: the query is the product, not an implementation detail. It gets validated like untrusted code and displayed like a result.
The requirements that came out of that.
Each one assumes the model will eventually produce something wrong, because over enough queries it will.
- Generated SQL checked before it reaches the database, not after
- Read-only execution with a bound on what one query may cost
- The query shown to the reader, not hidden behind the chart
- A model provider that can be replaced without touching the callers
What had to be true before a query could run.
Four calls, all of which get more expensive the later they are made.
Stated as decisions rather than features, because each has a defensible opposite. What follows is which way this one went and why.
Validate the parsed query, not the string
Generated SQL is parsed and inspected as a syntax tree before execution, so what gets checked is the statement the database will actually run rather than text that happens to match a pattern. String matching on generated SQL fails the moment a model phrases something in a way the pattern did not anticipate, which is the only kind of case that matters.
Read-only, bounded, every time
Execution runs against a read-only path with a statement timeout, so the worst case for a bad query is a failed query rather than a mutated table or a database pinned by one runaway scan. This is the property that makes it defensible to point the system at real data at all.
Show the SQL
The generated query is displayed and editable beside its result. It turns a wrong answer into a debuggable one, and it is the difference between a tool an analyst can be accountable for and a black box they have to either trust completely or not use.
The model sits behind an interface
Generation goes through a provider abstraction rather than a vendor SDK reached for directly. Models are the fastest-moving dependency in the stack and the one most likely to be repriced, deprecated or beaten; the interface is what keeps that a configuration change instead of a rewrite.
The decision that mattered.
One call per build, taken with a real alternative on the table. The alternative is named here, and so is what choosing against it cost.
Show the query, even though it makes the product look less magical.
The generated SQL is displayed beside its result and can be edited and re-run. The system does not present the chart as the answer and keep the derivation to itself.
It is the decision that mattered because it settles what the product is. Hiding the query makes a better demonstration; showing it makes a tool somebody can be accountable for using.
- The alternative
- Hide it. Question in, chart out, nothing in between. It is the cleaner interface, it is what the category advertises, and it is the version that demonstrates well to somebody who does not write SQL, which is precisely the buyer this kind of product is sold to.
- What it cost
- The illusion, and some of the audience with it. A visible query is a reminder that a machine wrote code against your database, and for a reader who cannot assess it the panel is noise at best and alarming at worst. It also exposes every clumsy join the generator produces, so the product is judged on output it would rather not show.
- Why the trade holds
- The failure mode in this category is not an error, it is a confident wrong answer, and a number with no visible derivation cannot be told apart from a correct one. Hiding the query removes the only mechanism by which a reader could ever catch it. The cost is paid in polish; the alternative is paid the first time somebody makes a decision on a number that was never right.
No accuracy rate, latency or success figure appears here. The repository's own README carries such numbers and nothing behind them backs those up, so they are deliberately not repeated on this site. A trade stated without a measurement is an argument, and this page claims only to be an argument.
The reasoning, published.
This page describes a problem class rather than a client engagement. These are the pieces where the same reasoning is worked through in full.
- ArticleShell scripting that scalesFailing loudly rather than silently, at the level of the glue. A system that swallows an error and returns a number anyway is the exact failure this build is written around.
- ServiceAI infrastructure and agent orchestrationThe standing offering this build sits under, with what ships and what it buys you set out per offering.
Ask about any of these.
The specifics are not on this page. Ask for them directly, or send the problem you actually need solved.