LLMs Generate. Jev Decides. Software Should Know the Difference Mokapot Labs integrated TypeSafe's Jev, a so-called System One Model designed to make fast, bounded, structured decisions rather than generate open-ended text, into its open-source Pipeline Framework and used it in a real invoice-processing application. The team found that tasks such as classification, routing, and selecting from a known catalogue — which had been handled by prompting large language models — were never generative problems in the first place. Jev exposes decision shapes including Choice, Noul, and Score, returning probabilistic decisions intended for software consumption rather than prose for human readers. For the last few years, we have been solving an extraordinary range of software problems with essentially the same primitive: send some context to a large language model and ask it to generate the answer. That has worked relatively well, but it has also encouraged us to turn problems that are not fundamentally generative into generation problems. Classification becomes generation. Routing becomes generation. Selecting one item from a known catalogue becomes generation. Determining whether a condition holds becomes, you guessed it: generation. And then, because a generative model is free to generate almost anything, we spend an increasing amount of effort constraining it: Return exactly one of these values. Do not invent identifiers. Return exactly this JSON structure. Do not include an explanation. Do not wrap the result in another object. Never return anything outside the supplied catalogue. Structured output has made this considerably better. But there is still something slightly peculiar about the underlying architecture. We are using a machine designed to generate an open-ended sequence of tokens, and then asking it very politely not to be open-ended. TypeSafe's Jev presents a fascinating alternative. And when we integrated Jev into The Pipeline Framework and then used it in a real invoice-processing application, something became very clear: some of the work we were giving to an LLM was never an LLM problem in the first place. TypeSafe describes Jev as the first of its System One Models : models designed not primarily to generate language, but to make fast, structured decisions that software can consume directly. Instead of an open-ended generation operation, the abstraction is closer to a bounded decision function. php flowchart LR S State -- G Generative model G -- T Open-ended tokens versus: php flowchart LR S State -- D Bounded questions D -- J System One model J -- R Probabilistic decisions The distinction is profound. TypeSafe currently exposes three particularly useful decision shapes: Choice , Noul , and Score . A Choice selects from a finite set of alternatives and returns the corresponding probability information. A Noul evaluates a proposition probabilistically. A Score evaluates something against an ordered scale. Several independent questions can be evaluated against the same state in one request. The output is not primarily prose intended for a human reader. It is information intended for software . That changes what the model is being asked to do. Consider the difference. A generative approach says: Read this invoice and tell me which property it belongs to. Return exactly one ID from this list and do not invent another one. A bounded decision instead defines: Which property? Choice: PROPERTY A PROPERTY B PROPERTY C In the first case, selecting a valid identifier is a prompt requirement. In the second, it is part of the decision domain. That is a much stronger contract. At Mokapot Labs we maintain a small application called Invoice Assistant. It is built with The Pipeline Framework TPF , an open-source framework for constructing typed processing applications. The application receives an invoice and a property catalogue, extracts invoice information, determines which property the invoice belongs to, optionally performs visual analysis when the supplier cannot be established from text, presents the result for human confirmation, and then performs the required external effects. Its pipeline includes ordinary computation, AI inference, branching, a human Await boundary and replay-safe Commands. Before Jev, its text-analysis stage looked roughly like this: php flowchart TD A Invoice -- B Extract document text B -- C Gemma 12B C -- C1 Extract supplier/invoice nr/amount C -- C4 Classify supplier evidence C -- C5 Select property C -- C6 Explain recommendation/w note C1 -- D Route supplier evidence C4 -- D C5 -- D C6 -- D D -- |Sufficient| E Review D -- |Insufficient| F Vision model This worked. It was not disastrously slow. It was not unreliable enough to force a redesign. But the LLM call was doing several fundamentally different jobs. And our prompt showed it. Part of the original prompt said: Classify supplier evidence with exactly one qualitative supplierEvidenceStatus: EXPLICIT TEXT STRONG TEXTUAL IDENTITY INSUFFICIENT Another part said: Select exactly one property ID present in the supplied catalogue. Do not invent, rewrite or normalize property IDs. Read those requirements again in the context of a System One model. They describe Choices . We had an LLM generating a result and a prompt instructing it to behave as though the output space were closed. But the output space really was closed. For supplier evidence, there were three possible answers. For the property recommendation, the possible answers were precisely the properties already supplied to the application. The problem was not: Generate a property identifier. It was: Choose one of these properties. That difference sounds small. Architecturally, it is enormous. This is where the distinction becomes useful rather than ideological. The application also needs to determine: supplier = "Some arbitrary company name" invoiceNumber = "INV-2026-18473" totalAmount = 68.52 Those are open-world values. The supplier can be a string we have never encountered before. The invoice number is arbitrary. The amount is arbitrary. These are extraction problems, and our existing generative LLM remains well suited to them. So we did not replace the LLM with Jev. We split the problem according to its semantics. The result became: php flowchart TD A Invoice -- B Extract document text B -- C "Generative LLM