Introduction

Jev is a decision model: it takes application state and one or more typed questions in a single HTTP call, and returns a typed answer with a probability distribution — never prose to parse. POST a state object and a set of questions to one endpoint; get back an answer per question, every time.

A single question against a support message — does this message request a refund? — returns in under 300 milliseconds at a cost measured in thousandths of a cent: a Noul value of 0.99, the model nearly certain the answer is yes.

Everything past that first call is engineering, and it sorts into four classes: how questions are packed into calls, how state is shaped before it reaches the model, where in an agent's decision loop the model's judgment sits relative to the system's authority to act, and how a decision gets recorded well enough to audit later. Each class is one part of this series.

Story shows what makes a Jev answer different from asking a general-purpose model. Technical has the full request and response, and the four problem classes in detail.

Ask a friend for medical advice and you get a paragraph. It might be right. It might hedge in six directions at once. It might change if you ask again tomorrow in a different mood. There's no way to feed that paragraph into a spreadsheet, no consistent scale to compare it against yesterday's paragraph, and no number telling you how sure your friend actually is.

A blood test doesn't work that way. You send a sample. The lab runs a specific panel — is this marker present, how far outside the normal range is that one — and it comes back as numbers on a form: a value, a reference range, sometimes a confidence interval. Nobody expects the lab to write a paragraph about how you're feeling about your health. That isn't its job. Its job is to answer specific, narrow questions about the sample, in a form a doctor, or a piece of software, can act on immediately.

That's the difference between talking to a general-purpose AI model and asking Jev a question. Most AI tools built into a product work like the friend: hand them a situation in words, and they hand back words — an explanation, a recommendation, a few paragraphs of reasoning that read well and are genuinely awkward to act on programmatically. Good software needs the other kind more often than it seems: a specific question with a specific set of possible answers, asked against a specific set of facts, answered with a number.

Jev is built for that second kind of question. Send it a state — the facts of the situation, structured the way you'd structure a lab requisition rather than a coffee-shop conversation — and one or more questions, each narrow enough to have a real answer: is this true or false, which of these options fits best, where does this fall on a described scale. What comes back is never a paragraph. It's a value, and — this is the part a lab report and a Jev answer share exactly — a number describing how sure the model actually is, reported separately rather than folded into the answer where you'd have to guess at it, the same way a lab flags a result as borderline instead of pretending every number is equally solid.

A blood panel doesn't diagnose you on its own, either. It hands a doctor evidence a decision can be built on, and the doctor — or in this case, ordinary code sitting right next to the model — still decides what happens. That division of labor is the whole idea: one system good at narrow, calibrated judgment, and another system, deterministic and reviewable, that holds the actual authority to act on it.

The rest of this series is about what happens once real questions get asked this way inside a real product: how many questions travel in one request, what goes into the sample, where in the system the result gets read, and what gets kept afterward so someone can check, months later, whether the lab was any good.

Every Jev interaction is one HTTP request. The client sends state and a set of typed questions; the service returns a typed answer with a probability distribution per question. There is no chat history, no system prompt to tune, and no free-text output to parse.

Choice, Score, and Noul

Three primitives cover the declared answer shapes:¹

• Choice — exactly one option from a labelled set wins. "Which team should handle this ticket? billing, technical, or account."
• Score — a position on an ordered, described rubric. "How frustrated is this customer? 0 = calm, 1 = frustrated, 2 = very frustrated."
• Noul — a single probability that a stated condition holds. "Does this message request a refund? True or false."

Each returns a probability distribution over its own answer space rather than a bare label, which is what lets a threshold, a confidence floor, or a human-review boundary be built on top of the answer in code, instead of trusting a single value blindly.

A real call, run against hosted Jev

State can be a plain string or a structured object; TypeSafe's own guidance is to use an object "so each part of the state has a descriptive name and its relationships remain clear."² A minimal request, structured that way, against a support-style message:

POST /v1/systemone
{
  "model": "jev-latest",
  "state": {
    "message": "Hi, I was charged twice for the same order last week. Can I get one of the charges refunded?",
    "order_status": "delivered",
    "duplicate_charge_detected": true
  },
  "questions": {
    "wants_refund": {
      "type": "noul",
      "instructions": "This message is requesting a refund."
    }
  }
}

The response, from a call run directly against hosted Jev:³

{
  "model": "typesafe/jev-1.13-20260917",
  "answers": {
    "wants_refund": { "type": "noul", "noul": 0.99 }
  },
  "usage": { "input_tokens": 320, "output_tokens": 20, "cost": 0.0000134 }
}

277.7 ms end to end. A Noul of 0.99 means the model is nearly certain the condition holds — not "yes, at 99% confidence" the way a Choice or Score confidence figure would read, because a Noul reports no separate confidence value by design. The probability is the whole answer.¹

Four problem classes

Nothing about that single call is hard. What gets hard is everything a real integration has to decide around it, and in practice it sorts into four classes:

Class	The question it answers	Covered in
Call shape	Which questions get bundled into one request, and when does a second request actually earn its cost?	Call State Economics
State design	What does a field name claim, and does the evidence behind it actually support that claim?	Evidence Fields
Harness placement	Where does Jev's judgment sit relative to the code that holds real authority to act?	Harness Placement
Decision auditing	What gets recorded about a decision, and can the system's own claims about itself be checked later?	Decision Receipt

Every integration problem encountered while building against Jev in production has fallen into one of those four rows. None of them is about model quality. They're about the surrounding system, which is where an integration actually succeeds or fails.

What would falsify this

The four-class breakdown is a claim about coverage, not a law: it says every real problem encountered so far fits one of the rows above. It would be falsified by a production integration problem that fits none of them — a failure mode that isn't about call shape, state design, harness placement, or auditability. None has turned up yet across the work this series covers, but the set was built inductively from a handful of integrations, not derived from a specification, so it should be read as the current map rather than a closed one.