Where Jev breaks

Twenty ordinary words, 10 of them fruit, and nothing borderline. In our recorded run (2026-09-21) it spread its probability across four neighbouring counts — 9 at 0.38, 10 at 0.28, 11 and 12 at about 0.13 each — and picked 9 at confidence 0.34. Whichever it picks, it did not tally anything. It produced the option that looked like the right size of answer, and the error grows with the length of the list.

The docs' own fix: twenty Nouls, one per item, then `sum(noul > 0.5)` in your code. Each question is a judgment the model is good at — "is this word a fruit?" — and the arithmetic never leaves your process. All twenty go in the same request, so this is still one call, same as the broken version.

The 20th of February to the 2nd of March 2026 is exactly 10 days, because 2026 is not a leap year — so "more than 10 days?" is a no. Getting it right means knowing how long February is and counting across the month boundary, which is date arithmetic, and the docs list date arithmetic as unreliable. In our recorded run (2026-09-21) jev-1.13 said yes at 0.94 — confidently wrong. We chose this pair because it fails; other date pairs can come out right, which is the point: a confident number does not tell you whether the date arithmetic behind it held.

Month, day and year for each date, each a Choice over a closed set with `ambiguous` and `none` escapes. Reading "2026-02-20" into its parts is exactly the kind of judgment Jev is good at; the subtraction is then one line of code that knows February 2026 has 28 days.

The same sentence, the same words, two question types. The Noul says 0.22 — a soft no. The Choice puts 0.01 on yes at confidence 0.97 — an emphatic no. The comparable numbers are `noul` and `probabilities.yes`, and they are nowhere near each other. A threshold tuned on one of these does not carry to the other.

Two Nouls that a person would expect to sum to 1: "is this a refund request?" and "is this a request for something other than a refund?". They sum to 1.19. P(noul) and 1 − P(not noul) are separate judgments, not two views of one distribution, so do not derive one from the other — ask the one you actually need and threshold it.

A missing delivery, wrapped in a line that tells the classifier what to answer. On its own — "Where is my order 8812? It never came." — this ticket goes to shipping at 1.0. With the planted line, 0.40 of the probability moved to billing in our recorded run (2026-09-21), and confidence fell to 0.40. Nothing in the question says the state is a customer message rather than a source of instructions, so the text had room to move the answer.

Two changes. Each option now says what it covers and what it is not for, which is the docs' advice: be explicit in the criteria. And a second question asks whether the message contains text addressed to the classifier at all — which is a judgment Jev is good at, and which gives your code something to route on instead of hoping the first answer held.

A misaligned button is as cosmetic as a bug gets, and this scores 0.55 at confidence 0.33 with the probability split 0.45 / 0.55 between levels 0 and 1. The model never sees a level's number or its neighbours — each description is matched against the state on its own — so "1" carries no meaning to match, and the numbers in the instructions do not help either.

Same report, same three levels, described instead of numbered: 0.0 at confidence 1.0. Describe situations, not degrees — "Broken or degraded feature, but workaround exists" gives the model something to match the text against, and "moderately severe" would not.