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. (This group is presented in Part 2 of this article.)
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. (This conclusion will be presented in Part 2.)
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.
To be continued…
So far, the competitive comparison has been carried to its logical extreme, forcing us to choose a superior option in each case. In the next part, we will add the examination of the unique functionalities of each system. This will imply new perspectives and reveal further how they are not competitors, but collaborators.
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.