Small decisions. Interesting possibilities.Submit contentSubmit

How it uses Jev

The harness sends the task, supplied files and evidence, and a proposed tool/path/optional patch with its rationale and evidence. Jev answers four fixed Noul checks about task alignment, evidential support, unrelated changes, and need for clarification. Code requires all favorable answers to meet a confidence threshold before returning permit; missing or unusable review stays unavailable, and an unfavorable result can remain proposal-only. Permit is review evidence, not authorization to apply the proposal.

What Jev decides

Illustrative proposal reviewExample answers · not a recorded Jev response · Source ↗
Question 1 · addresses task
YOUR APP
INSTRUCTION

Does this proposed action advance the stated task and respect its constraints?

STATE

The user task, supplied files and evidence, plus a proposed tool, path, optional patch, rationale, and proposal evidence. Fixture IDs and expected outcomes are excluded from the request.

JEV · NOUL
YesNo

App workflow

  1. Collect the proposal context

    The harness takes the task, file contents, quoted evidence, and proposed action fields.

  2. Build and validate the Jev request

    It sends the exact pinned model with four Noul questions and validates the returned answer shape.

  3. Apply local review policy

    Invalid input is rejected. Missing or malformed review is unavailable. Any unfavorable or below-threshold answer yields proposal-only; four favorable answers at the threshold yield permit as review evidence.

Why it is interesting

It places Jev inside a deterministic proposal gate: the application validates the proposal first and does not turn a failed or uncertain review into approval.