# Primitives

Three question types, one request. Each is evaluated on its own against the same state.

| Type | Use when | Answer |
|---|---|---|
| Choice | the answer is one of a set of unordered options | `choice`, `probabilities` per option summing to 1, `confidence` |
| Score | the answer is a position on ordered levels | `score` (probability-weighted level), `probabilities` per level, `legend`, `confidence` |
| Noul | the answer is yes or no | `noul`, the probability of yes, and `confidence` |

## Choosing

- Categories without order: Choice. Add an `other` option when the set may not cover everything.
- A spectrum: Score. Describe each level as a situation, not a degree word.
- A statement: Noul. Phrase it so that yes is the interesting case.

## Atomic questions, composed in code

Ask one specific thing per question. If a judgment needs several factors, ask each as its own question and combine the answers in code with weights you control. "Is this pitch good?" becomes market size, technical feasibility and differentiation, each a Score, combined by your formula. When priorities change, change a coefficient, not a prompt.

## Structure

`instructions` and `criteria` accept JSON, not only strings: an option can be `{"what": ..., "not_for": ..., "examples": [...]}`, a level `{"summary": ..., "signals": [...]}`, a noul's criteria `{"true": ..., "false": ...}`. Jers was trained on text, so structure helps when it makes the boundary clearer and hurts when it adds noise; test on your data.

## Several questions at once

All questions in a request run in one engine pass on the same state (two passes when a choice has more than 20 options, one per window with `windows`). A request may need at most 400 engine questions. Measured on the hosted GPU: a three-question request takes 27 ms of engine time (median of 25, 2026-09-24). You pay per input token the engine reads, so each question adds the tokens of one more read of the state.