Gate LLM-generated requirements with 22 questions

01 · Role in the system

What Jev does here

Each requirement goes out as state - the line, project context, existing requirements, the whole document - in one call whose parallel atomic questions cover five MECE facets: wording, content, reality, relationships, governance, aimed at where generated requirements fail: hallucination, intent distortion, infeasibility, redundancy, contradiction, hidden dependencies. Jev answers with calibrated signals only - never rewriting or explaining - and code routes by thresholds to pass, human review, or reject. Thresholds ship calibrated on real Jev output, a SQLite cache means one judgment is paid once and re-thresholded free, and an export-eval loop tunes thresholds from human labels. Document mode splits a spec into numbered requirements. Ships as CLI, Python API, agent skill, GitHub Action, and pre-commit hook, with a keyless playground and a Jev-versus-DeepSeek benchmark.

02 · Control boundary

Where Jev sits

Requirement plus document context to one batched 22-question request; threshold routing to pass, review, or reject in code; caching makes threshold tuning free, and human labels calibrate back.

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

• The 22-question profile and thresholds are the author's calibration on the author's test set; other requirement styles need the profile and threshold files retuned.
• Benchmarks compare against one DeepSeek baseline captured by the author, not a sweep of models.
• Requirement splitting in document mode is heuristic and meant to be human-confirmed before gating.

04 · Attribution

Public sources

This is a Community record: the project was published by a third-party community author.

• thomaszta ↗Community · github · public · checked 2026-09-26