v0.1.0, open source, Apache 2.0

Ask your tables questions in plain English.

sqljev adds jev() to SQL Server, PostgreSQL, MySQL, Snowflake, Databricks, BigQuery, Redshift and DuckDB. Every row is judged by Laya, an open-weights decision model that runs on your own hardware and learns from your own tables.

View on GitHub pip install "sqljev[laya,db]"
DuckDBtickets.sql

        

Real output: Laya's English checkpoint on CPU, all 8 rows in one forward pass.

Same functions, every database.

Pick your database for a three-step setup you can copy. Each database already hands its functions rows in batches. sqljev takes each batch as it comes, so a thousand rows become a handful of forward passes, not a thousand calls.

One question, many rows, very little work.

A SQL question is the same question asked of every row. So rows are de-duplicated, looked up in a cache, and only the new ones reach the model, packed into shared forward passes.

  1. Rows as JSONEach row becomes a compact object of its columns. NULLs are dropped to save tokens.
  2. De-duplicateIdentical rows are judged once, however often they appear.
  3. Answer cacheRows already judged for this question come straight back. Edited rows are judged again.
  4. BatchThe rest are packed into shared forward passes, sorted by length to waste less padding.
  5. AnswerCalibrated probabilities flow back into your query: filter, sort, group.

100,000 rows. 13 questions. One laptop GPU.

Ten realistic tables (support tickets, product reviews, adverse-event reports, expenses, job posts, rentals, contract clauses, advisor emails and company records to match) with exact labels. Every question is a plain SQL query through DuckDB, answered by the base Laya checkpoint with no training at all.

516decisions per second
4.5 minfor all 140,000 decisions
0.9 sto run all 13 queries again
accuracy, base model below 0.75: fine-tune it always guessing the most common answer

Synthetic data generated by python -m sqljev.demo; reproduce with python bench/run.py. Laya English checkpoint, zero-shot, RTX 4090 Laptop GPU shared with another model.

Filter, rank, classify, score.

Four kinds of answer, all ordinary SQL functions, so they compose with joins, GROUP BY and LIMIT like anything else.

subject jevjev(t, 'wants a refund') jev_probjev_prob(t, 'is angry') jev_choicejev_choice(t, 'which team?', …) jev_score_normjev_score_norm(t, 'how urgent?', …)

Illustrative values.

jev(row, condition [, threshold]) is true when the row satisfies the condition.
jev_prob(row, condition) returns the probability, 0 to 1, for ranking and thresholds.
jev_choice(row, question, options) returns the most likely option.
jev_score(row, question, levels) places the row on ordered levels; _norm scales it to 0–1.

Laya by default. Jev when you want it.

Both are System One models: they don't write text, they return probabilities. They trade off differently, and you can switch with one setting.

Accuracy, zero-shot

Laya
0.362
Jev
0.727

Accuracy, fine-tuned on the task

Laya
0.766
Jev
n/a

Time per decision

Laya
33 ms
Jev
~250 ms

Laya is Apache 2.0 with open weights. It runs on your GPU or CPU, so rows never leave your network and nothing is billed per token. Out of the box it is good at clear yes/no conditions and weaker at fine-grained choices.

Jev is TypeSafe's hosted model: stronger zero-shot, but your rows travel to an API and it cannot learn your domain.

Your tables are full of labels, which is why sqljev is built around fine-tuning Laya on them.

Figures from Laya's published typed-decisions benchmark (T4 GPU for latency).

Teach Rowl your tables.

Every labelled column is training data. Export it, fine-tune Laya, measure on held-out rows, and serve the new checkpoint to every database at once.

Labelled rowsany table with an answer column
sqljev datasettrain / test JSONL
sqljev finetuneColab, free T4 GPU
sqljev evalaccuracy on your rows
held-out accuracy0.694

69.4% → 100% on 1,000 held-out adverse-event reports (was the event serious?) after 2 minutes of training on a laptop GPU. The demo reports are built from templates, so they are easy to learn: expect a smaller jump on real data, and measure it with the same notebook.

Open the notebook, pick a question, press Run all. It measures the base model on held-out rows, fine-tunes, measures again, and publishes the checkpoint for your team.

Open in Colab

# or from a terminal with a GPU
sqljev dataset "$DB_URL" "SELECT drug, narrative, serious FROM adverse_events" \
    --label serious --noul "the adverse event was serious" --test-fraction 0.25 -o ae.jsonl
sqljev eval ae.test.jsonl                                 # base model
sqljev finetune ae.train.jsonl --out checkpoints/ae
sqljev eval ae.test.jsonl --model checkpoints/ae          # fine-tuned
sqljev publish checkpoints/ae --repo your-org/laya-ae     # the whole team uses it

What people ask their rows.

Anything SQL can't say with =, LIKE or a regex. Keep dates, sums and exact matches in SQL, and let the model judge meaning.

Support

WHERE jev(t, 'the customer threatens to cancel') AND created_at > now() - interval '7 days'

Pharmacovigilance

jev_prob(r, 'the adverse event report describes liver injury')

Compliance

WHERE jev(e, 'the email promises a guaranteed return')

Routing

jev_choice(t, 'which team should handle this?', ['billing','technical','security'])

Triage

ORDER BY jev_score(i, 'how severe is this incident?', ['minor','major','critical']) DESC

Entity resolution

SELECT a.id, b.id FROM crm a JOIN billing b ON a.city = b.city AND jev(to_json({'a': a.name, 'b': b.name}), 'both are the same company')

Expense audit

GROUP BY jev_choice(x, 'what kind of business expense is this?', ['travel','meals','software','entertainment'])

Data quality

WHERE NOT jev(a, 'this is a real postal address')