Decision model

Put a typed decision in the middle of your workflow.

Use this model when your application has context and needs a clear, machine-readable signal before it routes, evaluates, or acts.

Use the exact model ID shown in this page. Credits follow the same Jev rule as the other decision models.

A decision boundary

jaredpalmer/kev-4b

State in. Structured signal out.

State

A workflow has enough context to choose a safe next step.

Choice

Route to the approved path

Score

0.84 confidence

Noul

Escalate if evidence is incomplete

Keep permissions, side effects, and final actions in your application.

Input

State + typed questions

Output

Choice · score · noul

Billing

Same as Jev

Endpoint

POST /v1/systemone

Why this model

A small decision surface for production workflows.

Keep the model focused on one bounded judgment and let your application own everything that happens after it.

Typed output

Use choice, score, or noul results directly in branches, thresholds, and review gates.

Inspectable state

Record the state, question, answer, and confidence together for debugging and evaluation.

Controlled action

Treat the model as a signal; keep tools, permissions, writes, and side effects in code.

Where it fits

Use it between context and action.

Start with a decision that has a small set of valid outcomes and an explicit fallback.

Routing

Choose a team, queue, or next step

Return an approved route

Evaluation

Score quality or readiness

Gate the next workflow

Safety boundary

Detect uncertainty or risk

Escalate before side effects

Call the model

Use the shared Jev API shape.

Set the model ID shown on this page and keep the rest of the System One request unchanged.

  • Set model to the exact model ID shown below.
  • Send the current state as a compact string or JSON-serializable value.
  • Ask one or more typed questions and handle the returned answer in application code.
The model ID is shown in the example request and Playground selector.
Put business context in state and the decision contract in questions.
Validate confidence and fallback conditions before taking an irreversible action.
Example request
curl -X POST https://thejevai.com/v1/systemone \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jaredpalmer/kev-4b",
    "state": "A customer request needs a safe next step.",
    "questions": {
      "route": {
        "type": "choice",
        "instructions": "Choose the correct next step.",
        "criteria": {
          "continue": "Continue the approved workflow",
          "review": "Send the case for human review"
        }
      }
    }
  }'

Keep the API key on your server. The Playground uses the same request shape through your signed-in session.

Build with it

Make the next step explicit.

A typed signal is easiest to operate when the owner, allowed outcomes, and fallback are already clear.

Support triage

Route a case while keeping the customer-facing action under application control.

Agent guardrail

Check a requested tool path before permissions and side effects are applied.

Quality gate

Turn a rubric into a score or noul signal for review and regression workflows.

FAQ

Keep the integration bounded.

How do I select this model?

Set model to the exact ID shown on this page in the POST /v1/systemone request, or choose it in the Playground.

Does it use the Jev billing rule?

Yes. Supported decision models use the same Jev-based credit rule. Validate quality, latency, and availability with your own cases.

Can it execute actions directly?

No. Use the response as a typed recommendation and keep tools, permissions, writes, and human review in your application.

References

Keep every layer visible.

OpenRouter model page

Check current availability and provider-specific details before production use.

Jev API documentation

Follow the shared request, response, authentication, and error contract.

Your evaluation set

Measure route accuracy, confidence, latency, and review rate with representative cases.

View model on OpenRouter

Start with a bounded question

Give your workflow a decision boundary.

Try the model in the Playground, then move the same request to your server when the output is stable.