jev-dataops, jevframe and jevql: Pipeline Tooling for Typed Decisions

Data pipelines have three recurring jobs that don't fit cleanly into SQL or a schema: deciding whether a row is good enough to keep, scoring it against a rubric, and routing it based on a judgment call. Three projects on the Awesome Jev radar each take on one layer of that problem, from a full dataset-to-training workbench down to a query-time function you drop into an existing Postgres database.

None of the three is a mature, widely-adopted framework — star counts here range from 12 to 52 — but each documents a distinct, useful shape for wiring typed Jev judgments into a pipeline you already run.

Key Takeaways

• jev-dataops screens data, trains a LoRA, and evaluates it — one workbench, three stages. A benchmark shows it processing 100,000 synthetic records in about 16 seconds with peak memory around 39 MiB.
• jevframe brings Jev's noul/choice/score primitives into pandas and Polars, with bounded async concurrency (default 16 simultaneous requests) and an interactive demo that works without an API key via a rate-limited shared gateway.
• jevql adds semantic SQL to plain PostgreSQL with no extension install — it rewrites queries so the database only ever runs ordinary SQL, and a separate CLI evaluates jev_* calls against the results.
• All three are early-stage. jevframe explicitly excludes chat interfaces and custom data types in v0; jevql's v1 doesn't support jev_* inside INSERT/UPDATE/DELETE, CTEs, HAVING, window functions, or SELECT DISTINCT.
• Row and record content leaves your machine in all three cases — this is API-dependent tooling, not a local-only pipeline.

jev-dataops: screen, train, evaluate, in one workbench

jev-dataops (listing) is the most end-to-end of the three: an open-source workbench that uploads JSONL or CSV datasets, screens them for quality using Jev via OpenRouter or TypeSafe, routes rows into keep/review/reject partitions based on configurable probability gates, then trains a LoRA fine-tune on what survives and evaluates the result against a held-out test set. It ships six domain-specific screening rubrics (general, finance and code among them) and supports multi-GPU training through distributed data-parallel LoRA or external verl GRPO/PPO environments.

The README gives concrete numbers for the demo path: an 84-row default dataset screens to an expected 80 kept, 2 reviewed, 2 rejected, and training requires a minimum of 6 independent groups post-screening. A separate synthetic benchmark reports processing 100,000 records in roughly 16 seconds with about 39 MiB peak process memory — a throughput figure worth noting, though it describes the screening step alone, not the full train-and-evaluate pipeline. It's explicitly single-host: no distributed multi-machine orchestration, no native Excel parsing, no audio evaluation, no annotation workbench or semantic deduplication, and the model to be trained must fit in available memory or VRAM. Installed via git clone plus a standard Python virtualenv, then jev-dataops serve. MIT-licensed for the source code (model weights and third-party APIs carry their own terms), 52 stars as of September 2026.

jevframe: Jev scoring as a pandas/Polars primitive

jevframe (listing) is narrower and more library-shaped: it exposes Jev's decision primitives directly as DataFrame operations. noul() handles yes/no classification, choice() does multi-category labeling, score() applies rubric-based grading, and evaluate() combines several questions per row into one call. Results come back as ordinary pandas or Polars Series and DataFrames, preserving row order and index, with full probability distributions rather than just a top label.

Evaluation runs asynchronously with bounded concurrency (16 simultaneous requests by default), optional in-memory caching for repeated identical queries, custom per-row context via callable functions, and a choice between raising exceptions or coercing missing values on error. Progress is trackable through tqdm or a custom callback. One specific claim worth noting: the README says its interactive demo works without an API key, routed through a sponsored gateway offering 2,000 new row requests per UTC day shared across all visitors — useful for a first look, not for real throughput. Install via uv add 'jevframe[pandas]==0.1.0', with optional Polars support and a TYPESAFE_API_KEY environment variable for your own key. The author is explicit that v0 covers row-wise decisions only, deliberately excluding chat interfaces, automatic analysis, custom data types and Excel integration. MIT-licensed, 13 stars as of September 2026.

jevql: semantic SQL without touching the database

jevql (listing) takes a different path than the database extensions covered in Jev Inside the Database: rather than installing a Postgres or DuckDB extension, it's a standalone CLI (also available as HTTP, MCP and SDK interfaces) that sits in front of a vanilla Postgres database and requires no extension or superuser privileges. Queries are rewritten so ordinary SQL predicates run in the database as normal, and a family of jev_* functions — filtering, scoring, multiple-choice classification, confidence scoring — are evaluated in the CLI or service layer against the rows the SQL query returns. The README states this directly: "the database only ever sees ordinary SQL." A local SQLite cache avoids redundant API calls for repeated queries.

Version 1 has real gaps to plan around: jev_* calls aren't supported inside INSERT/UPDATE/DELETE, inside CTEs, in HAVING clauses, in window functions, combined with OR jev(), or with SELECT DISTINCT or set operations — meaning jevql fits read-heavy analytical SELECT queries far better than transactional workloads. It defaults to a 2,500-row cap per query, adjustable with --max-rows, and follows TypeSafe's roughly $0.042 per million input tokens pricing. Row content is sent to an external API even though the database itself stays untouched. Install via Homebrew (brew install kylemclaren/tap/jevql), a prebuilt binary, or from source with Go 1.23+. MIT-licensed, 12 stars as of September 2026.

Picking a layer

These three sit at different points in a pipeline rather than competing directly. jevframe is the right layer if you already load data into pandas or Polars and want row-level judgments inline with the rest of your analysis code. jevql is the right layer if your data already lives in Postgres and you'd rather not install anything on the database server itself. jev-dataops is a heavier commitment — it assumes you're building toward a fine-tune, not just filtering or scoring a table — and its benchmark numbers describe the screening stage specifically, not the training or evaluation stages that follow it.

What to do next

• Start with jevframe or jevql if you just need row-level scoring — both are lighter-weight than committing to jev-dataops's full screen-train-evaluate pipeline.
• Check jevql's v1 SQL limitations against your actual query shapes before assuming it'll drop into an existing analytical workload unchanged.
• Reproduce jev-dataops's 100,000-record benchmark on your own hardware before using it to size a production screening job — memory and throughput depend heavily on record size and rubric complexity.
• Read Calibrating Jev Thresholds before setting probability gates in any of these three, since threshold choice is where most of the real tuning work in a Jev-based pipeline lives.