JEV - Are yes-no, choice, and score enough of a language?

Noul, Choice, and Score are a language for code. This piece uses an expense report to show how the three questions split apart, and when the language is not enough.

Folkbench folkbench.com

Co-author: folkbench.com (Folkbench is a reviewable evaluation and selection platform for AI APIs, model services, and related sites. It draws on published service information, prices, availability, latency, and evidence windows to help users compare and choose a path.)

Ten pieces in this series:

Whether this language is enough depends on what you want it to say. Three closed questions buy speed, and they buy composability. The cost is that anything which needs to be unfolded, it cannot say. This is a language for code. It is not for a person to read.

The docs and the eval site divide it the same way: Noul, Choice, and Score. There is no fourth kind on the page.

The three kinds in the docs

Noul only asks yes or no. It returns a probability. In the docs that number runs from 0 to 1. Near 1, it is a confident yes. Near 0, it is a confident no. If it stops near 0.5, that only means the two sides are equally possible. It does not mean "a middling degree". The docs name this trap: ask whether someone is strong at Python, and 0.5 is not a middling level. If you actually want to measure level, switch to Score and write what each level looks like. Noul also does not attach a separate confidence. The probability is the signal.

Choice picks one item from a set that has been fixed. What comes back is the chosen item, plus the whole distribution and a confidence. Confidence looks at whether the distribution is sharp. If the probability is spread out, confidence is low, and code knows this question is unsteady. The cardinality cap on this question for Jev is 255. Above that, Jev takes two stages. Two stages means score independently first, then make an explicit choice. It is sometimes a little slower. The slowness is the extra step, not the same narrow question suddenly becoming expensive.

Score is levels on a scale. In use it is an ordered scale of 2 to 10 levels. The docs say at least two levels, and the interface accepts at most ten. A level has to be written as a situation that can be matched. Write only "a bit high" or "all right", and the model has nothing to match. The score can land between two levels. That number is the sum of each level's position multiplied by its probability. A decimal between two levels is normal. It is not a broken calculation. It returns the score, and at the same time the distribution over the levels and a confidence. The same score might be everything pressed onto the middle level, or a split between the two ends. Look only at the score, and you will treat those as the same thing. Read the distribution and the confidence together.

None of the three answers can leave the cells you gave in advance. Questions on the same material are independent of each other. Add one or take one away, and the other questions do not change. If a judgment depends on several things together, ask them separately and leave the weights in code. Later, when you adjust policy, you change these numbers. You do not rewrite a whole prompt.

An expense report, taken apart

The official eval page uses an expense report as a toy. On the left is a paragraph a person wrote, the kind of policy a team would write down. Every report has to carry a receipt. If the receipt cannot be read, ask the employee for another one. Then see whether the spend is a meal, travel, or equipment. If a meal is over $75 and the description does not match the receipt, a manager has to sign. The other reports are treated as approved.

On the right, the same paragraph is split into a flow. Each sentence of policy is one question, or one code rule. Whether the receipt can be read is a yes-no. If it cannot, code asks for a new one, and that step does not ask the model again. Category uses a single choice, and the options are meal, travel, or equipment. Whether the amount is over $75, code compares on its own. Only the half sentence about the description not matching the receipt needs the model to be asked once more. Together with the amount, that decides whether a manager signs. Reports that do not need a manager's signature, code treats as approved. The model does not write a comment here.

The direction on the eval page is one sentence: structure is always better than one large prompt. Averaged across the four example flows, every model on the workflow has higher accuracy than the whole policy as one prompt, and the spend and the time are lower. The prompt side hands the whole policy over and lets the model walk the logic inside one answer. The workflow side gives code whatever can be written as a rule, and leaves only the narrow judgments as questions.

The steadiest real flow is usually not one large question. It is many narrow questions, independent of each other. Behavior depends on probability, not only on one discrete label. The category can look settled while the other options still hold a share of the probability. Code can take one more step at the threshold you wrote, without throwing the distribution away. Outside the flow, it is still one branch. The layer in the middle is domain engineering. Which question is unused this time, and which number counts as crossing the line, has to be written down for this business, and run the same way every time. Once the answers to the narrow questions are in code, the weights and thresholds are set in this layer.

After string generation is given up

Jev gives up string generation and takes parallel sampling in exchange. The questions in one request are computed together. Every output comes out at once. Not token by token. A chat model has to grow one token after another, each one looking at the one before. There is no letter-by-letter step here. Add a few ordinary narrow questions, and the time barely rises with them. The extra cost is mainly the question's own tokens.

The official price is not the chat interface's price. Input is $0.042 per million tokens. Output is FREE. Without a long run of generated words billed by token, output is not charged. Latency lands at 70–500 milliseconds. That range is for a call chain, not for waiting inside a chat box.

The return value goes straight to code. Noul's probability can enter an if. Routing uses Choice's label. A scoring threshold uses Score's position. No parsing first. If a chat model hands back a piece of Markdown, you have to split the words first, and one extra sentence can bend the format so the rest cannot connect. The three questions do not hand that text back, because Jev does not generate it.

Explaining why this report was rejected does not fit in the three questions, and neither do an apology and a negotiation. A reason written for a person to read is not in the return value either. Those go to a model that can speak. Jev stops at the judgment.

When it is not enough, the cases are concrete. If the options are names in an open world, company names and product names keep appearing, and the set cannot be fixed in advance. 255 is a cardinality cap, not an infinite list. When a reason must quote a sentence from the source, there is no such sentence to hand over. When a user is waiting for a human sentence, the interface wants readable words. Forcing Jev on then is treating a joint as a mouth.

When policy can be closed into yes-no, single choice, and levels, what follows is a branch, and the judgment is assembled back into the same code. If what you want is speed, and this kind of composability, it is enough. What needs to be unfolded, it cannot say. Speed and composability are what that exchange buys.

Sources

Series