Noul, Choice and Score: The Three Questions Jev Can Answer

There is one question in our Jev Lab quiz that splits every group we try it on. "How likely is this lead to buy this quarter?"

Half the room says it is a yes/no question. The lead buys or does not. The other half says it is a rating, because "likely" has degrees. Both halves have a point, and the argument that follows teaches more than the answer does.

Jev only understands three shapes of question. Picking the right shape is the first skill of building with it, and it turns out to be most of the skill.

Why does Jev only have three kinds of question?

Because almost every judgement a business makes about a piece of text reduces to one of three things. Does something hold? Which of these is it? How much of something is there?

Bigger decisions are built by asking several of these at once and combining the answers in code. "Should this customer go to the manager?" is really "are they angry?", "is there a deadline?" and "is money involved?", joined by a rule someone in the business agreed. Three small shapes, combined, cover a remarkable amount of ground. In our lab, three yes/no questions and three rules were enough to sort six customer messages into the right queue, six out of six.

What is a Noul, and what is it enough for?

A Noul is TypeSafe's name for a yes/no question. You get back one number between 0 and 1: the probability that the answer is yes. There is no separate confidence value, because the number already says it all. Near 1 is a clear yes, near 0 a clear no, and near 0.5 means the model weighs both about the same.

TypeSafe's documentation has a tidy example. Asked "Is the customer asking for a human agent?" about "I have asked three times now. Can I please just talk to a real person?", Jev returned 0.99. About "Thanks, that fixed it!" it returned 0.02.

Each Noul can carry criteria: a line saying what counts as yes and a line saying what counts as no. They matter more than people expect. "Yes: mentions a prior attempt, ticket, or that they have asked before" is far clearer than "is this a repeat contact?" on its own.

A Noul is enough for flags, filters and checklists: is this spam, is there a deadline, does this CV mention a licence, does the reply promise a refund we cannot give. One condition per Noul, as many Nouls as you like in one call.

One warning from our own testing. Nouls read your words literally. Asking "is this message not a question?" is harder for the model than asking "is this a question?" and flipping the answer in code. And one word can move everything: the same message scored 28% when we asked whether the sender explicitly asked for their money back, 77% without "explicitly", and 94% when we asked whether they want it back. None of those numbers is wrong. They answer three different questions.

What is a Choice, and what is it enough for?

A Choice picks one option from a list you define, up to 255 options in a single question. You get back the winning option, a probability for every option (they add up to 1), and a confidence number that says how concentrated those probabilities are.

Confidence is easy to misread, so it is worth one example. With three options at 90%, 6% and 4%, TypeSafe's formula gives a confidence of 0.60. With an even three-way split it gives 0. It measures how peaked the answer is, not whether it is right. A model can be very concentrated and still wrong, which is why you still test on your own data.

Two habits make Choices work. Always include an "other" or "none of the above" option when your list might be incomplete, or the model will be forced into a bad fit. And when two options are easy to confuse, describe each one properly, even with a note on what it is not for.

A Choice is enough for routing and sorting: which team, which product line, which language, which intent, which stage of the sales funnel. The rule of thumb is that exactly one answer must be true. If two things can be true at once, such as a customer who wants to cancel and get a refund, a Choice cannot say "both". Ask two Nouls instead.

What is a Score, and what is it enough for?

A Score places the answer on a ladder of levels you describe in words, up to ten of them. You get back a single number, the probability-weighted position on the ladder, plus the probability of each level and a confidence value.

TypeSafe's example is a bug report: "The export button crashes the settings page in Safari. It works in Chrome, but a few of our customers only use Safari." With three levels, cosmetic, broken with a workaround, and blocking with no workaround, Jev put 57% on the middle level and 43% on the top one. The score came out at 1.43. That is the honest answer: for most customers there is a workaround, for the Safari-only ones there is not.

The most important rule is that each level is judged on its own. The model never sees the level next to it. So "Low", "Medium" and "High" are nearly useless: they describe nothing. "Cosmetic; no impact on functionality" describes a situation the model can recognise. In Jev Lab we run the same bug report with vague levels and with concrete ones, side by side, and the difference is visible in a second.

A Score is enough for anything with degrees: severity, urgency, frustration, fit with your ideal customer, quality of a draft, risk. It gives you a number you can hold against a threshold, and move later.

How do we choose between Noul, Choice and Score?

And the lead that splits every room? We call it a Score, because "likely to buy" has rungs you can describe: no budget mentioned, exploring options, comparing vendors, asked for a contract. A ladder gives you something to threshold on and something to argue about in a sales meeting. But the argument is the point: the shape you pick is a design decision, and it should be made on purpose.

What mistakes do people make with the three shapes?

The first is asking one big question when you mean four small ones. "Is this a good customer?" hides spend, loyalty, risk of leaving and whether they want a call. Ask the four and let code decide what "good" means this quarter. We show this side by side in How Jev Works.

The second is vague levels and options, which we covered above. The third is using a Choice when the answers are not exclusive. The fourth is asking Jev to do what it is weak at: counting items, comparing dates, or anything that needs several hops of reasoning. Those belong in code, around the question.

The fifth is forgetting that the model answers exactly what you wrote. Before trusting a question, run it on ten real examples and read the numbers. The Build mode in Jev Lab does exactly that: paste your messages, tick the questions, and get a table with every uncertain answer highlighted.

Where can we practise all three?

Jev Lab walks through the three shapes in its third stage with a six-task quiz, then has you build questions with a simple form: pick the shape, write the question in plain words, say what each answer means. No JSON, no code. Its final stage is a six-message triage you have to get fully right, with hints if you get stuck.

If the idea of a program asking a model a question is new to you, API Lab is a gentle first step: it teaches what an API call is on our live jobs feed. And if you want to see the three shapes inside a larger workflow, Automation Lab lets you build one on a canvas.

Frequently asked questions