agenticfabriq/mnemiq

**Text-to-SQL you can tune to your database.** */NEM-ik/ — the "m" is silent, as in mnemonic.*
*By Agentic Fabriq (YC W26) — made with love, from MIT.*
An open-source engine that answers natural-language questions over your database, built so that
every stage between the question and the SQL is a setting you can read, change, and measure.
Two answers and a refusal. The third question asks for revenue the database does not hold, and the
engine says so — naming the columns it would have needed — instead of returning a number that looks
right. That distinction is the whole design.
**Read more** · Product page ·
Launch article ·
Technical report (PDF, DOI 10.5281/zenodo.22806094) ·
Paper (PDF) ·
beacon — the grader and results tracker
Why mnemiq exists
Every text-to-SQL product has an accuracy number. Almost none of them were measured on a database
that looks like yours.
A system can do well on a benchmark and then struggle on your warehouse because the schema is
larger, the naming is different, the business definitions live in people's heads, or the
configuration that suited the benchmark simply doesn't suit your data. When it underperforms, a
closed system gives you no way to find out why, and nothing to change.
So the question worth asking isn't *how accurate is it*. It's:
> How well will this work on my database — and what can I change if it doesn't?
mnemiq is built to make both halves answerable. It is Apache-2.0, runs inside your own environment
on models you choose, and exposes the major parts of the pipeline as settings rather than
internals. No accuracy number applies to your database until you have run it on your database;
mnemiq is the engine and the evaluation harness for doing that.
How it works
mnemiq separates writing SQL from deciding to run it. A model proposes a query. A deterministic
layer then rules on it before anything touches the database. The query has to be read-only, may
only reference objects the caller is allowed to see, has to compile in the source's own SQL
dialect, and has to survive an EXPLAIN. Fail any of those and you get a refusal with a stated
reason rather than a plausible number.
Two properties fall out of that ordering. Permissions apply *before* schema retrieval, so the model
is never shown a table the caller may not see — naming it is useless rather than refused. And every
answer carries a trace: the SQL as asked, the tables it touched, the enrichment version behind it.
Where a row or column policy rewrote that SQL, the answer says which tables it narrowed, and the
statement as executed -- which can name the policy's own tables -- is kept in the audit trace.
Read the diagram left to right, top to bottom. The stages in red are the ones that can stop an
answer: the decider refuses or repairs, execution runs under policy, and verification can defer.
The model appears once, at stage 05, and everything around it is deterministic.
The pipeline is settings, not internals
The parts people usually can't reach are the parts mnemiq puts in your hands:
- **Which model writes the SQL** — hosted or local, one candidate or several.
- **How much schema context is retrieved**, and how it is ranked.
- **How much semantic enrichment is built**, and whether a human certifies it.
- **How aggressively the system refuses** — the verifier and its threshold.
- **What the decider enforces**, including row and column policy applied to the query tree rather
than requested of the model.
Each of those is a dial with a cost on the other side, which is why they are dials and not
defaults. More context is not free. More compute is not automatically better. The right setting
depends on your data, and the point of the harness is that you can find out rather than guess.
The semantic layer has tiers
Before any question is asked, mnemiq can inspect the database and build context around the schema:
- **Tier 0** — tables and columns only.
- **Tier 1** — adds structural information: primary and foreign keys, profiling, value
distributions.
- **Tier 2** — adds meaning an LLM proposes: table and column descriptions, grain, glossary terms,
coded-value meanings.
Enrichment is a multiplier on meaning that isn't already in the schema. Where column names already
say what they hold, richer cards add length without adding signal. Where three columns are all
called *revenue* by three different teams, the meaning is in a person, not the schema — and that is