Six concrete workloads that map cleanly onto the System One shape — text in, one decision out — each one compared against the LLM baseline teams run today. Claims labeled: vendor claim / observed / analysis.
Every good fit has the same skeleton: unstructured text arrives → the right answer is one of N options your team could name in advance → software acts immediately on the answer. High volume, tight latency budget, and a real cost per decision. If a wrong-but-confident answer is expensive and a calibrated confidence number would change what your code does, you're looking at a System One workload analysis. The option lists below match the presets in our schema generator, so each scenario is one click from a working contract observed.
The job: a customer message lands — "my card was charged twice for order #8841" — and must reach billing, tech support, refunds, or a human now, because routing delay is the top complaint driver in support ops analysis.
LLM baseline: a function-calling or JSON-mode prompt that writes a routing label as text, at generation latency and cost, with occasional invented labels your switchboard doesn't recognize.
System One shape: options like billing / tech_issue / refund_request / escalate / other; one single-pass call per ticket, probabilities you can threshold on (low-confidence tickets go to humans automatically). Default preset exists in the generator observed.
The job: every user-generated comment, post, or review must be labeled — safe, spam, harassment, self-harm, worse — before it ships, at whatever volume your platform does analysis.
LLM baseline: JSON-mode classification prompts at scale; cost scales linearly with volume, and a hallucinated label category silently breaks your enforcement dashboards.
System One shape: a fixed label set, a probability per label, and calibrated numbers you can route on — auto-action above 0.95, human review in the middle band. Moderation is the canonical "closed set at volume" workload, which is why TypeSafe's launch material leads with decision tasks like it vendor claim analysis.
The job: pull structured fields out of messy text — "book a table for 4 this Friday, outdoor if possible" → party_size=4, seating=outdoor observed (example from this site's generator presets).
LLM baseline: JSON mode is genuinely good here, and this is the workload where it's hardest to beat — multiple fields in one call. The honest caveat: each field is still model-written text.
System One shape: one call per choice-field, each returning calibrated confidence — party_size ∈ {2,4,6,8}, seating ∈ {indoor, outdoor, either}. More calls, but each one gets a trust number your booking code can act on; low-confidence fields fall through to a form instead of a wrong reservation analysis.
The job: a new signup shows a 2-hour-old email, VPN IP, $1,990 first order. Decide: low_risk / review / high_risk / block — before you ship the goods observed (preset example).
LLM baseline: a JSON-mode prompt over the event features; every millisecond of latency sits inside the checkout path where conversion bleeds.
System One shape: single-pass banding with calibrated probabilities tuned so your chargeback tolerance maps directly onto thresholds. Fraud is asymmetric-cost: a calibrated 0.6 is actionable in a way that a fluent "risk_level": "low" is not analysis.
The job: your monitoring fires hundreds of alerts a day; most are noise, some are 3 a.m. page-worthy. Somebody — or something — has to sort signal from noise every time analysis.
LLM baseline: summarization-plus-JSON prompts that classify severity as text; helpful, but each classification costs generation latency while the incident clock runs.
System One shape: options like page_now / ticket / batch_digest / ignore, fed the alert payload as state, single pass, with probabilities your escalation policy reads directly. Faster triage of the same alert stream is exactly the hot-loop shape the ~100× claim addresses vendor claim analysis.
The job: per-user, per-impression decisions — which of 4 headline variants, which offer, which onboarding path — made millions of times a day analysis.
LLM baseline: rarely attempted at this volume because generation cost per impression is absurd; teams fall back to rules or bandit libraries that can't read the text context.
System One shape: variants as the option list, user context as the state, one cheap calibrated call per impression — contextual selection with a language-understanding front end at per-decision economics that only make sense if the ~100× efficiency claim survives contact with real pricing vendor claim analysis.
| Use case | Option set (typical) | Why it fits the System One shape |
|---|---|---|
| Ticket routing | billing / tech / refund / escalate / other | Closed set, latency-sensitive, volume-priced analysis |
| Moderation | safe / spam / harassment / self_harm / illegal | Closed set, huge volume, confidence-routed enforcement analysis |
| Field extraction | one choice-field per call | Calibration beats silent wrong values analysis |
| Risk banding | low / review / high / block | Asymmetric cost; threshold = policy analysis |
| Alert triage | page / ticket / digest / ignore | Hot loop inside incident response analysis |
| Variant picking | N campaign variants | Only viable at per-decision micro-cost analysis |
Honesty section. Don't force the shape where it doesn't fit: anything that must produce text (drafts, summaries, code); multi-step planning where each step's arguments are novel; tasks needing an audit trail of reasoning a human can read by design / analysis. Those are LLM workloads, full stop. And note what none of the six use cases above contain: a measured Jev benchmark. None exists publicly as of 2026-09-20 observed — the pattern fits; the economics are still an assumption until TypeSafe publishes pricing observed.
Four of these six scenarios ship as presets with option sets ready to edit.
Decisions/day × your assumed Jev price vs your current LLM bill.
What a System One Model is, and how it differs from function calling and JSON mode.