The previous article examined how training objectives may change when a model is designed to produce calibrated decisions rather than language. That leads to a practical engineering question: what changes when such a model is actually placed inside a software system?
For most applications built around language models, the model sits behind an interface that is fundamentally textual. The application sends a prompt or a sequence of messages, the model generates tokens, and the application then interprets the result.
Even when the model is instructed to return JSON, the application is still receiving generated language that has been constrained into a particular structure.
System One Models propose a different relationship. TypeSafe describes Jev as producing typed probabilistic decisions for software, with the possible outputs and their structure defined in advance.
That distinction moves the model closer to a conventional software component.
The interesting question is not whether the response happens to look like an object. It is whether the decision itself becomes part of the computational contract.
The Language Model Boundary
A simplified language-oriented architecture looks like this:
Language-oriented architecture:
Application → Prompt → Language Model → Generated Text → Parsing → Validation → Application Logic
The model produces a flexible string. The application then has to determine what that string means.
For a simple conversational application, this may be perfectly reasonable. Language is the interface because a human is ultimately consuming the result.
Production automation creates a different requirement.
Suppose an application needs to determine whether a transaction should be escalated.
The model might respond:
Model response: "This transaction appears suspicious because..."
The application now has to extract the relevant judgment.
A structured-output model can improve this:
Structured output:
{ "risk": "HIGH_RISK", "confidence": 0.91 }
But the architectural problem has not necessarily disappeared. The software still needs to establish that the output is valid, interpret what the fields mean, and determine how the result should affect execution.
The deeper question is therefore: who owns the computational meaning of the output?
Structured Output Is Not the Same as Typed Intelligence
Structured output means that a model's response follows an expected format. Typed intelligence goes further conceptually.
A language model can generate JSON containing a decision. The model is still fundamentally generating a sequence of tokens that happen to conform to a schema.
The schema describes the output format. It does not necessarily change the underlying computational behavior of the model.
TypeSafe's proposition is different. Its public material describes System One outputs as type-safe structured values whose possible outputs and structure are defined in advance. The company contrasts this with language models, where strings are flexible and software typically has to parse and validate them.
| Structured output | Typed decision |
|---|---|
| Language constrained into a format | Decision space defined as part of the interface |
| Application interprets generated content | Application receives a defined decision |
| Schema describes representation | Type describes the computational contract |
The second model is designed around the decision space itself.
That is the architectural shift this article examines.
The Type Becomes Part of the Contract
Software architecture depends heavily on contracts. A function may accept a particular input type and return a particular output type. The developer does not have to interpret the function's result from natural language.
A decision-oriented intelligence component introduces a similar possibility.
Conceptual interface:
Input State → Decision<T> + Probability → Application Logic
The exact implementation should not be confused with a conventional programming-language generic type, but the architectural concept is useful.
The application knows what kind of judgment it is requesting.
For example:
| Primitive | Decision |
|---|---|
| Noul | Yes-or-no judgment |
| Choice | One option from a defined set |
| Score | A value on a defined scale |
TypeSafe's API currently exposes separate Noul, Choice, and Score question and answer schemas, confirming that these are part of the API interface rather than merely editorial categories.
This gives the surrounding software something important: it knows the shape of the intelligence it is consuming.
Intelligence Moves Closer to the Type System
Traditional software types describe computational values.
Examples:
String Integer Boolean Enum Object
These types allow software to reason about what a value is and what operations are valid on it.
A decision-native intelligence component introduces a different kind of value. The result may be semantic rather than deterministic.
Example:
Risk = HIGH_RISK
Probability = 0.91
The value represents a judgment about the world. The probability represents uncertainty around that judgment.
The important architectural question is not whether this becomes a conventional programming-language type.
It is whether semantic judgment can become a first-class computational value that software can compose without translating it through language.
That is a much deeper proposition.
Parsing Moves Toward the Boundary
The difference becomes clearer when the two architectures are placed beside each other.
Language-oriented architecture:
Application → Prompt → Language Model → Generated Text → Parser → Schema Validation → Semantic Interpretation → Business Logic
Decision-oriented architecture:
Application → Decision Contract → System One Model → Typed Decision + Uncertainty → Business Logic
The second architecture does not eliminate validation, error handling, business rules, or other application logic.
It potentially removes a category of translation between generated language and program state.
That distinction matters.
The goal is not to eliminate software around the model. The goal is to make the model's contribution to that software more explicit.
The Model Becomes a Software Component
TypeSafe describes Jev as a kind of frontier-intelligence function call: structured state enters, and typed probabilistic decisions come out.
That framing is architecturally significant.
A conventional language model often becomes the center of an interaction:
User → Agent → Language Model → Reasoning → Tools → Action
A decision-native model can occupy a much smaller position inside the system:
Application → Specific Decision → System One Model → Typed Result → Application Logic
The model does not need to own the entire workflow. It can provide one judgment.
The program remains responsible for composition.
This makes intelligence more similar to another software dependency than to an autonomous conversational entity.
Intelligence Becomes Composable
This is where the architectural consequences become more concrete.
Suppose an application needs to decide whether a transaction should be escalated.
Decision 1:
Risk = HIGH_RISK
Probability = 0.91
Decision 2:
Customer Impact = HIGH
Probability = 0.84
Decision 3:
Manual Review Required = YES
Probability = 0.94
The application can then combine those decisions with deterministic rules.
Illustrative logic:
if risk == HIGH_RISK
and risk_probability > threshold
and manual_review_required == YES
then escalate()
The intelligence does not have to generate the workflow. The workflow is written in software.
The model becomes one component in a larger computational graph.
From Prompt Chains to Decision Graphs
This creates a meaningful difference in how engineers might design AI workflows.
Prompt-oriented workflow:
Prompt → Answer → Prompt → Answer → Prompt → Answer
A decision-oriented workflow can instead look like:
Decision graph:
Input State → Risk? Intent? Eligibility? Confidence? → Software Rules → Action
The model supplies individual judgments. The application defines how those judgments interact.
This changes the engineering surface.
Instead of designing one increasingly elaborate prompt, engineers can design a decision graph. Each node has a defined purpose. Each result can carry uncertainty. The surrounding code controls the sequence, branching, and final action.
The Workflow Becomes the System
This is one of the important consequences of the System One approach.
The intelligence does not necessarily need to live inside one large model call.
Programmatic Rule → Model Judgment → Programmatic Rule → Model Judgment → Human Review → Action
Some questions are better handled by deterministic code. Others require semantic judgment.
The architecture can therefore assign each problem to the appropriate mechanism.
TypeSafe's workflow evaluations describe this approach by decomposing automation tasks into programmatic rules and intelligent judgments, using Noul, Choice, and Score questions and allowing code to handle what does not require model judgment.
This is an important difference from treating the model as the system.
The model becomes part of the system.
The Software Still Owns the Policy
Typed intelligence does not mean that the model becomes the architect of the application.
The model supplies semantic judgment. The application owns policy.
Model:
Risk = HIGH
Probability = 0.91
The application might decide:
if probability > 0.95 → block
else if probability > 0.70 → review
else → continue
Another application could use completely different thresholds.
The model output remains the same. The software policy changes.
This separation allows intelligence to remain reusable while the application's business logic remains explicit.
TypeSafe's product material describes developers setting thresholds for autonomous action or review and combining decisions in code to build larger workflows.
Type Safety Changes What Failure Looks Like
One argument for typed intelligence is not that it makes models correct. It changes the category of failures that software has to handle.
A language model can produce:
"high risk"
when the application expects:
HIGH_RISK
It can return malformed JSON. It can omit a field. It can invent a value that was never part of the allowed set.
The surrounding application has to defend against these possibilities.
TypeSafe makes a stronger claim for System One Models: because possible outputs are defined in advance, type errors are prevented by construction. Its public material distinguishes this from language-model output and argues that type safety is a requirement for reliable automation.
That does not mean semantic errors disappear.
A model can still make the wrong judgment.
Type error is not the same as semantic error.
A system can constrain an output to the allowed structural space while still producing the wrong answer within that space.
Type safety therefore narrows one class of failure. It does not solve intelligence itself.
The Contract Becomes More Explicit
A useful way to think about this architecture is as a computational contract.
| Layer | Responsibility |
|---|---|
| State | Provide the information the decision needs |
| Question | Define what judgment is required |
| Type | Define the valid decision space |
| Model | Produce the semantic judgment |
| Probability | Represent uncertainty |
| Software | Apply policy |
| Workflow | Compose decisions |
| Action | Change system state |
This separation is potentially more important than any individual model architecture. It creates boundaries around intelligence.
The Architecture Becomes More Observable
There is another consequence.
When a workflow consists of discrete decision nodes, engineers can inspect those nodes individually.
Instead of seeing:
Input → Mysterious Model → Final Action
the system can expose:
Risk assessment → HIGH_RISK → 0.91
Customer intent → REFUND → 0.87
Policy eligibility → YES → 0.96
Final action → REVIEW
That gives engineers more places to investigate when a workflow behaves incorrectly.
Was the model's judgment wrong? Was its confidence poorly calibrated? Was the business rule wrong? Did the workflow combine the decisions incorrectly? Was the input incomplete?
These questions are harder to isolate when the entire process is hidden inside a single prompt and model response.
The Architecture Does Not Eliminate Complexity
Moving intelligence into typed decision components does not make software architecture automatically simple.
It changes where complexity lives.
Instead of one large prompt containing business logic, reasoning instructions, formatting requirements, and edge cases, the complexity may move into:
- Decision definitions
- Workflow graphs
- Thresholds
- Policy rules
- State management
- Error handling
- Evaluation
- Monitoring
- Human escalation
That can be a better architecture because the responsibilities are explicit.
But it is not free.
The engineering work still exists. It simply becomes more visible.
From One Intelligent Model to Many Small Judgments
The implications become especially interesting when a workflow contains many decisions.
TypeSafe's workflow evaluations show this pattern directly. Their published examples include security incidents, invoice processing, customer service, and agent trace observability, with workflows decomposed into multiple Noul, Choice, and Score questions.
Decision graph:
Input State → Decision A + Decision B + Decision C + Decision D → Program Logic → Outcome
This is closer to a decision graph than to a conventional chatbot interaction.
The model is no longer asked to solve the entire problem.
It is asked to answer the questions that require intelligence.
The program handles everything else.
Typed Intelligence Is Not the Same as Deterministic Software
There is a subtle but important boundary here.
A conventional function might behave predictably for the same input. A probabilistic intelligence component does not necessarily have the same semantics.
It is still making a judgment under uncertainty.
The type constrains what kind of answer can be returned. It does not guarantee that the answer is correct.
The probability provides information about uncertainty. It does not guarantee the decision either.
The software therefore gains a stronger interface without turning intelligence into deterministic computation.
That distinction should remain central.
The Deeper Architectural Shift
The deeper shift is not simply:
Text → JSON
It is:
Language interface → Decision interface
That distinction changes the role of the model inside software.
| Language-oriented | Decision-oriented |
|---|---|
| Model → Language → Interpretation → Software | Model → Decision → Software |
| Flexible output space | Defined decision space |
| Interpretation is part of integration | Decision contract is explicit |
The second path is shorter because the model is designed around the form of computation the application needs.
That is what makes the idea interesting.
The model is no longer primarily an external language generator that software has learned to consume. It is being designed as a computational component that software can compose.
What This Architecture Still Leaves Open
Several important questions remain unresolved.
- Can typed decision interfaces generalize across sufficiently diverse production problems?
- How much engineering effort is required to decompose a complex workflow correctly?
- Does decomposition improve reliability consistently, or can it introduce errors between decision nodes?
- How should uncertainty be propagated across a decision graph?
- What happens when two model decisions disagree?
- How should engineers monitor semantic errors when type errors are eliminated?
- How much of the apparent architectural advantage comes from the model itself and how much comes from the quality of the surrounding workflow?
These questions matter because a good interface does not automatically produce a good system.
Architecture still determines how intelligence behaves in production.
The Engineering Model
The System One proposition can therefore be summarized as a different division of responsibility.
System One Model
Typed semantic judgment
+
Probability / uncertainty
Software System
Rules + Workflow + State
↓
Action
The model provides the part of the system that is difficult to write deterministically.
The software provides the structure around it.
That may be the most important engineering consequence of the System One approach.
Intelligence does not replace software architecture. It becomes another component within it.
The Next Question
Once intelligence becomes a typed software component, another economic question follows.
If the model is no longer spending compute generating long sequences of tokens, and if workflows can ask many small decision questions instead, what happens to the economics of inference?
That takes the series from engineering architecture to performance and economics.
The next article examines why System One Models could be fast and cheap, and which architectural choices might make those economics possible.
AI Developments Database
This article is part of DataGuy's ongoing tracking of developments in artificial intelligence, model architectures, and machine-native intelligence. Relevant developments and source material are tracked through the AI Developments Database.
Sources
- TypeSafe: Introducing System One Models and Jev
- TypeSafe AI
- TypeSafe API Documentation
- TypeSafe Workflow Evaluations
- TypeSafe Invoice Processing Workflow Evaluation
- TypeSafe Customer Service Workflow Evaluation
- TypeSafe Agent Trace Observability Workflow Evaluation
Editorial note: TypeSafe-specific descriptions of typed outputs, type safety, workflow architecture, and the intended role of System One Models are presented as claims or descriptions from TypeSafe's public materials. The broader architectural interpretation in this article is DataGuy editorial analysis. Type safety constrains the structural output space; it does not establish semantic correctness.