Decisions, Not Strings: Why TypeSafe's Jev Changes System Architecture

For the last few years, the answer to almost every AI problem has been identical: throw a Large Language Model at it. We use them to write prose, reason through problems and generate code, but we also rely on them to classify support requests, route complex workflows, score search results, and decide whether a background job requires human attention. LLMs are versatile enough to handle all of these tasks, but that flexibility conceals a fundamental architectural flaw. A lot of the time, we are deploying a machine engineered specifically to generate continuous natural language when we do not actually want language at all. We just want a clean, reliable decision.

That is precisely what makes TypeSafe AI's Jev so compelling. Jev is what TypeSafe terms a System One Model. Rather than generating arbitrary text token by token, Jev is built ground-up around structured decisions. You feed it the current state, define the exact set of decisions you want made, and receive typed, probabilistic results back instantly.

---

We Keep Making LLMs Pretend to Be Functions

Consider the common task of routing an incoming web request. When using a conventional LLM, we typically prompt it to analyse the payload and output a structured JSON object containing a target team, an urgency score, and a boolean flag indicating whether review is required. From the application's point of view, this feels structured. However, underneath the hood, we are still relying on a probabilistic text generator producing tokens, essentially pretending to be a function.

To keep this probabilistic process on the rails, we wrapper it in heavy JSON schemas, regex parsers, retry loops, and defensive guardrails. We spend immense engineering effort constraining the very creative flexibility that made the generative model useful in the first place. As I noted in my post on cutting AI costs with smart model routing, using massive frontier models for simple decision nodes is akin to driving a Ferrari to the corner shop.

Jev approaches this from a completely different direction. Its fundamental primitives revolve around Choice, Score, and Noul: choosing between known enumerated options, scoring an input against a bounded scale, or evaluating the probability of a specific state being true. Here is how that distinction looks in application logic:

// Traditional LLM: Forcing structured outputs from text generation
const llmResponse = await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "user", content: "Analyse this request..." }],
  response_format: { type: "json_object" }
});

// Jev / System One Approach: Direct typed decision primitive
const decision = await jev.choose({
  state: incomingPayload,
  options: ["billing_support", "technical_triage", "account_security"],
  context: "Determine the appropriate support queue based on request context."
});

if (decision.choice === "account_security" && decision.confidence > 0.9) {
  await triggerSecurityProtocol(incomingPayload);
}

Instead of asking a generative model to compose a paragraph explaining why something looks urgent, we ask a decision model how urgent it appears to be. Instead of asking it to write out a string describing where something should go, we provide the available destinations and ask it to select one.

---

Judgment Without Giving the Model the System

The architectural pattern enabled by this separation is what I find most exciting. Traditional software architecture gathers state, Jev provides a fast semantic judgment, and standard deterministic code executes the policy and action:

// System Flow Architecture
State -> Jev (Semantic Judgment) -> Policy Engine -> Action

This clean boundary is critical as software systems become more autonomous and agentic. It is alarmingly easy to let an LLM gradually assume total ownership over your entire control flow: reading the state, deciding what action to take, executing tools, inspecting the output, and deciding what happens next. While powerful, this means a non-deterministic generative model begins owning the core logic of your application.

A System One model restores sane boundaries. The AI handles the fuzzy, semantic judgment, while deterministic code maintains control over policy enforcement. If Jev returns a 96% probability that a document requires expedited handling, your TypeScript or Python code decides whether 96% meets the threshold for automated approval, triggers a flag for human review, or drops the task entirely. The AI supplies the judgment; the code owns the policy.

---

The Interesting Part Is the Economics

TypeSafe reports response latencies ranging between 70ms and 500ms, with pricing pegged at roughly $0.042 per million input tokens. Given how new Jev is, these benchmarks should be evaluated critically in your own testing rather than taken as an absolute guarantee. However, as I discussed in AI Engineering Playbook Part 6, model performance and unit economics dictate architecture at scale.

If these economics prove even approximately accurate, they fundamentally alter how we tier our systems. We can stop viewing AI as a single monolithic model positioned at the centre of an app, and instead construct an intelligence ladder:

• Deterministic Code: Handles everything that can be computed or evaluated with certainty.
• Cheap Decision Models (Jev): Handle bounded, semantic evaluation and categorisation.
• Generative LLMs: Handle complex synthesis, long-form writing, and open-ended reasoning.
• Humans: Retain ultimate authority where professional accountability and nuanced judgment are mandatory.

Consider Retrieval-Augmented Generation (RAG). A vector search might retrieve fifty candidate chunks from a vector database. Throwing all fifty passages into a full-scale LLM context window is both slow and expensive. A fast decision layer can pre-evaluate and rank the relevance of those candidate chunks first. The vector search fetches candidates, Jev scores their relevance, and the generative LLM only processes the top three validated contexts.

---

Jevons Paradox for Intelligence

The name Jev is explicitly derived from Jevons Paradox in economics: as a resource becomes significantly more efficient to consume, total consumption actually increases rather than decreases because new use cases become viable. TypeSafe's core thesis is that machine intelligence will follow this exact trajectory.

The real opportunity here is not merely swapping out a £1.00 LLM API call for a £0.01 decision call to save a small percentage on cloud bills. The real breakthrough is discovering hundreds of micro-decisions across your codebase where calling an AI model was previously unthinkable due to speed constraints and API costs.

Semantic checks can start populating regions of your codebase where traditional boolean logic is too brittle: verifying if a document segment matches user intent, scoring whether an incoming message requires an alert, or determining if cached data remains relevant. These are probabilistic questions, but they do not require a model capable of writing poetic prose.

---

Not Everything Needs to Talk

This is not a story about replacing LLMs entirely. For open-ended reasoning, interactive chat, creative output, and automated coding, full-blown generative models remain unmatched. Instead, this represents a shift away from forcing one tool to solve every architectural requirement.

For the past few years, engineering teams have spent countless hours asking which LLM should we use? The far better question now emerging is what specific tier of intelligence does this component require? Sometimes you need a frontier model, sometimes standard deterministic code is perfect, and there is a massive, untapped space opening up right in between.

Sometimes your application does not need the machine to talk. It just needs it to decide.