1. Data source
  2. Decision schema
  3. Model inference
  4. Structured result
2 Decision schema 3 typed questions
  • lint_verdictchoicepasswarnfailneeds_review
  • pii_severityscorenonelowhigh
  • redaction_presentnoulprobability 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": "Rule: never write PII (emails, phone numbers, addresses, tokens) to logs.\nFile: src/api/signup.ts  line 42 (added)\n+ logger.info(\"signup ok\", { user: req.body, plan: plan.id });\nContext: req.body = { email, phone, password, referralCode }; logger ships to Datadog; no redaction middleware on this route.\nTask: semantic lint verdict for this line — pass / warn / fail / needs_review (+ pii_severity, redaction_present).",
  "questions": {
    "lint_verdict": {
      "type": "choice",
      "instructions": "Apply the semantic lint rule to the changed code. Rule: changes must not write personally identifiable information (emails, phone numbers, addresses, names, government ids, auth tokens) to logs, analytics or error reports. Decide the lint result for this change.",
      "criteria": {
        "pass": "The change does not write PII anywhere; logged values are ids, counts, enums or already-redacted",
        "warn": "Possible PII exposure that depends on runtime data or configuration; flag it but don'\''t fail the build",
        "fail": "The change clearly writes PII (or an object that contains PII) to a log, analytics event or error report",
        "needs_review": "Not enough context in the diff to judge; a human should look before merge"
      }
    },
    "pii_severity": {
      "type": "score",
      "instructions": "How sensitive is the most sensitive personal data this change could expose in logs or telemetry.",
      "criteria": [
        "none",
        "low",
        "high"
      ]
    },
    "redaction_present": {
      "type": "noul",
      "instructions": "The change already masks, hashes or redacts every personal field before it is logged."
    }
  }
}'

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.

About this use case

Use Jev as a semantic PII linter: incoming state, Jev decision, routed outcome

Who / when

Audience

  • platform and DevEx teams who want meaning-level lint rules in CI next to ESLint
  • teams letting coding agents open pull requests that touch logging, analytics or error reporting
  • security and privacy engineers who own rules like "no PII in logs" but can't express them as regex

Triggers

  • a diff adds or changes a log, print, analytics or error-reporting call
  • a logged object may carry user fields (email, phone, address, tokens) even though no field name looks sensitive
  • a coding agent's pull request touches request handlers, auth or payment code paths
  • a regex or AST rule fires too often on safe identifiers, so the team has started ignoring it

The workflow

  1. 01
    Diff + ruleFile, line, English ruleInput
  2. 02
    Score PII severitynone / low / highJev
  3. 03
    Lint verdictpass / warn / fail / reviewJev
  4. 04
    CI gateReport file:line, fail or passYour code

Question shape

{
  "lint_verdict": {
    "type": "choice",
    "instructions": "Apply the semantic lint rule to the changed code. Rule: changes must not write personally identifiable information (emails, phone numbers, addresses, names, government ids, auth tokens) to logs, analytics or error reports. Decide the lint result for this change.",
    "criteria": {
      "pass": "The change does not write PII anywhere; logged values are ids, counts, enums or already-redacted",
      "warn": "Possible PII exposure that depends on runtime data or configuration; flag it but don't fail the build",
      "fail": "The change clearly writes PII (or an object that contains PII) to a log, analytics event or error report",
      "needs_review": "Not enough context in the diff to judge; a human should look before merge"
    }
  },
  "pii_severity": {
    "type": "score",
    "instructions": "How sensitive is the most sensitive personal data this change could expose in logs or telemetry.",
    "criteria": [
      "none",
      "low",
      "high"
    ]
  },
  "redaction_present": {
    "type": "noul",
    "instructions": "The change already masks, hashes or redacts every personal field before it is logged."
  }
}

Gate policy

≥ 0.90

pass lets the check go green; fail blocks the merge and reports file, line, rule and probability like a normal linter error.

0.65–0.90

Report as a warning annotation on the line and suggest a redaction helper; don't fail the build.

< 0.65

Mark needs_review and request a reviewer from the owning team; keep the probability in the report.

Failure modes

Pre-launch checks before you trust auto-routing:

  • Grepping for field names like email or ssn and missing a whole req.body or user object being logged;
  • Failing the build on every log line that contains the word "user", until the team disables the rule;
  • Asking a chat model for a free-text review and parsing "looks fine" as a pass;
  • Letting the coding agent that wrote the change also decide whether its own change leaks PII;
  • One global threshold, so uncertain lines either block merges or silently pass;
Keep exact work in code: syntax, formatting, known secret patterns, allow-listed redaction helpers and the file/line mapping stay in ESLint, regex and your CI script. Use Jev for the meaning-level rules a parser can't express—does this object carry personal data, is it already redacted, is the exposure real—and let the gate bands decide what fails.

FAQ

How is a Jev semantic lint different from an ESLint rule?

ESLint rules match syntax and AST patterns. A semantic rule is an English yes/no question about meaning, such as whether a change will leak PII in logs. Jev answers it with calibrated probabilities, so your CI can report file, line, rule and probability like a normal linter and only fail above a threshold.

Where does it run in CI?

After your normal linters. Take each changed hunk that touches logging, analytics or error reporting, send it with the rule text to Jev, and turn the typed answers into lint annotations. Pass and high-confidence fail are automatic; the middle band becomes warnings or reviewer requests.

Does it replace secret scanners or regex rules?

No. Keep secret scanners, known-pattern regexes and allow-listed redaction helpers. Jev covers the cases they miss, like logging a whole request body or user object whose fields aren't visible at the call site.

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.