What about false positives on generated code?

Tighten the criteria or exempt the paths in CI before the call. One noisy path is a config fix; a noisy model is a criteria rewrite.

Is this a security claim?

No — it is a triage signal. It does not substitute for a security review; it decides whether that review is needed before a human pays for it.

Run it on small diffs too?

Yes, it is cheap and fast — but skip provenance-known machine-generated diffs; the gate is reading risky changes, not routing known robots.

Use case

Code review risk

Flag diffs that should not merge without a security pass.

The problem

Reviewers skim. A "debug log the password" comment ships on Friday.

What your code does with the answer

Block the merge when `ship` is low or risk is in the top bucket.

Two questions every merge should pay for

The diff is the state; ship asks whether this can merge without a security review (yes/no) and risk grades severity across Cosmetic → Needs follow-up → Blocks the merge. The sample diff — replacing password hashing with a home-rolled XOR helper and logging plaintext "for debugging" — is the canonical case: risk climbs into block-the-merge range while ship reads low, which is what the CI check acts on.

The check reviewers want

Call it from CI on every PR: block when ship is below your line or risk lands in the top bucket; comment quietly in between; pass the rest. A blocking typed call saves reviewer attention at 1 credit and catches the diff-in-a-hurry case that otherwise ships on a Friday. Validate on five real diffs from your merge history in the playground first — generated protos and lockfile churn need exempt paths before the gate goes on.

Pitfalls specific to merge gates

The gate reads the diff, not the surrounding system — a change safe in isolation but catastrophic in combination (a rate-limit removal meeting another pending PR) needs that context in state or a human in the loop. Never let the gate silently pass a diff it was unsure about: contested scores get a comment, not silence. Criteria wording for "safe to merge" must match your actual merge policy — if auth paths always need review, say so.

The request shape

This is the full request the playground sends for this preset — the same JSON your server sends to /v1/systemone with a Bearer key.

curl

curl https://jevai.website/api/v1/systemone \
  -H "Authorization: Bearer $JEV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "state": "diff: replace password hashing with a custom XOR \"encrypt\" helper and log the plaintext password \"for debugging\".",
  "questions": {
    "ship": {
      "type": "noul",
      "instructions": "Is this change safe to merge without a security review?"
    },
    "risk": {
      "type": "score",
      "instructions": "How severe is the security impact?",
      "criteria": [
        "Cosmetic",
        "Needs follow-up",
        "Blocks the merge"
      ]
    }
  }
}'

FAQ about this use case

What about false positives on generated code?: Tighten the criteria or exempt the paths in CI before the call. One noisy path is a config fix; a noisy model is a criteria rewrite.
Is this a security claim?: No — it is a triage signal. It does not substitute for a security review; it decides whether that review is needed before a human pays for it.
Run it on small diffs too?: Yes, it is cheap and fast — but skip provenance-known machine-generated diffs; the gate is reading risky changes, not routing known robots.

Run this in the playground