Jev for Search and Data: pg-jev, llama-index-jev and jev-curate
Semantic filters inside SQL, a LlamaIndex reranker and router, and a dataset sifter: three Jev projects that put typed decisions into data pipelines, with their real limits.
Data work is full of judgments that SQL cannot express. Which tickets are from frustrated customers? Which retrieved passages actually answer the question? Which rows in a training set are low quality? The usual answer is to send each item to a language model and parse whatever it writes back.
Jev, TypeSafe AI's decision model, offers a narrower tool: return a typed score, a choice or a probability, and let ordinary code do the rest. Three open-source projects bring that into familiar places: a PostgreSQL extension, a LlamaIndex integration and a dataset command-line tool. All are on the Awesome Jev radar. Their evidence ranges from a documented small test to nothing beyond a README.
Key Takeaways
- pg-jev puts semantic conditions inside SQL, composing with joins,
GROUP BYandORDER BY. It is the most concrete of the three, with 137 stars as of September 2026. - Every row leaves your database. pg-jev sends row contents to TypeSafe's servers and does not use indexes. Filter with ordinary predicates first.
- llama-index-jev reports one benchmark: BEIR nfcorpus nDCG@5 rose from 0.340 to 0.396, self-reported by the maintainer.
- jev-curate's 1,500 rows/sec depends on concurrency. The figure assumes many worker threads, not a single sequential stream.
- Two of three have 1 to 2 stars. Treat them as prototypes.
pg-jev: semantic WHERE clauses
pg-jev (aiskill.market page) is a Postgres extension. Its functions include jev(row, condition) for boolean WHERE predicates, jev_prob(row, condition) for a 0-to-1 probability, and jev_choice() and jev_score() for classification and scoring. The README says these compose with everything else in SQL: AND age > 40, joins, GROUP BY, LIMIT, ORDER BY jev_prob(...).
Rows are batched into requests rather than judged one at a time, and answers are cached per row content within a session, so reruns and threshold changes are nearly free. The README's example: on a 129-row table, the first run took about 1 second over 4 requests at roughly $0.0009, and later runs about 6 ms. That 6 ms is a cache hit, not model inference, and the 129-row sample is the author's own test.
The limits are stated plainly. Every row goes to an external API, so it is a full scan, and probability-based filtering cannot use indexes. Row contents travel to TypeSafe's servers, which makes it unsuitable for sensitive data. Use indexed predicates to shrink the candidate set before Jev sees it.
llama-index-jev: rerank and route
llama-index-jev (listing) offers JevRerank, which scores retrieved passages on a 0-to-3 relevance scale and keeps the top-n, plus JevSingleSelector and JevMultiSelector for choosing which query engine or tool handles a request.
Its README makes a specific claim: on BEIR nfcorpus (323 queries), reranking improved nDCG@5 from 0.340 to 0.396, at about $0.096 for the split, or roughly $0.0003 per query. That is the maintainer's own protocol and has not been independently reproduced. The site's review classifies the project as auto-summarized with 2 stars.
The failure design is thoughtful. Rerank fails open: on an API error you get the original retrieval order, truncated to top_n. Select fails closed: a routing error raises an exception unless you set a default_index, because a wrong tool is worse than an error. It also scores one query-passage pair per call rather than batching, citing concern about "context rot." That choice trades cost for isolation.
jev-curate: sifting datasets
jev-curate (listing) streams Parquet and JSONL datasets and evaluates each row with Choice, Score (a 1-to-5 ordinal) or Noul (a calibrated probability). Data stays verbatim; nothing is rewritten. An example preset, reasoning-math, checks has_circular_logic, is_step_valid and reasoning_depth.
The headline 1,500+ rows/sec comes with context: it assumes concurrent workers (32 by default) and an adaptive token-bucket rate limiter to avoid HTTP 429 errors, and no sequential guarantee is stated. It cites Jev pricing of $0.042 per million input tokens with no output fees. It depends on external API availability, and it had 1 star as of September 2026.
Choosing between them
| Need | Tool | Evidence quality |
|---|---|---|
| Semantic filter in existing SQL | pg-jev | Real interface; small self-run test |
| Better RAG ordering, tool routing | llama-index-jev | One self-reported benchmark |
| Quality filter on a training corpus | jev-curate | README claims only |
What to do next
- Try pg-jev on a non-sensitive table with a cheap indexed filter first, and log how many rows actually reach the API.
- Reproduce the reranking result on your own retrieval set before trusting 0.340 to 0.396.
- Sample-audit jev-curate's decisions on a slice of data you can label yourself.
- Read how others use scores as gates in Typed Decisions vs Free Text, and apply How to Evaluate Jev Projects Honestly to anything at 1 or 2 stars.