The day after the release of Jev, the first System One model, a friend sent us a message asking how it related to our tool, DecisionRules. In fact, both are used to automate decisions: Jev is a decision model; DecisionRules is a decision engine. The purpose of this article is to answer the question of this friend (one that implicitly asks which solution is better). The conclusion, to no one’s surprise, is that an original competitive comparison rests on false assumptions. These two tools are not rivals; rather, they are complementary in automating decisions. Yet, this must be demonstrated through open argumentation.
Claim
There is an intersection between Jev and DecisionRules in decision automation. Now, we want to show, through a proof by cases structure, that 1. If we assume a competitive intersection between Jev and DecisionRules, the result is that they are composable tools, and 2. If we assume a complementary intersection between them, the result is also that they are composable tools. Therefore, they are composable tools, a good combination for the expected digital transformation of the coming years.
Justification
1. From the outset, we clarify that they belong to different system families, so a comparison may seem problematic. However, they are leaders within their respective categories, and their high quality provides the best basis for evaluating the general approach of both systems.
a. Jev: An AI solution. The model is called the System One Model, with an internal structure similar to LLMs but modified to guarantee type-safe responses. It claims to offer a trustworthy AI solution for an economic revolution.
b. DecisionRules: A modern Decision Rules Engine. Building upon the legacy of Business Rules Engines (BREs), this software designs and centralizes a company’s standards, or business rules. It claims to offer a user-friendly, no-code/low-code UI for direct use by non-technical teams.
2. The current landscape of digital transformation is pushing companies to future-proof technology stacks. CTOs and Solution Architects face pressure to select the best tools for this transformation, balancing technological, commercial and legal requirements. An accurate assessment of these two important decision automation tools provides useful orientation in this task. Moreover, if directors are choosing between external providers and in-house solutions, this article offers valuable background for their decisions.
3. More broadly, skepticism and hope are intertwined in every AI investment. In this context, comparing AI solutions to other market tools can help nurture more mature opinions and healthier discussions in the field.
Methodology
We compare Jev and DecisionRules, from the results, we deduce that the compared properties do not oppose the two tools but instead reveal that they are composable. In the case where we assume they are complementary, it is intuitively clear that this implies composability; also, the analysis itself illustrates how they are composable.
For the comparison, we divide the properties (functionalities of the systems) into two groups:
- Similarities: Features common to both platforms.
- Differences: Features unique to each platform.
Judgment regarding each functionality will differ depending on the group.
For the first group, features are evaluated based on practical experience in digital automation. Since real-world automation projects with economic impact are inherently practical, professional experience (corroborated by theoretical documentation and examples) forms the best framework. We classify the superior feature in each category as optimal.
For the second group, features are original and thus evaluated based on the additional benefits they bring to practical automation. We classify these benefits as advantages.
For the conclusion, we combine the optimal features and advantages of each system. These put together enable an argument concluding that Jev does not replace DecisionRules; rather, the current digital environment has cultivated a strong symbiosis between them.
Similarities
Structured Output Model
Unlike current LLMs, the recently introduced Type-Safe AI known as Jev does not return generated text for human reading. Like DecisionRules, Jev is constrained to return an element from a predefined set of outputs. This set may contain one, two, or hundreds of possible elements, but the system can only return outputs from within this set. The advantages are numerous: parsing is unnecessary because results are structured by design; system behavior can be secured; and users gain more control.
The first System One Model supports three primitives (or question types), each corresponding to a distinct set of possible results:
- Choice: A fixed set of options
- Score: Fixed positions on a user-defined spectrum
- Noul: The probability that a statement is true (0 or 1)
For each of these predefined sets, selection is straightforward. Given a question, the AI performs a probabilistic analysis and selects the option, position, or truth value with the highest probability.
DecisionRules defines output sets visually, with different rule types representing these sets in different ways. For example, in a decision table, the results column can list any number of possible outputs, enabling the expression of options, positions, boolean values, and more.
So far, the approaches are similar. The optimal feature emerges when a scenario requires responses with complex structures.
In DecisionRules, the answer is upfront: the platform returns an array of customizable JSON objects. This simple model allows the creation of more complex JSON structures for each array element. For instance, you can return the single best product or the top three products from a list; you can return a failure status along with an array of failed validations; or you can generate multiple data maps.
Jev’s answers are deliberately atomic: each question returns a typed value along with its probability distribution, and TypeSafe recommends combining these answers programmatically. Advanced patterns, like traversing a taxonomy through multiple questions, are possible, but the shape of each individual answer remains unchanged. Complex scenarios, such as attaching a product ID to a resulting discount, are not natively supported.
Therefore, DecisionRules’ structured output model offers greater flexibility and capability for diverse result scenarios, and is hence optimal.
Natural Language Input
Two years ago, it was not obvious that a BRE could process natural language. However, rapid advances in AI have enabled modern Decision Rules Engines to incorporate this capability. In Q2 2026, DecisionRules was among the first engines to release a new AI Agent Rule, integrating LLM capabilities into rigorous decision workflows.
The idea behind the AI Agent Rule resembles the vision behind Jev. Engineers at DecisionRules created a framework allowing users to connect their own LLM provider (e.g., OpenAI, Anthropic, Google, etc.) within a constrained Input/Output model. The rule receives inputs defined in its input model—such as free text, documents, or transcripts—and returns JSON-structured, type-safe outputs. Natural language enters through the AI prompt, where users insert dynamic attributes from the input; the rest of the prompt remains static. The logic for each possible output is defined similarly to Jev, with criteria descriptions paired with output elements.
For a closer look at how the AI Agent turns natural-language input into structured data for downstream rules, see AI Agent in DecisionRules: The First Rule Type That Thinks.
Clearly, System One models like Jev consume natural language. The question of which solution is more optimal here comes down to performance.
After testing with real decision tasks from financial use cases, Jev delivered faster and more accurate responses than the AI Agent Rule powered by general LLMs. In this sense, the task of transforming unstructured input into structured data is performed better by a System One Model. Thus, Jev’s natural language processing is optimal.
Confidence
Jev aims to be a reliable model, so the system returns a confidence value alongside each Choice or Score. This attaches a measure of reliability to the result. Two benefits stand out. First, it gives control: systems consuming Jev’s outputs can set a minimum confidence threshold, processing results only when certainty is high. Second, Jev is trained to be honest about its certainty. If you collect all answers where Jev reports 80% confidence, approximately 80% of them will be correct. TypeSafe calls this training method RLCD.
DecisionRules also provides confidence, but not as an attached value to the result. Since the confidence level is always the same for each response, it can be considered implicit. The level for predictable and deterministic software is 100%. The intended UI for non-technical users does not compromise the underlying conditional logic of standard programming.
The optimal feature depends on the use case, as different scenarios imply different priorities. However, in practice, industries such as finance, insurance, manufacturing, and logistics demand total predictability. This is non-negotiable for technical teams and providers.
While System One Models are optimized against outcomes, leading to better-calibrated probabilities, they explicitly state: individual answers are not guaranteed to be correct. In enterprise environments, optimal decisions rely on predictable, deterministic systems where additionally, processes can be inspected step by step, like audits in DecisionRules.
Therefore, DecisionRules’ confidence model is optimal.
Before jumping to conclusions, we must examine the functionalities that place these tools in different system families. This will help explain why they approach differently the similar features discussed above, and clarify how their goals and solutions relate.
Differences
Audit logs - DecisionRules
DecisionRules goes beyond typical Business Rules Engines (BREs) by offering a robust audit logging system. Let us see how it is unique.
Jev's output is divided into three atomic components: the typed answer (one of the three primitive results), the probabilities, and the confidence value. While this supports model control, it is not an audit log. A full logging system: recording the API input, output, metadata (date, status, execution time) must be built externally. In contrast, audit logging is built-in and "out of the box" in DecisionRules.
Data Retention Controls: Compliance on Your Terms
Furthermore, other platforms in the market also offer audit logs that include input, output, and execution time. However, institutions often need more: the ability to justify why a specific result was returned. A strong audit feature should show exactly which condition was met (or not) for each individual case, even within complex AND/OR logic chains. DecisionRules delivers this for the log of every decision because its condition chains are explicitly defined and human-readable.
The advantages are clear, but let’s consider a related question:
Will System One Models ever generate strong audit logs?
Never say never, but current trends suggest it’s not on the roadmap. For now:
- Adding reports with inputs, outputs, and explainability to AI responses would improve transparency (currently, Jev does not provide explainability). But this alone is insufficient: such explanations are typically in natural language, whereas trusted systems require structured, consistent logs.
- Even if explainability results were structured, the model's probabilistic nature implies that each log entry would carry its own confidence value. Consequently, the audit trail becomes probabilistic. But regulatory frameworks demand for a long part of the decision chain, deterministic, factual records, regardless of high confidence. Further, requesting explainability for those probabilities could lead to an infinite explanatory loop.
In short: To meet compliance standards is fundamental in audit logs, therefore determinism is non-negotiable in some regulated decisions. Those decisions are claimed by DecisionRules.
Instructions and Criteria - Jev
In a request to Jev, the user provides a question or decision problem under the label instructions, and this is unique. We have two advantages:
- The use of natural language.
- The introduction of mental clarity into the decision process.
The second point is often underestimated, but crucial. Consider communication and knowledge transfer: explaining a decision made by an automated system requires clear understanding of the decision problem, not just intuition. Or consider maintenance by a new generation: specifying the question we are answering explicitly can be far clearer than relying on vague use-case labels.
For discussing the use of natural language, it’s also important to discuss the criteria field in a Jev request.
DecisionRules, of course, also makes decision criteria explicit when designing rules. But how they do so differs: Jev uses natural language, while DecisionRules uses visual, formal logic.
The ability to define logic in plain English was a long-sought goal in IT projects. In that sense, Jev represents a dream realized. But the counterargument has always existed, and remains interesting.
The original motivation for this dream stemmed from an objection: non-technical people cannot understand formal logic, so even visual interfaces still require too much technical literacy. This concern was based on real-world cases where business teams resisted adopting BREs due to learning difficulties.
In that context, plain-language explanations of the reasons behind a decision are helpful and represent a clear advantage.
Yet, this advantage is double-edged. Natural language offers intuitive clarity, but reduces tool clarity. We must remember that logic was formalized to ensure transparency, precision and security in reasoning. Despite being universal, formal logic is not effortlessly acquired. Removing formalism from machines risks sacrificing transparency and security in the system itself.
This warrants deeper discussion, that exceeds our capacities. To close however, consider a quote from Alfred North Whitehead:
“By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.”
Accepting that too much formal and technical knowledge is unrealistic, we should recognize that a certain degree of technicality is beneficial for business users and their teams. It empowers them to think clearly, act precisely, and innovate sustainably.
User friendly - DecisionRules
A key difference lies in targeted users:
- Jev is designed for developers.
- DecisionRules is designed for business users.
This means that, despite using natural language, Jev’s way of describing rules or criteria does not look for the use of non-technical users.
Let me use a visual comparison of both interfaces for clarity:
Jev and DecisionRules interface comparison
This is not a flaw in Jev, in fact, they are not aiming to solve this problem. Instead, their goal is to embed AI safely into robust technical infrastructures, where architects and engineers rely on predictable, modular components.
DecisionRules, in contrast, addresses a different challenge in digital transformation: who will use and maintain digital tools?
This question does not have a simple answer. But, based on experience, when decisions depend on human pragmatics and contextual semantics, it’s essential that subject-matter experts, not just developers, can manage the rules behind the automation. DecisionRules dramatically reduces time-to-market and lowers the technical barrier for rule changes, making automation sustainable over time.
This is the feature helping the most to show that each tool optimizes a different dimension of decision automation.
Semantic Judgment - Jev
Jev claims a broader scope of applicable use cases. So far, we’ve focused on decisions, but System One Models go beyond that. They perform what they call semantic judgment and decisions.
This section highlights use cases exclusive to Jev, which DecisionRules cannot support:
- Scientific discovery
- Semantic code linting
- Gaming
- Lead generation
- Graphs and knowledge graphs
These applications arise from the model’s adaptability: its ability to work with diverse, unstructured inputs without strict data constraints. And makes the possible scenarios more flexible.
The originality of these scenarios offers a standalone advantage for Jev, and also, Jev’s performance and preparation make it significantly more useful than other traditional LLMs.
Testing Suite - DecisionRules
IT teams are familiar with testing methodologies, but this knowledge rarely extends to other departments. Business users often propose rule changes, but regardless of size, those changes must be tested by IT to ensure system stability. Resulting in a back-and-forth process: request, test, feedback, revise, request with an improvement. It creates a major bottleneck in many organizations.
DecisionRules goes beyond other BREs by offering Rule Testing: a module for creating and running custom test sets. Users can simulate hundreds of scenarios per rule and across versions. With a single click, they can input test data and compare results.
This puts control in the hands of business users while maintaining the security and rigor needed for safe changes. For audit purposes, all test executions are stored, and historical results are fully accessible.
Unit and Regression Testing: All in One Place
In contrast, Jev delegates testing entirely to developers, they can solve either through code or external services. Similarly, version control is also left to the engineering team.
This reflects a fundamental difference: one tool empowers users; the other assumes developer ownership.
Conclusion: composable tools
Putting together all eight observations (similarities and differences), we can deduce two conclusions:
- Regardless of the intersecting capabilities, both tools solve distinct areas of the automation problem without overlap, meaning both are valuable by themselves.
- If you adopt one, the other naturally emerges in the intersection as its symbiotic partner for full optimization of decision automation.
Independent utility
From the tentative definitions in the beginning, it was possible to see that both tools serve different purposes in decision automation. And now, even assuming that one can substitute the other for some functionalities, we arrive again at the same, different areas and purposes.
Because of the user friendly and testing suites advantages, we saw that the targeted users are different.
The areas of the use cases are different as well:
- Audit logs and testing suites indicate a focus on regulated environments, where compliance, traceability, and stability are critical.
- Semantic judgment, on the other hand, points to intellectual tasks involving understanding, classification, and discovery—where absolute security is less central.
The similarities in input and output models revealed that they also optimize for different data models:
- DecisionRules: Structured input → structured output
- Jev: Natural language input → structured atomic output
| DecisionRules | Jev | |
|---|---|---|
| Targeted Users | Non-technical users | Technical users |
| Data Model | Structured Input → Structured Output | Natural Language Input → Structured Output |
| Area of Use Cases | Regulated Companies | Semantic understanding projects |
From an architectural perspective, this means both tools are useful for different types of projects. For example, in DecisionRules, a common use case is returning an array of failed validations from a decision flow. In Jev, the concern is whether the confidence level meets a threshold to continue the workflow. These distinct behaviours are also the hint for the compatibility: the flows.
Composable for optimal practice
Let us build the argument across three premises:
- Jev is designed for programmatic workflows. TypeSafe AI explicitly states that Jev’s results are meant to be processed by code. Safety mechanisms, e.g. overage thresholds, fallback logic, confidence gates, are implemented in application code, not in Jev itself.
- Jev outperforms general LLMs in decision tasks. As shown above, Jev delivers faster, more accurate structured outputs than general LLMs. As also discussed above, its probabilistic nature of the structured outputs means that confidence-based logic must be externally enforced, again, in code.
- DecisionRules enables structured decision orchestration. Its Decision Flow feature allows users to chain rules, define logical dependencies, and control execution order. In DecisionRules Academy, it’s recommended to always integrate the AI Agent Rule into Decision Flows, to combine AI power with deterministic control.
From the premises two and three we can deduce that Decision Flow offers the capacity to orchestrate the decisions taken by Jev with the decisions taken by the deterministic rules of DecisionRules, in one flow.
Here’s how they compose in practice:
- Jev handles the part of the workflow that requires consuming natural language and producing high-quality, atomic structured outputs.
- DecisionRules uses its native UI to build deterministic, transformational logic that acts on Jev’s outputs—especially based on confidence levels.
- The Decision Flow orchestrates the whole process, ensuring trustworthy, auditable decisions that comply with company standards.
From the premises one and three we can deduce that the safety mechanisms expected by Jev, can be implemented in DecisionRules for better performance. Each tool covers the other’s gap:
| System One Model (Jev) | DecisionRules |
|---|---|
| Integrates safely with code | Provides a centralized, secure environment for safety logic |
| Delivers high-performance AI | Auditable, predictable rules managed by business users |
| Processes unstructured input | Enables non-technical experts to maintain compliance logic |
| Empowers IT to focus on semantic integration, not rule testing |
Together, they allow:
- Non-technical teams benefit from natural language input while retaining auditability and control.
- AI-driven systems to achieve full automation without sacrificing compliance or traceability.
In conclusion, if you are considering one of these tools, the other will naturally emerge as the ideal partner. If you’re automating decisions with non-technical users, combining Jev’s natural language understanding with DecisionRules’ governance features delivers both accessibility and intelligence. If you’re building AI-powered automation, integrating Jev with DecisionRules ensures confidence thresholds, audit trails, and business rule enforcement—without overburdening developers. They are not rivals. They are composable partners in the future of decision automation.
Co-author Ivan Peresta
Ivan Peresta is a Product Analyst and works in Professional Services at DecisionRules. He helps shape product features, test and document them, and support customers in putting decision automation into practice. He also contributes to AI-powered rule features and the DecisionRules MCP server. Read more in Ivan's profile.
Gerardo Cabaña works at DecisionRules, collaborating closely with clients across their digital initiatives. He focuses on operational and infrastructure analysis, business rule and standard documentation, industry regulatory compliance, and aligning technical capabilities with business solutions. Guiding clients from the initial demo through rigorous evaluations, realistic roadmaps, and high-impact Proofs of Concept (PoCs), he regularly bridges the gap between technical teams and executive decision-makers.
