# 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 this Mac: a three-question request takes 22 to 25 ms of engine time (medians of 20 requests, three runs, 2026-09-23); the cost per answer is the same however many you send.