Jev, one level down: request shape, confidence, and the jagged edges

A second pass on Jev, this time at the level of the request and the response.

One endpoint: POST https://api.typesafe.ai/v1/systemone with `state`, `model` and a `questions` map. State is a string, JSON object or array, text only. You name each question key, and the key is not sent to the model, so the whole meaning has to live inside the question. Answers come back under the same keys.

The three question types with their real constraints:

- Noul: instructions plus optional criteria for what true and false mean. Returns one float 0-1, the probability of yes. No confidence field.
- Choice: criteria is a map of option to rubric, up to 255 options. Returns the top option, the probability of every option, and confidence.
- Score: criteria is an ordered array of level descriptions, 2 to 10 of them. Returns a probability-weighted value that can land between levels (score 1.05 with 0.95 sitting on level 1), plus a legend, the distribution and confidence.

Confidence is not a second opinion. It is the shape of the distribution collapsed into one number, the normalised peak: (n x peak - 1) / (n - 1). Flat distribution, near zero. That is why nouls don't carry one. The useful part is gating on it by stakes: a higher bar to act unattended on a destructive operation than on a read-only one.

Numbers worth knowing for jev-1.13:

- 64k tokens per request for state plus all questions; 32k for state plus the single longest question
- the state is ingested once and every question is evaluated against it in parallel, which is what makes asking ten questions at once cheap
- input tokens are billed, output tokens are free, $0.042 per million input tokens
- 250k tokens/sec and 1,200 requests/minute, 429 with retry-after, and the docs admit the limits are moving around under load
- trained with RLCD, reinforcement learning for calibrated decisions, a different objective from RLHF or RLVR. No per-account fine-tuning: you shape answers through state and criteria, not weights.

The part of the docs I respect is the jaggedness page for 1.13. It reads instructions literally, negations and scoping words at face value; if you catch yourself explaining what you really meant, that explanation was the missing half of the instruction. It does not count, and arithmetic and date comparison belong in code. It degrades on a large state full of irrelevant detail, and on indirection, where the answer needs two hops between fields. And it does not generate.

The design rule I take from that: give it semantics, keep arithmetic, lookups and control flow in code.

Still reading rather than shipping. If you have run Jev in production, where did you set your confidence thresholds, and did the literal reading bite you first?

Docs: https://docs.typesafe.ai