Two ways to get structure out of AI. One guarantees the shape of the text; the other guarantees the output is a decision. Labels throughout: vendor claim / observed / analysis.
JSON mode (structured output) constrains an LLM to emit syntactically valid JSON matching your schema. It cannot guarantee the JSON is right: the model still writes every field as text, so wrong values, invented enum entries, and confident nonsense all remain possible analysis. Jev's input/output shape removes that failure class by construction — no string is ever written; the output is a probability per option you defined vendor claim. The trade: Jev only answers closed-set questions and returns no prose by design.
JSON mode is constrained decoding: the model still generates token by token, but the sampler only allows tokens that keep the string valid against your schema or grammar. You get well-formed, parseable JSON without babysitting the format observed (public, documented mechanism). It's the workhorse behind most production "LLM extraction" pipelines today.
The guarantee, stated precisely, is syntax: fields present, types correct, enum values from the allowed set if your schema constrains them. What it does not guarantee is semantics — nothing stops the model from emitting "risk_level": "low" for a transaction any human reviewer would flag, or a plausible-but-wrong value in a free-form field analysis.
Jev never enters the text-writing regime. Input: one piece of unstructured text plus your option list. Output: one calibrated probability per option, single pass vendor claim. Because there is no generation step, the failure surface changes qualitatively:
No format errors at all — there is no string to malformed vendor claim.
No invented options — the output space is exactly the option list you supplied vendor claim.
Calibrated confidence — trained with RLCD so probabilities are meant to be trusted as probabilities vendor claim. With JSON mode, a confident wrong answer looks byte-identical to a confident right one analysis.
| LLM + JSON mode | Jev (System One Model) | |
|---|---|---|
| What's guaranteed | Syntactically valid JSON against your schema observed | Output is a distribution over your option list vendor claim |
| What can still go wrong | Right shape, wrong facts; format drift on long outputs; invented values in unconstrained fields analysis | Wrong decision — with a calibrated number telling you how confident it is analysis |
| Output | A JSON string the model wrote | Probabilities, no text observed shape |
| Multi-field extraction | Yes — many fields in one call observed | One decision per call; chains of calls for many fields observed shape |
| Probabilities | None you should trust as truth analysis | Calibrated by training (RLCD) vendor claim |
| Latency & cost | Autoregressive; scales with output tokens observed | Single pass; claimed ~100× vs LLMs on decision tasks vendor claim |
| Best at | Extracting rich structured fields from messy text analysis | High-volume closed-set decisions analysis |
The dangerous bug is not malformed JSON — validators catch that. It's the valid JSON that's wrong: shape-perfect output that your downstream code consumes without question, because nothing in the pipeline was ever asked "how sure are you?" in a way you could act on analysis. Teams end up building homegrown confidence layers — sampling the same call N times, self-critique passes — each one adding latency and cost that erode the point of the pipeline.
That's the gap a calibrated decision model aims at: confidence arrives as a first-class number, and your threshold policy becomes explicit instead of emergent analysis (calibration itself remains a vendor claim until independently replicated).
Stay with JSON mode when the job is free-form extraction with many fields, nested structure, or long inputs — summaries with typed fields, document-to-record pipelines. The LLM's generation ability is the feature there; constraining its format is all you need analysis.
Reach for the System One shape when the job is one decision, from a known option set, at high volume — routing, moderation labels, risk bands, triage. There, generation is overhead and calibration is the product analysis. Most real systems will run both, side by side analysis.
Build the text + options contract a System One call expects, with curl/JS/Python snippets.