Community · E2 · artifact verified
Ask Jev inside SQL and get real types back
A DuckDB extension where jev_choice, jev_score, and jev_noul are scalar functions over table rows: the criteria literal is both the set of permitted answers and the column's SQL type.
01 · Role in the system
What Jev does here
jev_choice(text, MAP{option: meaning}) returns an ENUM of exactly those options; jev_score(text, [worst...best]) returns a DOUBLE on that rubric; jev_noul returns the probability of yes; and jev_ask bundles many questions into one STRUCT, each field carrying its confidence beside it. Because the criteria literal is the type, answers are typed by construction - an empty option map, a duplicate option, a one-level rubric, or a non-constant criteria fails when the query is planned, not on row 400,000. Requests batch sixteen rows at a time, identical requests hit a process-lifetime cache, and jev_usage() reports requests, cache hits, and tokens so the cost of a query is visible before the invoice. The README frames the honest billing model: one request per row, so treat these functions like a join against a paid service.
02 · Control boundary
Where Jev sits
Criteria literals define both the question set and the SQL column type; requests batch per chunk, dedupe through a process cache, and report usage through jev_usage().
Code owns the loop, permissions, thresholds, validation, and side effects. Jev owns only the bounded judgments described above.
03 · Known limits
What this evidence does not prove
- One paid request per row: the README's own guidance is to treat the functions like a join against a paid service.
- Criteria must be constant across rows, because it is both the question set and the column type.
- Errors fail the whole query by default; jev_on_error='null' trades rows for query survival.
04 · Attribution
Public sources
This is a Community record: the project was published by a third-party community author.
- colliber ↗Community · github · public · checked 2026-09-20