Why fast, typed probabilistic judgments like TypeSafe Jev and Bespoke Nimble are transforming AI software architecture.
Join developers getting comprehensive guides, code examples, optimization tips, and time-saving prompts to accelerate their development workflow.
No spam. Unsubscribe anytime.
A new approach to AI is emerging: models designed to make fast, structured decisions that software can use directly.
On September 15, 2026, TypeSafe AI introduced Jev, its first System One Model. You provide information, define a question, and specify the possible answers. Jev evaluates the options and returns a decision with probabilities.
The implications go beyond a new model release. Developers can begin treating semantic judgments as small, reusable components of application logic. A workflow can ask a series of precise questions, use the answers to determine its next steps, sync embeddings into a vector store via deterministic vector pipelines, and reserve more capable reasoning models for problems that require deeper analysis.
Jev is a timely example of this approach. Open-source projects are already exploring similar techniques, including ways to train models on business-specific decisions.
I see considerable potential for the CMS platforms, internal applications, and business workflows I work on. This article introduces the concept and the architectural shift behind it. I will cover practical integration, open-source alternatives, training, and evaluation in separate articles.
Most developers first experience modern AI through a generative language model.
We provide a prompt and receive an answer. The model might produce an explanation, write code, summarize a document, or return structured JSON.
That interface is useful because it supports an enormous range of tasks. It has also become our default approach to integrating AI into software.
Consider a customer submitting this message through a website:
I was charged twice for my order. Please resolve this before Friday.
The application needs to identify the appropriate department and determine whether the request requires urgent attention.
A generative LLM can analyze the message and return a JSON object containing a department and priority. Structured-output contracts can constrain that response to an expected schema.
Jev provides a different interface for the same task.
The application supplies the message as context and asks which department should handle it. The possible answers might be billing, sales, and technical. It can also ask whether the customer expresses urgency.
Jev evaluates those predefined questions and returns typed decisions.
A generative LLM produces a response token by token. Jev evaluates the answer options you provide and returns decisions that software can use directly.
This is the essential distinction. The application defines the questions and controls what happens after the model answers them.
TypeSafe describes Jev’s interface as unstructured state in, typed probabilistic decisions out.
The state contains the information being evaluated. It could be a support message, an article draft, a document, a retrieved passage, or an AI agent’s proposed action.
The questions define what the application needs to know about that state.
Jev supports three question types:
Multiple questions can be evaluated against the same state in one request. The official quick start demonstrates this pattern with customer-support decisions.
Defining the answer space gives the application an explicit contract. If the permitted departments are billing, sales, and technical, the model cannot introduce an unexpected fourth department identifier.
A valid answer can still be incorrect. Jev might select sales when the message clearly belongs to billing. Typed outputs make integration more predictable; reliable automation still requires testing the quality of the decisions.
Classification is established technology. Traditional machine-learning classifiers, BERT-based models, natural-language inference, and generative LLMs can all categorize information.
The emerging change is architectural.
Software already contains thousands of decisions. Some are expressed as explicit rules. Others depend on understanding what a person means.
An application can calculate whether an invoice is overdue from its due date and payment status. It can determine whether a user has publishing permission from their assigned role.
Interpreting a customer’s intent is different. The customer may describe a billing problem without mentioning billing. A document may contain a sensitive claim without using any of the keywords an application expects.
Semantic models make it possible to evaluate these meaning-dependent questions within an ordinary workflow.
A website can classify an inquiry before creating a CRM record. A CMS can flag a draft for review. An internal application can identify requests that appear to fall outside its usual process.
Each evaluation becomes a bounded responsibility inside a larger system.
The architectural shift is toward composing applications from deterministic rules, semantic decisions, and deeper reasoning, with each component responsible for a different kind of work.
That separation also gives developers a clearer way to evaluate and replace individual components.
This is the part of the approach that interests me most.
I recently worked on a multi-brand Payload CMS architecture involving products, articles, recipes, departmental responsibilities, permissions, and editorial approval workflows.
Designing that system required understanding how the organization operates. Different teams own different content. Some material requires additional review. Publishing depends on permissions and workflow state.
A decision model could extend such a system by suggesting which department should handle a draft or identifying content that warrants specialist attention. The CMS would continue enforcing permissions, assigning authorized reviewers via custom administrative interfaces, and controlling publication.
I have not deployed Jev in that project. The architecture provides a concrete example of where semantic decisions could fit.
To design those decisions, we need to understand the business processes behind them.
“Evaluate this article” is a vague instruction. “Does this article contain a product claim that requires specialist review under our editorial policy?” defines a more precise responsibility.
The second question also exposes work that must happen around the model. Someone needs to define the policy, identify relevant evidence, establish the possible outcomes, and decide how the workflow should respond.
Knowing the business well enough to ask the right questions becomes a central part of building AI-enabled software, demanding sound engineering judgment over technology hype.
As decision models become cheaper and faster, identifying valuable decisions may become as important as choosing the models that evaluate them.
TypeSafe advertises Jev at approximately $0.042 per million input tokens, with no additional output-token charge. The company reports response times of roughly 70 to 500 milliseconds.
Those are vendor-reported figures. Actual performance and cost-effectiveness need to be established for a specific workload.
The interesting implication is how frequently an application might be able to evaluate meaning.
A website could classify every incoming inquiry. A CMS could assess each draft as it enters an approval workflow. An AI agent could evaluate whether its next proposed action requires additional scrutiny.
These are small decisions, but they occur repeatedly.
Low inference cost expands the set of workflows worth investigating. It also makes it practical to consider several focused evaluations instead of asking one model to handle a broad, loosely defined task.
Model price is only one part of the calculation. Integration, infrastructure, monitoring, incorrect classifications, and human review still carry costs. The value of automation depends on the outcomes of the complete workflow.
The interest surrounding Jev has already encouraged developers to explore similar decision-oriented approaches using open models.
One example is Bespoke Nimble. It uses a Qwen-based model to evaluate predefined answer candidates and return typed decisions. Its maintainers have published a local-inference approach and a training recipe. They state that they did not distill Jev’s outputs.
This creates several possibilities for developers.
A team can evaluate a managed decision API, explore a model running on its own infrastructure, or adapt an open model to a specific domain.
These approaches have different tradeoffs. A hosted service transfers much of the inference operation to a provider, while evaluating self-hosted AI vs API providers gives a team deeper deployment control at the cost of hardware and maintenance overhead.
Open implementations also vary in accuracy and generalization. Similar interfaces do not establish equivalent model performance.
The broader significance is that decision-oriented AI is becoming an architectural pattern that can be explored independently of a single provider.
One of the most useful ideas emerging from the open-source work is contrastive training.
Bespoke Nimble describes an approach built around pairs of examples that are almost identical. One important fact changes, and the correct answer changes with it.
Consider two customer messages:
I want a refund for this order.
I do not want a refund for this order.
The difference is small, but it changes the customer’s intent.
Training examples like these help show a model which piece of evidence should affect a classification.
The same principle applies to more complex business decisions. A company may need to distinguish between an inquiry that mentions a product and one that makes a claim about what the product can treat. It may need to identify the exact circumstances that require escalation.
This is where business knowledge becomes training data. The people who understand a process can help define examples, label outcomes, and identify situations that a model must distinguish.
Contrastive examples also give developers a useful way to test a model. Changing a decisive fact should change the answer. Changing an irrelevant detail should generally leave it unchanged.
A handful of examples cannot establish reliability. A production model needs representative data, realistic edge cases, and independent evaluation.
I will explore business-specific training in a separate article.
Jev returns probabilities alongside its decisions.
That creates an opportunity to treat straightforward and uncertain cases differently. A routine request could enter a standard queue, while an ambiguous request receives more analysis or human review.
The probabilities need to be interpreted carefully.
A model reporting 95% probability does not guarantee that a particular decision is correct. Developers need to test calibration: whether predictions made with a given level of confidence are correct at a corresponding rate across representative examples.
This matters especially when a decision carries significant consequences.
Sending a support request to the wrong queue may cause a delay. Publishing sensitive content without review or authorizing an inappropriate action creates a different level of risk.
A semantic model can provide an assessment. The application must determine how that assessment affects the workflow.
TypeSafe’s documentation of Jev’s limitations also identifies weaknesses involving numerical precision, date comparisons, multi-step reasoning, and other tasks requiring exact or extended computation.
Permissions, arithmetic, and other deterministic requirements should remain in code. Consequential decisions need safeguards appropriate to their risks.
TypeSafe uses the term System One for fast, decision-oriented models. It borrows the name from the distinction between fast judgment and slower, deliberate reasoning.
For developers, this is a useful analogy for dividing work between components.
A decision model can classify an incoming request. A reasoning model can investigate an unfamiliar problem or examine a complex case. Application code can validate conditions and execute authorized actions.
A workflow can combine these capabilities without requiring every step to use the same model.
That raises a useful architectural question: which decisions need semantic interpretation, which require extended reasoning, and which already have exact answers in code?
Answering it requires understanding both the technical capabilities and the business process.
It also provides the foundation for the next stage of this discussion: how to route work between models, evaluate the quality of each decision, and design the actions that follow.
This article establishes the conceptual foundation. The implementation questions deserve their own treatment.
I plan to explore Jev’s API and TypeScript integration, open-source and self-hosted alternatives, contrastive training for business-specific decisions, and methods for evaluating accuracy, calibration, latency, and cost.
Those topics will move from the idea to practical engineering choices.
Jev is a specialized decision-model product with a typed, probabilistic interface. Classification and probabilistic prediction existed long before its launch. The emerging paradigm discussed here concerns how developers compose fast semantic decisions inside applications.
Yes. Generative LLMs can classify information and return structured outputs. The relevant comparison is their performance on a specific workload, including accuracy, calibration, speed, and cost.
Jev is designed for bounded judgments. Open-ended generation and complex investigation require other capabilities. A larger application can combine decision models, reasoning models, and deterministic code.
Some open-source implementations support adapting models with labeled examples, including contrastive pairs. The process requires clearly defined decisions, representative data, and independent evaluation.
A high reported probability is insufficient on its own. The model needs to be evaluated for calibration, and the consequences of an incorrect decision must determine the safeguards.
Jev has brought attention to an approach that could change how we design AI-enabled software: making semantic judgments fast and inexpensive enough to use throughout ordinary applications.
The opportunity extends beyond classification. Developers can break a workflow into precise questions, evaluate them with appropriate models, and connect the answers to existing software that controls what happens next.
For the CMS platforms and internal applications I work on, the most interesting implication is how closely this brings business understanding and software architecture together.
The better we understand the decisions inside a business, the more precisely we can define them, evaluate them, and build useful automation around them.
I will explore the practical implementation and model choices in the next articles.
Thanks,
Matija
| Primitive | What it does | Example |
|---|
| Choice | Selects from predefined options | Which department should handle this request? |
| Noul | Evaluates a yes/no condition | Does the customer request a refund? |
| Score | Evaluates a defined scale | How frustrated does the customer appear? |
