The previous article examined how System One Models differ from language models at the architectural level. The central distinction was that language models are fundamentally organized around generating sequences of tokens, while System One Models are designed around producing decisions that software can use directly.
That raises a more specific question. If a model is designed around decisions rather than language, what exactly is a decision?
Software systems make thousands of decisions, but many of them follow a small number of recurring patterns. A system may need to determine whether something is true, choose one option from several alternatives, or determine how strongly something satisfies a condition.
TypeSafe's documentation describes three decision types for these situations: Noul, Choice, and Score. Noul represents a yes-or-no judgment, Choice selects from a defined set, and Score represents a level on a scale.
From Architecture to Decision Primitives
A model designed for software needs more than a structured response format. It needs a defined vocabulary for the decisions that an application actually has to make.
A language model can generate an explanation, classification, recommendation, or piece of code because its output space is intentionally broad. A decision-oriented model approaches the problem differently by defining the form of the decision before inference takes place.
This makes the primitive itself part of the interface between intelligence and software. Instead of asking the model to describe a judgment in language and then interpreting that description, the application can request a particular kind of judgment directly.
Decision-oriented flow:
Application State → Decision Primitive → Software Logic → Action
The significance of Noul, Choice, and Score therefore lies less in their names than in the structure they impose on the interaction between a model and the software using it.
Noul: Is the Condition True?
The simplest decision is binary. A software system may need to determine whether a condition is true or false before it can decide what should happen next.
Examples include determining whether a transaction appears suspicious, whether a request requires escalation, whether an account state satisfies a condition, or whether a message belongs to a particular operational category.
TypeSafe calls this primitive Noul. Its public material describes Noul as a yes-or-no decision accompanied by a probability.
The important distinction is that the model is not being asked to explain its judgment in natural language. The application is asking for a specific computational result that can become part of its execution logic.
The probability also becomes part of the result. That distinction matters because a binary answer alone does not tell the surrounding software how uncertain the model was about the decision.
Choice: Which Option Applies?
Many software decisions are not binary. An application may need to determine which route a request should follow, which category an event belongs to, or which action should be considered next.
This is the structure represented by Choice.
TypeSafe describes Choice as selecting one option from a defined set, with the result accompanied by a distribution and confidence information.
Consider a support system with four possible outcomes: refund, technical support, account review, or escalation. A language model could generate an explanation of which category appears appropriate, after which the application would need to interpret that response.
A Choice primitive makes the decision space explicit from the beginning. The software defines the possible outcomes, while the model determines which option best fits the supplied state.
The application can therefore work with the decision itself rather than reconstructing that decision from generated language.
Score: How Strong Is the Judgment?
Not every decision has a discrete answer. Sometimes software needs to know how much, how strong, or to what degree something satisfies a condition.
This is where TypeSafe's Score primitive fits. TypeSafe describes Score as a rating on a scale, with the result accompanied by a distribution and confidence information.
Examples might include determining the strength of evidence, the severity of an incident, the degree to which a request matches a policy, or the likelihood that a case requires additional review.
A score can then become an input to ordinary programmatic logic. The model provides the judgment, while the application determines what that judgment means operationally.
Example:
Score below threshold → continue processing
Score above threshold → initiate review
Score above higher threshold → escalate
This separation allows semantic judgment to remain with the model while workflow control remains with conventional software.
Three Primitives, Different Kinds of Decisions
Noul, Choice, and Score are not simply three ways of formatting the same response. They correspond to different structures of judgment that appear repeatedly inside software workflows.
| Primitive | Decision Structure | Example |
|---|---|---|
| Noul | Yes or no | Is this activity unauthorized? |
| Choice | One option from a defined set | Which response path applies? |
| Score | Level on a scale | How strong is the evidence? |
TypeSafe's workflow evaluations use these kinds of decisions to break larger tasks into narrower judgments, with software combining the resulting outputs into actions.
This is where the idea becomes more significant than a list of API response types. The primitives provide a way to decompose intelligence into explicit decisions that can participate in a larger software workflow.
From One Prompt to a Decision Graph
Consider a security incident. A production system may need to determine whether the activity was unauthorized, assess the strength of the available evidence, and decide what response should follow.
These questions do not necessarily have the same structure. The first may be represented as a Noul, the strength of the evidence may be represented as a Score, and the appropriate response may be represented as a Choice.
Decomposed Decision Workflow:
Application State → Noul → Score → Choice → Deterministic Action
TypeSafe's public workflow evaluations demonstrate this broader pattern by decomposing complex tasks into narrower decision steps rather than treating the entire workflow as a single open-ended model interaction.
The result is a collection of explicit decisions connected by software logic. The model does not need to own the entire workflow. It provides intelligence at the points where semantic judgment is required, while the application retains control over state and execution.
The Primitive Is Not the Workflow
Noul, Choice, and Score do not replace application logic. They provide the judgment layer within that logic.
A production system can still contain databases, APIs, deterministic rules, thresholds, state transitions, authentication systems, and other conventional software components. The model supplies a particular judgment, while the surrounding software determines what should happen with that judgment.
This distinction is important because decision-native intelligence does not imply that the model should control the entire execution process. The surrounding application remains responsible for workflow orchestration.
The primitive therefore sits between application state and programmatic action. It gives software a defined place where semantic judgment can enter the execution loop.
Computational relationship:
State → Decision Primitive → Software Logic → Action
Why This Is More Than Structured Output
At first glance, these primitives may appear similar to structured outputs already available from language models. A language model can be instructed to return a JSON object containing a category, score, or confidence value.
The architectural question, however, is different.
The issue is not whether a language model can format a decision as structured data. The question is whether the model is designed around the decision itself.
A JSON response can still be generated through sequential token generation. The surrounding software may still need to validate the response, interpret its contents, and handle cases where the generated result does not correspond cleanly to the intended decision space.
System One Models take a stronger position. The decision space becomes part of the model interface rather than simply being imposed on a general language model after generation.
That distinction connects directly to the architectural shift examined in Article 3. The primitive is not merely a schema for the output. It represents the kind of computational decision the model is being asked to make.
The Beginning of Composable Intelligence
Once decisions have explicit types, they can also become composable. A software system can combine a binary judgment with a score, use the result to select a path, and then evaluate another decision based on the resulting state.
Example Decision Chain:
Noul → Was the activity unauthorized?
Score → How strong is the evidence?
Choice → Which response should be taken?
Software → Execute the selected action
The value of the primitive is therefore not simply that it is small. Its value comes from giving software a clearer unit around which intelligence can be composed.
This creates a possible bridge between semantic judgment and conventional program logic. The model can provide the part of the computation that is difficult to express through fixed rules, while the application determines how that judgment affects the rest of the system.
What These Primitives Do Not Tell Us
The existence of decision primitives does not automatically make a system reliable. A Noul can be wrong, a Choice can select the wrong option, and a Score can produce a probability that does not accurately represent the underlying likelihood of correctness.
The primitives define what kind of decision is being requested. They do not, by themselves, establish whether the model's probabilities are trustworthy or whether the resulting workflow behaves correctly under unfamiliar conditions.
That distinction becomes increasingly important as these decisions move closer to production actions. A software system needs more than a typed answer. It needs a meaningful understanding of the uncertainty attached to that answer.
This is where the question of calibration becomes central.
The More Interesting Question
Noul, Choice, and Score provide a compact vocabulary for representing different kinds of software judgment. They also reveal something deeper about the System One approach.
The model is not simply being asked to generate a response that happens to fit a schema. The application can define the decision it needs before inference takes place, and the model operates within that defined space.
That creates a foundation for composable, decision-oriented workflows. It also changes what software needs from the model when those decisions influence real actions.
The next question is therefore not what kinds of decisions the model can produce, but how much confidence software should place in those decisions.
A decision becomes useful to software only when its uncertainty can also be understood.
AI Developments Database
Explore the evolving landscape of model architectures, machine-native systems, and AI developments in the DataGuy Intelligence Repository.
Sources List
- TypeSafe AI: Introducing System One Models & Jev
- TypeSafe AI: API Documentation
- TypeSafe AI: Workflow Evaluations
- TypeSafe AI: Security Incidents Workflow