Does this replace a recruiter?

No — it front-runs the part that scales badly: first-pass must-have coverage. Decisions that cut finalists stay human, and the fit score goes to interview prep, not to a reject pile.

How do we avoid keyword gaming?

The model reads semantics, which cuts both ways: "shipping billing systems" reads stronger than a skills list. State must_have items as capabilities, not tool names alone, and the call rewards substance over padding.

Are résumés sensitive data?

Yes. The gateway forwards the request to the model to compute the answer and does not keep the content — still, get applicant consent in flow and send only what the decision needs.

Use case

Résumé screening

Check must-haves and score overall fit without inventing experience.

The problem

Keyword search rewards padded CVs and punishes career changers.

What your code does with the answer

Reject only when a must-have is clearly missing. Interview the rest.

Must-haves first, fit second

State carries the structured role (must_have and nice_to_have lists) plus the resume text. Two questions: meet_must_have (does the resume cover every must-have) and fit (a score across weak, possible, strong). Splitting matters because they behave differently: must-have coverage is checklist verification — TypeScript, Postgres and API design against five years of Node.js and two billing systems — while fit is a graded judgment your thresholds own.

Interview the humans, not the keywords

Reject only when a must-have is clearly missing (low meet_must_have probability with high confidence). Everyone else goes onward — the career-changer that keyword screens punish is exactly the point of semantic reading. Keep the nice_to_have list in state: the fit score absorbs it, but your bar for "possible" can move as the pipeline fills.

Pitfalls specific to résumé screening

Fairness is a legal surface here: scores route, humans decide, and must-have rejections need to be operational — a missing capability, not a vibe about culture fit. Do not send identity data (names, addresses, dates of birth) into the decision call; it is not needed for must-have coverage. And review criteria quarterly: credentials age, and a must-have that is really a nice-to-have is bias by keyword.

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": {
    "role": {
      "title": "Backend engineer",
      "must_have": [
        "TypeScript",
        "Postgres",
        "API design"
      ],
      "nice_to_have": [
        "Workers",
        "payments"
      ]
    },
    "resume": "5 years Node.js, shipped two billing systems, strong TypeScript and Postgres. No public-cloud certs."
  },
  "questions": {
    "meet_must_have": {
      "type": "noul",
      "instructions": "Does the resume cover every item in `role.must_have`?"
    },
    "fit": {
      "type": "score",
      "instructions": "How strong is this candidate for the role?",
      "criteria": [
        "Weak",
        "Possible",
        "Strong"
      ]
    }
  }
}'

FAQ about this use case

Does this replace a recruiter?: No — it front-runs the part that scales badly: first-pass must-have coverage. Decisions that cut finalists stay human, and the fit score goes to interview prep, not to a reject pile.
How do we avoid keyword gaming?: The model reads semantics, which cuts both ways: "shipping billing systems" reads stronger than a skills list. State must_have items as capabilities, not tool names alone, and the call rewards substance over padding.
Are résumés sensitive data?: Yes. The gateway forwards the request to the model to compute the answer and does not keep the content — still, get applicant consent in flow and send only what the decision needs.

Run this in the playground