What is Noul in Jev?

Noul is Jev's primitive for a yes-or-no judgment. You give the model some state and a specific proposition; it returns one number from 0 to 1 representing the probability that the answer is yes.

That makes Noul useful for questions such as:

• Is this customer asking for a refund?
• Does this output contain personal information?
• Should this case be escalated to a human?
• Does this answer satisfy one required policy condition?

The official TypeSafe Noul documentation is the source of truth for the current request and response contract.

What a Noul answer means

A Noul value near 1 is a strong yes, a value near 0 is a strong no, and a value near 0.5 means the model gives yes and no similar probability. It is not a severity score.

For example, a result of 0.82 for “Does this message request a refund?” means the model assigns an 82% probability to yes. It does not mean the refund request is 82% complete or 82% urgent.

Noul has no separate confidence field. Its two-outcome probability already describes the distribution: the probability of no is 1 - noul.

Noul vs. Choice vs. Score

Use the primitive whose answer maps directly to your code:

• Noul: one proposition, yes or no. Example: “Does this require human review?”
• Choice: one option from an unordered set. Example: billing, technical, account, or other.
• Score: a position along defined ordered levels. Example: low, medium, or high urgency.

Do not use Noul as a disguised scale. “Is this customer very frustrated?” depends on an unclear definition of very. If the degree of frustration matters, define ordered levels and use Score.

Request shape

The exact SDK syntax can change, but the underlying request has shared state and one or more typed questions:

{
  "model": "jev-latest",
  "state": "I have asked three times. Please let me speak to a person.",
  "questions": {
    "needs_human": {
      "type": "noul",
      "instructions": "Is the customer asking for a human agent?"
    }
  }
}

The answer is returned under the question ID you chose:

{
  "answers": {
    "needs_human": {
      "type": "noul",
      "noul": 0.99
    }
  }
}

Always copy current field names and endpoint details from TypeSafe or your selected provider before implementation.

Put the threshold in code

Jev supplies a probability; your application supplies the policy. A useful pattern has three outcomes rather than forcing every result into yes or no:

if probability >= 0.85: take the yes path
if probability <= 0.15: take the no path
otherwise: send the case to review

Those numbers are examples, not defaults. Raise the yes threshold when a false positive is expensive. Lower it when missing a true positive is more dangerous. Test several thresholds on labeled examples from the real workflow.

Ask one proposition per Noul

Avoid compound questions such as “Is the customer angry and asking for a refund?” A single number cannot tell you which half caused uncertainty. Ask two Noul questions in the same request and combine the answers in code.

TypeSafe says questions sharing the same state can be evaluated together. That lets you check several independent conditions without hiding application policy inside one broad prompt.

A production checklist

Before a Noul controls a real action:

1. Write a proposition with a clear yes/no boundary.
2. Add true and false criteria when the boundary is easy to confuse.
3. Evaluate clear, negative, and ambiguous examples.
4. Choose thresholds from the cost of each error type.
5. Preserve an explicit review path for the uncertain middle.
6. Log the safe model identifier, request ID, answer, threshold, and resulting action.

Noul is valuable because it exposes uncertainty to ordinary code. It is safest when the code treats that uncertainty as a first-class state rather than rounding every probability into a confident decision.

Next: build your first typed Jev workflow or compare all three primitives in What Is Jev?.