---
title: "Decision models explained: Jev, Clef, and OpenAI"
description: "A beginner's guide to decision models: what they return, how they differ from a text-generating LLM, and where Jev, Clef, and OpenAI's Decisions API fit."
date: 2026-10-13
updatedDate: 2026-10-13
location: San Francisco, CA – October 13, 2026
image: /images/decision-models-explained-jev-clef-hero.jpg
keywords: "decision models explained, Jev, Cloudflare Clef, OpenAI Decisions API, decision models vs LLMs"
tags: ["decision-models", "ai-engineering"]
faq:
  - question: "Can a decision model write an explanation?"
    answer: "Jev and Clef's decision interfaces return choices and scores rather than new prose. OpenAI's Decisions API also returns bounded answers. Use a text-generating model when the application needs a written explanation."
  - question: "Do I need training data to try a decision model?"
    answer: "You can define questions and allowed answers without training a new model. You still need examples with known outcomes to check accuracy and decide which results can be used automatically."
  - question: "Can a decision model take actions by itself?"
    answer: "A decision model returns a judgment. Your application decides whether to use it, checks permissions, and executes any action. Selecting a refund label does not authorize a refund."
---

A **decision model** helps software choose among answers you define. Give it a message, a question, and the allowed options, and it returns a judgment with probabilities. A text-generating large language model, or LLM, can compose a new reply. A decision model can help decide where that message should go first.

TypeSafe's Jev, Cloudflare's Clef, and OpenAI's Decisions API all support this kind of bounded judgment. An application can use them to select a support queue, identify an issue, or rate its severity. A generative model can handle the writing that follows.

## One message, two different jobs

Suppose a customer writes: "I was charged twice for the same order." A support system has two jobs. It needs to send the ticket to the right team, and someone needs to write a useful response. Those jobs require different outputs.

A generative LLM could write: "I can help you check that charge." A decision model could answer the question "Which team should handle this?" with `billing`, selected from `billing`, `technical`, and `review`.

The application can inspect that answer directly. It might route the ticket to billing, or send it for review when the result is uncertain. A person or another model can then write the response. The decision model handles one focused judgment inside a larger process. [TypeSafe's System One introduction](https://docs.typesafe.ai/concepts/system-one) describes this separation.

The diagram compares both models on the same routing question. The text model generates a JSON answer; the decision model scores the three allowed options.

<iframe data-simple-decision-diagram src="/illustrations/decision-models-simple/index.html" title="Animated diagram of the same message and system prompt passed to text generation and decision inference" width="100%" height="1200" loading="lazy" style="display:block;border:0;width:100%;"></iframe>
<script src="/illustrations/decision-models-simple/embed.js" defer></script>

## What can you ask a decision model?

Decision interfaces generally support three kinds of questions: choose an option, estimate whether something is true, or give a score. You supply the evidence and define what the answers mean. The same customer message can support several separate judgments.

| Kind of question | Example | What comes back |
| --- | --- | --- |
| Choose one option | Which team should respond first? | A selected team and probabilities across the options |
| Yes or no | Does this message request a refund? | A probability that the answer is yes |
| Give a score | How severe is this issue, using a defined scale? | A rating based on the levels you supplied |

TypeSafe calls these [Choice](https://docs.typesafe.ai/primitives/choice), [Noul](https://docs.typesafe.ai/primitives/noul), and [Score](https://docs.typesafe.ai/primitives/score). OpenAI uses choice, predicate, and score. A predicate is a yes/no question.

The wording matters. "Which team should respond first?" asks for one team. "Does this mention a billing problem?" and "Does this mention a technical problem?" are separate questions that can both receive a yes. If a ticket describes two problems, forcing them into one category can lose useful information.

## How is this different from asking an LLM for JSON?

An LLM can also return a category inside JSON, a data format software can read. With [Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs), supported schemas can restrict the answer to allowed values. That makes an LLM a valid alternative for many classification tasks.

The difference is how a dedicated decision model produces its answer. A conventional LLM generates text in sequence, using small pieces called tokens. That remains text generation even when the output is just `{"team":"billing"}`.

Cloudflare's Clef instead reads the input and scores the allowed answers directly, without writing the answer token by token. Cloudflare describes this approach in its [Clef announcement](https://blog.cloudflare.com/clef-decision-models/). Clef still uses an LLM as the foundation for understanding the input.

OpenAI documents the Decisions API's inputs and outputs without establishing that it uses Clef's internal design. A similar interface does not prove an identical architecture.

Both approaches can return a valid category and still choose the wrong one. A valid category still needs to match the customer's problem.

## Where do Jev, Clef, and OpenAI fit?

These products provide focused judgments that software can inspect. Jev is TypeSafe's decision model. Clef is Cloudflare's downloadable model family, also available through Workers AI. OpenAI offers a Decisions API for bounded questions. Choosing between them requires testing on the actual task.

| Product | What to know first |
| --- | --- |
| **TypeSafe Jev** | Built around typed questions over text and structured data. Its training targets useful, calibrated probabilities. |
| **Cloudflare Clef and Clef-flash** | Available as downloadable weights and a hosted service. Their published design scores answers using a language-model backbone. |
| **OpenAI Decisions API** | A hosted interface for choices, yes/no judgments, and scores. Currently in public beta using `gpt-6-luna`. |

Sources: [TypeSafe](https://docs.typesafe.ai/concepts/system-one), [Cloudflare](https://blog.cloudflare.com/clef-decision-models/), and [OpenAI](https://developers.openai.com/api/docs/guides/decisions).

Their response formats and supported inputs differ. OpenAI can also return a refusal, which the application must handle. Moving from one provider to another means checking both the integration and the quality of its answers.

## What do the probabilities tell you?

A probability expresses the model's estimate for an answer under the question you asked. It gives your application more information than a winning label alone. The numbers still need testing before you use them to decide which cases can skip human review.

Imagine these results for our ticket:

| Allowed answer | Illustrative probability |
| --- | --- |
| Billing | 92% |
| Technical | 5% |
| Review | 3% |

Billing is the clear winner. For a mixed message about a charge and a broken dashboard, billing might receive 52% and technical 43%. Billing still wins, but the close result gives the application a reason to request review.

**Calibration** means checking whether probabilities match outcomes across many examples. Among comparable predictions around 90%, a well-calibrated model should be correct about 90% of the time. One answer marked 90% can still be wrong.

A field called "confidence" may summarize how concentrated the probabilities are. It does not automatically mean a measured success rate. [TypeSafe's confidence guide](https://docs.typesafe.ai/confidence) explains that distinction.

## When are decision models useful?

Decision models are useful when the task requires interpreting meaning and the possible answers are already known. Examples include routing messages, selecting relevant documents, and rating an item against a rubric. They can work alongside a generative model that handles writing or investigation.

Avoiding a generated response can reduce work for the model. Whether that improves speed or cost depends on the whole application, including network delays, input size, and fallback calls. Compare a decision model with an LLM asked for the same short answer, rather than an unnecessarily long explanation.

They also have limits. A decision model can misread the message, choose a wrong allowed option, or be overly certain. Independent [Red Hat guardrail tests](https://developers.redhat.com/articles/2026/10/02/benchmarking-ai-decision-models-against-traditional-guardrails) found Jev strongest on one task while alternatives beat it on another. Those tests did not compare all three products.

Use ordinary code for exact calculations and permission checks. Use a generative model when the task needs a new reply, code, or an explanation. To try a decision model, start with one small judgment, collect examples with known answers, and measure its mistakes alongside the amount of work it saves.

## Frequently asked questions

#### Can a decision model write an explanation?

Jev and Clef's decision interfaces return choices and scores rather than new prose. OpenAI's Decisions API also returns bounded answers. Use a text-generating model when the application needs a written explanation.

#### Do I need training data to try a decision model?

You can define questions and allowed answers without training a new model. You still need examples with known outcomes to check accuracy and decide which results can be used automatically.

#### Can a decision model take actions by itself?

A decision model returns a judgment. Your application decides whether to use it, checks permissions, and executes any action. Selecting a refund label does not authorize a refund.