Open-source Python SDK · Persian and English

Text-to-SQL, without letting the model write SQL.

SageQL lets managers ask for reports in Persian or English. A language model only chooses from what the host registered; deterministic code checks permissions, writes parameterized SQL and runs it read-only. A wrong or manipulated model can produce a wrong report, never an unauthorized query.

See recorded examples Source on GitHub

Designed and built by Sina Qasempour · Portfolio · Résumé · LinkedIn

The model never sees your schema No table names, column names or policy values in any recorded model input. Checked automatically. See the recorded examples → Attacks don't become queries Prompt injection, SQL in the chat, an invented column and SQL hidden in a filter: none produced an unauthorized query. Try to break it → Less model, better reports Nearly 3× more correct reports with half the model calls, after planning moved from the model into code. Measured results →

What changes when the model doesn't write SQL

	Model-written SQL	SageQL
Who writes the query	The model	SageQL's compiler, from registered IDs
Joins	Chosen by the model	Only relationships the host registered
Row and tenant filters	Requested in the prompt, or checked afterwards	Added to every query from the authenticated user
What the model sees	Table and column names, often sample rows	Business labels and IDs; never rows, SQL or physical names
When the model is wrong or manipulated	A wrong or unauthorized query can run	A wrong report at worst; anything unregistered is rejected before SQL exists

How a request becomes a report

ModelExtract intent Picks registered measures, groupings, period and filters by ID, or asks a question.
SageQLValidate Every ID must be registered and allowed for this user. Anything else is rejected.
SageQLResolve Dates, Solar Hijri months and product names are resolved locally.
SageQLCompile Writes the SQL with the user's row policy and bound parameters.
SageQLExecute Read-only, with row, time and work limits. Rows never go back to the model.

Recorded examples

Each turn shows what the model received and returned, the SQL SageQL wrote with the store policy highlighted, and the reply. All data is invented: a two-store bookshop and café, viewed as the manager of the north store.

Try to break it

Two attempts by a user, recorded against a real model, and two replies from a deliberately hostile model, written by hand. The outcomes below are read from the recorded runs.

Measured results

27 scored reports across fixed synthetic multi-turn conversations, all models at low reasoning effort.

Setup	Correct reports	Model calls / 40 turns	Median turn
`gpt-5-nano` for every stage	8/27	76	8–21 s
`gpt-5-mini` intent, nano planner and reviewer	15/27	87	16–21 s
`gpt-5-mini` intent, locally compiled spec, no reviewer	22/27	34	~7 s

Compiling a complete intent locally, instead of asking a second model to plan it, removed more than half the calls and nearly tripled accuracy over the nano baseline. Full comparison.

Everything after the model (validation, policy, SQL compilation and execution) is covered by about 2,200 offline tests that run in CI on Linux and Windows, Python 3.10–3.15.

Why I built it

In July 2026 I built QuerySmith: a language model wrote T-SQL for SQL Server, and a guard checked it. It allowed one SELECT, no comments or extra statements, only columns inside a scope, plus access profiles and result masking. Each protection meant recognizing one more pattern in SQL the model had invented.

In September I started SageQL by inverting that design. The model never writes SQL. It picks registered concepts by ID, and SageQL compiles the query itself, so tenant filters, joins and limits come from code instead of from text a model produced. The question changed from "is this SQL safe?" to "is this a report the host allowed?", which is much easier to answer exactly.

The reports I had in mind are the ones managers ask for in Persian, with Solar Hijri dates, so Persian is the default and the calendar is resolved locally rather than by the model.

Limitations and next steps

The benchmark is small. 27 scored synthetic reports; results vary by about ±2 reports between runs.
Understanding still fails sometimes. The model can drop a filter or pick the wrong period or limit. Every report states its interpretation, so a user can catch it.
Only registered operations. No arbitrary formulas, share-of-total or model-chosen joins yet; those requests are declined rather than approximated.
SQL Server is compiled and checked offline, but not yet tested end to end against a live server in CI; SQLite runs every test.
Authentication belongs to the host. SageQL enforces the policy it is given.

Next: letting users correct an interpretation in one click, a library of verified questions, more report operations, and a larger public evaluation. Roadmap.