l0l1

Overview

l0l1 sits between a language model and a data warehouse, and its premise is that the interesting risk in AI-assisted analytics is not a wrong query but a leaked one. Getting a model to write SQL is largely solved. Getting it to write SQL without sending the schema, sample rows, or the analyst's own question to a third party is not, and in a regulated environment it is the question that decides whether the tool can be used at all.

The toolkit does three things. It validates model-generated SQL against the live schema before execution, catching the hallucinated column and the silently-wrong join before they produce a plausible number. It scans queries and prompts for personally identifiable information before anything leaves the local process, which is a different control from redacting results after the fact. And it learns approved query patterns per workspace, so the shapes a team has already reviewed become the shapes it suggests.

Validating against the live schema rather than a cached description is the decision that does most of the work. A model that was shown last quarter's schema writes confident queries against columns that have since been renamed, and the failure is a wrong answer rather than an error. Checking against the connection that will actually run the query closes that gap.

It connects to PostgreSQL, MySQL, SQLite and DuckDB, and meets analysts where they already are: a CLI, a REST API, a Jupyter magic and a VS Code integration over LSP. That surface area is deliberate — a data-governance tool that requires people to leave their notebook is a tool that gets bypassed.

The pattern learning is the part we are least sure about. Learning from approved queries risks entrenching whatever the team already does, including the bad habits, and a suggestion system that reproduces an inefficient join because three people used it is not obviously an improvement. We currently treat learned patterns as suggestions rather than as defaults, which limits both the benefit and the damage.

Where it loses: a general Text2SQL tool or a commercial analytics copilot will have broader dialect coverage and a more polished experience, and if the data is not sensitive the privacy machinery is pure overhead. l0l1 is for the case where a query cannot leave the building.

For an evaluation, the question to ask first is where the boundary of the local process actually falls in your deployment. A PII scan that runs before the prompt leaves the machine is a meaningfully different control from one that runs inside a vendor's infrastructure, and the difference is invisible in a feature comparison. If the model itself is hosted remotely, l0l1 reduces what is sent rather than eliminating the transfer, and a deployment that needs the stronger property has to pair it with a local model.