Atomic questions, composed in code
An atomic question is one snap judgment: a gut-check a knowledgeable person could make in a few seconds given the right state. TypeSafe’s introduction is the design rule in one sentence — each question should ask one specific, well-scoped thing. Jev (TypeSafe’s first public System One model) then returns a typed answer you compose in your code.
This page is for builders who already heard of Jev / System One and keep stuffing multi-factor analysis into a single instructions string. jev.pro is an independent unofficial field guide — not affiliated with TypeSafe AI. Confirm the build loop on docs.typesafe.ai. We do not sell or issue API keys.
Definition: one judgment, many questions per POST
“Does this message convey urgency?” is in-bounds. “Analyze this message and determine the best course of action” is not. The second needs slow reasoning and several independent factors. Split it.
Atomic does not mean “one question per HTTP call.” It means one judgment per question object. Pack many atomic questions into one POST /v1/systemone call. Coding agents default to one question per call. TypeSafe publishes an agent skill that tells agents to batch.
| In-bounds (atomic) | Out of bounds (split this) |
|---|---|
| Does the message request a refund? | Analyze the ticket and decide what to do |
| Is the tone urgent? | Write the reply and pick a priority |
| Does policy language support a refund? | Combine market, feasibility, and differentiation in one Score |
Mental model: decompose, ask in parallel, own the weights
If a judgment weighs market size, technical feasibility, and differentiation, ask those as three Scores (or a mix of Choice / Score / Noul) and combine them in code. When priorities change, you change a coefficient. You do not rewrite a giant prompt and hope the model reweights internally.
Questions in the same request are independent. One answer is not hidden context for another. All questions see the same state and are evaluated in parallel. If a later question truly cannot be built until you have an earlier answer — you need to fetch more data, or the next option list depends on the first Choice — make a second request. Otherwise ask everything together and ignore unused answers.
That independence is the System One loop: Jev supplies snap judgments; code owns control flow. Schema-safe answers still can be wrong. Schema-safe ≠ correct. Your compose step is where policy and arithmetic live.
Speculative questions are cheap (vendor claim)
Docs say adding questions barely changes response time and costs only the extra tokens. Ask the severity question even if you might later learn the ticket is not a bug. That pattern is speculative fan-out: pay a small input-token increment rather than a second round-trip after you learn the first answer.
Treat latency and cost figures as vendor claims unless you measured them. The launch post cites 70ms–500ms and $0.042 per million input tokens with output free. Do not treat those as your p95.
What “atomic” is not
- Not a ChatGPT-style essay inside one question.
- Not a calculator. Keep sums in code;
jev-1.13is weak at numeric precision (jaggedness). - Not one HTTP call per factor. Batch.
- Not a hidden chain: question B does not read question A’s answer in the same request.
If you need a paragraph after the decision, let a generative model write it. Jev does not generate text.
A refund-shaped split
State holds the message, fetched transactions, and extracted clauses. Questions: refund requested (Noul), duplicate-charge evidence (Noul), policy support (Noul or Choice), urgency (Score). Code keeps entitlement and velocity caps deterministic, then routes allow / review / hold. Change a weight without changing the questions.
FAQ
Can one question ask two things if I number them?
No. If you need two judgments, send two question objects. Numbered bullets inside instructions still collapse into one snap — and one typed field.
Do later questions see earlier answers in the same POST?
No. TypeSafe documents independent, parallel evaluation against the same state. Chain only when the next schema depends on a prior answer.
Is “atomic” the same as one request per ticket?
No. One ticket can carry many atomic questions. Atomic is about judgment scope, not HTTP cardinality.
Should I average three Nouls into a priority?
Only as a compose rule you own and validate. Officially, questions are different judgments. Do not treat 0.5 as “medium.”
Disclaimer
This is an independent unofficial site and is not affiliated with TypeSafe AI; official documentation is available at https://docs.typesafe.ai. Never treat jev.pro as TypeSafe official documentation. We do not sell, issue, or proxy API keys.