Try it

Copy the code ↓
  1. Data source
  2. Decision schema
  3. Model inference
  4. Structured result
Demo · no sign-in
2 Decision schema 3 typed questions
  • ruling_fitchoicecoversresembles_onlygoes_furtherunrelated
  • coversnoulprobability 0–1
  • same_guidelinenoulprobability 0–1

3 Model inference typesafe/jev-1.13

Waiting for a run.

4 Structured result

Run the demo to see the JSON answers, the highlighted pick and the final action.

Call Jev yourselfSame data and schema, straight to Flatkey. Set FLATKEY_API_KEY and run.
curl -sS https://router.flatkey.ai/api/alpha/decisions \
  -H "Authorization: Bearer $FLATKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "model": "typesafe/jev-1.13",
  "state": "Finding: Error envelope rule. API handlers must return the team error envelope, not a bare error object.\n\nHunk:\n--- a/tests/fixtures/payments_stub.py\n+++ b/tests/fixtures/payments_stub.py\n@@ -12,6 +12,9 @@ def charge(request):\n     if request.headers.get(\"x-simulate-failure\"):\n-        return JSONResponse({\"ok\": False}, status_code=500)\n+        return JSONResponse({\"error\": \"failed\"}, status_code=500)\n     return JSONResponse({\"ok\": True, \"charge_id\": \"ch_test_123\"})\n\nRuling: Error envelope rule: fixtures under tests/ are exempt, because they never ship.\n\nTask: ruling_fit, covers, same_guideline.",
  "questions": {
    "ruling_fit": {
      "type": "choice",
      "instructions": "A code-review check flagged `hunk` under the guideline named in `finding`. Read the reviewer ruling in `ruling` literally, including its scope and reason. How does the ruling relate to this hunk?",
      "criteria": {
        "covers": "The hunk is squarely inside the scope the ruling names, for the same guideline, and the ruling'\''s reason applies to it",
        "resembles_only": "The hunk looks like the case the ruling was written for, but its path, purpose or context is outside the stated scope",
        "goes_further": "The hunk is partly in scope but does more than the ruling allows, for example code that is imported by something that ships",
        "unrelated": "The ruling is about a different guideline, a different part of the codebase, or a different kind of change"
      }
    },
    "covers": {
      "type": "noul",
      "instructions": "Does the ruling in `ruling` cover `hunk` exactly as the ruling states its scope?",
      "criteria": {
        "true": "The hunk is squarely inside the scope the ruling names.",
        "false": "The hunk is outside that scope, only resembles it, or goes further than the ruling allows."
      }
    },
    "same_guideline": {
      "type": "noul",
      "instructions": "The ruling is about the same guideline the finding was raised under."
    }
  }
}'

No Flatkey key yet? Get one for Jev 1.13 →

Run with real Jev

Sign in and connect a key

  1. Sign in with Google.
  2. Connect your Flatkey or OpenRouter key on the next screen. Get a Flatkey key for Jev 1.13.
  3. Come straight back here and press Run again.

This site is for researching, sharing and cataloguing Jev use cases. Your key is only there to make trying Jev convenient: it is stored encrypted, used only for runs you trigger, never used for anything else, and you can delete it anytime.

Sign in with Google

About this use case

Use Jev to honor code-review rulings: incoming state, Jev decision, routed outcome

Who / when

Audience

  • teams running an automated code-review check that people keep dismissing by hand
  • builders of semantic linting on Jev who need reviewer corrections to stick
  • platform teams that store team rules and past rulings in a knowledge base or memory store
  • anyone whose decision model cannot be fine-tuned and must carry corrections in the request

Triggers

  • the same finding is raised on the third pull request this week after a reviewer already dismissed it
  • a reviewer writes "fixtures under tests/ are exempt" in a comment the check never reads
  • stuffing every rule and every past ruling into one request makes the judgment worse
  • a ruling written too broadly starts exempting code it was never meant to cover

The workflow

  1. 01
    Hunk + findingOne diff hunk with its file path, the guideline it was flagged under, and one stored ruling for that guidelineInput
  2. 02
    How does it fit?Covers, only resembles, goes further than allowed, or unrelatedJev
  3. 03
    Ruling covers?Yes/no probability that the hunk is squarely inside the ruling's scopeJev
  4. 04
    Code gate≥ 0.7 exempt, 0.3–0.7 a person decides, < 0.3 the finding stands; log the ruling usedYour code

Question shape

{
  "ruling_fit": {
    "type": "choice",
    "instructions": "A code-review check flagged `hunk` under the guideline named in `finding`. Read the reviewer ruling in `ruling` literally, including its scope and reason. How does the ruling relate to this hunk?",
    "criteria": {
      "covers": "The hunk is squarely inside the scope the ruling names, for the same guideline, and the ruling's reason applies to it",
      "resembles_only": "The hunk looks like the case the ruling was written for, but its path, purpose or context is outside the stated scope",
      "goes_further": "The hunk is partly in scope but does more than the ruling allows, for example code that is imported by something that ships",
      "unrelated": "The ruling is about a different guideline, a different part of the codebase, or a different kind of change"
    }
  },
  "covers": {
    "type": "noul",
    "instructions": "Does the ruling in `ruling` cover `hunk` exactly as the ruling states its scope?",
    "criteria": {
      "true": "The hunk is squarely inside the scope the ruling names.",
      "false": "The hunk is outside that scope, only resembles it, or goes further than the ruling allows."
    }
  },
  "same_guideline": {
    "type": "noul",
    "instructions": "The ruling is about the same guideline the finding was raised under."
  }
}

Gate policy

covers ≥ 0.7

Exempt the finding in code, post the decision with the ruling that resolved it to the review record, and do not comment on the pull request.

0.3–0.7

Send it to a person (or a reasoning model) with the hunk, the finding and the ruling side by side; save their answer as a new, narrower ruling.

covers < 0.3

The finding stands: post it on the pull request as usual and record that this ruling was checked and did not apply.

Failure modes

Pre-launch checks before you trust auto-routing:

  • Keeping reviewer corrections only in pull-request comments, so the check never sees them and raises the same finding on every pull request;
  • Putting rulings into the first judging request, so one ruling can quietly change decisions it was never written for;
  • Pasting every rule and every past ruling into each request; accuracy drops as the state fills with text unrelated to the decision;
  • Writing a ruling without a reason, so it matches look-alike code (a helper imported by something that ships) and exempts it;
  • Letting a ruling make a rule stricter or override a block; rulings should only exempt, and stricter rules belong in the guidelines;
  • Treating the probability as a verdict with no middle band, so borderline hunks are silently exempted or silently flagged;
Keep exact work in code: splitting the diff into hunks, loading the guidelines, storing rulings in a fixed shape (rule name, scope, reason), looking up only the rulings for the flagged guideline, the 0.3 / 0.7 cutoffs, and the audit record. Jev answers the meaning-level questions only: first whether the hunk breaks a guideline (with no rulings in that request), then, one ruling at a time, whether that ruling covers the hunk. Path patterns, counting and date checks stay in code, because Jev reads them as text.

FAQ

Why can't the correction just go into the model?

Jev is not fine-tuned on your data. You shape its behavior only through the state and question fields of each request, so a reviewer's correction has to be stored somewhere else, found again for a similar hunk, and sent with the next request.

Why ask about rulings in a second, separate request?

Keeping the guideline judgment and the ruling check apart means a ruling can only change the decision it names. Rulings are looked up only for findings that were not already dropped, and each ruling is checked on its own, one question per ruling.

What should a stored ruling look like?

A fixed shape: the rule's name, the scope, and the reason, for example "Error envelope rule: fixtures under tests/ are exempt, because they never ship." The name lets code find rulings for one rule, and the reason keeps the ruling narrow so it does not exempt look-alike code.

Where do the 0.3 and 0.7 cutoffs come from?

They are the starting bands used in the Yugabyte write-up linked below. Treat them as the first thing to tune: run the check on findings your team has already judged and move the cutoffs until clear cases land in the right band and borderline ones land in the middle.

What does the Flatkey call look like?

POST https://router.flatkey.ai/api/alpha/decisions with Authorization: Bearer …, Content-Type: application/json, and a body of state (hunk, finding, ruling), model (typesafe/jev-1.13), and questions (choice / noul). This is not an OpenAI-compatible /v1 chat endpoint. Get a key for Jev 1.13 on Flatkey.

Can I bring my own API key?

Yes. Try the free demo above without signing in. To run it live on your own text, sign in with Google and connect a Flatkey or OpenRouter key (a quick test call runs when you save it). Manage or delete it anytime under Dashboard → BYOK. Keys are stored encrypted on the server, used only for runs you trigger, and never sent back to the browser. Need a Flatkey key? Get one for Jev 1.13 on Flatkey.

Is this the official TypeSafe Jev product page?

No. jev-llm.com is an independent research and practice site. Verify pricing, models and terms at the original TypeSafe sources.

Sources

Seen on X
Independent-site note: jev-llm.com is an independent research and practice site. It is not the TypeSafe AI official site. Verify models, pricing and terms at the original source.