Decision models, in practice
A little judgment
goes a long way.
Which queue? How urgent? Is something missing? Learn how small AI judgments become useful decisions in your software, across hosted and open models.
Updated for Jev 1.14 · What changed · Try photo intake
Give the fuzzy part
a clear place to go.
Code can look up a booking or check opening hours. Understanding “my wheel catches when I pedal” takes a different kind of judgment.
A System One model reads the evidence and answers questions using options you define. You get a typed value and probabilities. Your code decides what happens next.
Meet the programming model →Run the repair desk.
Choose a customer message. See the three judgments it produces, then move the threshold to change where the request goes.
A customer writes
What does the message tell us?
on our 0–3 rubric
Where does it go?
This slider changes a demo rule. It does not change the model’s answers.
See the questions and routing rule
Three focused questions
- Choice: Which workshop queue best fits the request: repair, fitting, accessories, or unclear?
- Score: Does the message describe no disruption, inconvenience, a limited ride, or an unusable bike?
- Noul: Does the customer ask for a loan bike while theirs is in the shop?
const winner = answer.choice;
const p = answer.probabilities[winner];
if (winner === "unclear" || p < threshold) {
askForDetails();
} else {
suggestQueue(winner);
}All answers here are hand-authored examples. A real application needs labelled tests before using a probability threshold.
Three ways to ask.
Pick the answer shape that matches the decision.
Which one fits?
A category from a set you define, with probabilities for every alternative.
ScoreWhere on the scale?
A weighted position on ordered levels you describe, such as the impact of a bike problem.
NoulDoes this hold?
The probability of yes for a claim, such as whether a customer requested a loan bike.
One pattern. Several ways to run it.
Use Jev through TypeSafe, Clef through Cloudflare Workers AI or its open weights, Kev on your own hardware, or Laya’s smaller multilingual encoders. Start with the evidence your feature needs and the operational tradeoffs you can support.
Compare models and providers →An answer isn’t
an action.
In the repair desk, raising the threshold sends the same answer to review. The model’s judgment stays the same; your application’s rule changes.
That separation matters. You can adjust routing, add a human check, or change a product rule without pretending the underlying answer has become more certain.
Learn to use uncertainty →The evidence, question, and answer boundaries form a decision frame. Learn to change each part deliberately, then explore what we learned from Jev experiments.
What would you like to figure out?
Read in order, or follow the question you came with.