Few-shot examples¶
Independent implementation of the documented System One wire format — not affiliated with TypeSafe.
A few-shot example is rendered as a chat turn pair: a user turn holding the example state plus the same
question block the real call uses, then an assistant turn holding the answer in the format the active method
expects. Because the demonstration goes through the same renderers as the real call, the model sees exactly the
answer shape it is being asked for — a label for logprobs/grammar, a JSON object for
structured/discrete.
Example(state="Charged twice for one order", answer="billing")
Example(state="Login fails after reset", answer="technical", probabilities={"billing": 0.05, "technical": 0.9})
answer accepts a label ("B", case-insensitive over ASCII — a is label A, while ı and ſ are letters
of their own and are not labels; two letters such as "AB" past 26 options), a Choice criteria key, a Score
level index, or a bool for Noul. An exact criteria key wins over a label spelled the same way, so
answer="a" with criteria {"b": ..., "a": ...} demonstrates the option keyed a rather than the first
label, and a non-ASCII key is matched exactly rather than case-folded. probabilities is rendered only by method="structured" — no other answer shape carries a
distribution — but it is validated for every method, before any provider call: the keys must be exactly the
question's, every weight must be non-negative, and a Noul weight must be within [0, 1].
Where examples come from¶
flowchart TD
A["question.examples"] -->|"non-empty"| U["use them"]
A -->|"empty"| B["system_one(examples=...)"]
B -->|"mapping entry for this question id, or the bare sequence"| U
B -->|"empty"| C["SystemOneClient(examples=...)"]
C -->|"mapping entry, or the bare sequence"| U
C -->|"empty"| D["no examples for this question"]
The first level that yields anything wins; the levels do not merge. A mapping is keyed by question id, so
{"intent": [...]} applies to the intent question only; a bare sequence applies to every question in the
call. This makes it easy to keep a house style on the client and override it for one call or one question.
Examples are resolved and validated per question inside system_one, after the question is known, so an
answer that matches no option fails before any request:
InvalidQuestionError: question 'intent': example 1: answer 'nope' does not match any option of this question
Rendering¶
For each example, in order:
| Turn | Content |
|---|---|
user |
render_question_turn(example.state, question, labels) — the question block, then the example state's message contents joined with "\n\n" |
assistant |
the expected answer (see below) |
The full message list for a call is therefore
[system] + example turns + [question block] + state turns. The state comes last because it is the part
that changes from call to call: a provider reuses a cached prefix only up to the first token that differs, so
putting the state second — where it used to be — made every call about a new state reprocess the whole prompt.
Measured against ollama, llama.cpp, vLLM and SGLang, moving it to the end takes the reused prefix of a
2400-token prompt from about 40 tokens to 528–1010 (see
local-servers.md). The state is never repeated.
A state that carries its own system or developer turn has that content folded into jevper's system
prompt, in the order given, and the rest of the state goes last as usual. No server here accepts a system
turn that is not first — llama.cpp's template raises System message must be at the beginning. and vLLM and
SGLang answer 400 with the same words — and jevper's own prompt always leads, so the alternative would be to
drop the caller's instruction or fail the call.
Expected answers per method:
| Method | Assistant turn |
|---|---|
logprobs, grammar |
the label, e.g. B |
structured |
{"probabilities": {"billing": 1.0, "technical": 0.0, "sales": 0.0}} — one-hot from answer when Example.probabilities is omitted, otherwise your numbers verbatim |
discrete |
the one-hot shape that method reads: {"choice": "B"}, {"noul": true} or {"score": 0} |
For Noul in structured mode the payload is {"noul": 1.0} (or {"noul": 0.0}); supplying
probabilities={True: 0.9} gives {"noul": 0.9}, and {False: 0.1} gives {"noul": 0.9} as well. In
discrete mode it is {"noul": true} or {"noul": false} — that schema has no room for a weight.
Use explicit probabilities when the demonstration should teach calibration, not just format: a one-hot example teaches the model that answers are certain.
Wire compatibility¶
examples is declared with Field(exclude=True), so it never appears in a dump:
Choice(criteria={"billing": "...", "technical": "..."}, examples=[...]).model_dump()
# {"type": "choice", "instructions": None, "criteria": {"billing": "...", "technical": "..."}}
That keeps model_dump_json() on questions — and on SystemOneResponse — matching the Jev wire shape exactly.
Two-step reasoning¶
Examples are emitted in both passes of mode="two_step": the analysis call and the answer call carry the same
example turns, so the analysis reasons with the same demonstrations in view.