1 Overview of Oracle Business Rules

This chapter describes the concepts of business rules and provides an overview of the Oracle Business Rules runtime and design-time elements such as facts, valuesets, rulesets, decision tables, Oracle BP Composer and Oracle SOA Composer. It also describes the Oracle Business Rules engine architecture.

This chapter includes the following sections:

For more information on any references to Rules Language and Rules API in this book, see the Related Documentation section of this book.

1.1 Introduction to Oracle Business Rules

Oracle Business Rules makes processes and applications more flexible by enabling business analysts and non-developers to easily define and modify business logic without programming. By leveraging the unified JDeveloper design platform, and maintaining business rules outside of the related process or application, Oracle Business Rules provides faster, easier rule modifications and reduces subsequent redeployment costs.

Figure 1-1 Oracle Business Rules

Description of Figure 1-1 follows
Description of "Figure 1-1 Oracle Business Rules"

Using Oracle Business Rules you can automate policies, computations, and reasoning while separating rule logic from underlying application code. This allows more agile rule maintenance and empowers business analysts to modify rule logic without programmer assistance and without interrupting business processes.

As a business analyst, a user can model a rule in Process Composer and further refine and complete the process in Process Studio.

An IT developer uses the BPM Studio and talk to its business catalogue with well known data types, services, and human tasks implementation. The developer, then, creates a project and publishes it into the business catalogue. Then a business analyst or a business user can go in Process Composer and check out the projects in business catalogue and make changes to the existing process models.

While some users want to model simple calculations with a handful of rules, others use rules for complex decision making and hence a need to have a methodology to approach the decision modeling problem.

Figure 1-2 Oracle Business Rules Components

Description of Figure 1-2 follows
Description of "Figure 1-2 Oracle Business Rules Components"

The Oracle Business Rules includes the rule editor, rule browser, rules engine and rule repository for rule discovery, governance, versioning, traceability and availability across the enterprise. Business rules are defined using the Business Rules editor and stored and managed in a central Business Rules repository. You can reference pre-defined business process rules within the modeler. The Business Rules activity in the business process model gets converted to a decision service that in turn invokes the business rules engine in the executable business process. Business users can change these business policies on the fly via an intuitive web browser interface without having to redeploy or re-implement the business process.

1.1.1 Why Use Oracle Business Rules?

Oracle Business Rules is a high performance lightweight business rules product that addresses the requirements for agility, business control, and transparency.

Business rules are statements that describe business policies or describe key business decisions. For example, business rules can include:

These examples represent individual business rules. In practice, you can use Oracle Business Rules to combine many business rules or to use more complex tests.

For the car rental example, you can name the rule the Driver Age Rule. Traditionally, business rules such as the Driver Age Rule are buried in application code and might appear in a Java application as follows:

public boolean checkDriverAgeRule (Driver driver) { 
   boolean declineRent = false;  
   int age = driver.getAge();
   if(  age < 21 ) { 
      declineRent = true; 
   }
   return declineRent; 
}

This code may be difficult for nontechnical users to understand and modify. For example, suppose that the rental company changes its policy so that all drivers under 18 are declined using the Driver Age Rule. In many production environments the developer must modify the application, recompile, and then redeploy the application. This process is simplified because a business analyst can change policies that are expressed as business rules, with little or no assistance from a programmer. Applications using Oracle Business Rules support continuous change that allows the applications to adapt to new government regulations, improvements in internal company processes, or changes in relationships between customers and suppliers.

1.1.2 Understanding Oracle Business Rules Terminology

A business rule must contain:

  • Rulesets: A set of conditions or actions that determines the outcome of the rule.

  • Facts: Data objects used by the ruleset.

  • Decision functions: Reference to the code that executes the rule.

Additionally, a business rule may contain:

  • Functions: Functions that may be called in the ruleset. An example of this type of function is one that initializes a data object.

  • Globals: Data objects that are used in the ruleset. May be constants.

  • Valuesets: Lists or ranges of values used by the condition.

  • Links: Links to other business rules dict.

The following sections provide additional details about these components.

1.1.2.1 What Are Facts and Valuesets?

In Oracle Business Rules, rules are written in terms of fact types. Each fact is an instance of a fact type. You must import or create one or more fact types before you can create rules, unless you use Verbal Rules, where you have the option of deferring fact type modeling until the executable rule is defined.

In Oracle Business Rules, a FactType is a type definition in the data model and a fact is an instance of that type. For example, rules are written in terms of fact types. The Oracle Business Rules runtime, or a developer writing in the RL Language, uses the RL Language assert function to add an instance of a fact to the Oracle Business Rules. In Rules Designer you can define a variety of fact types based on XML Schema, Java classes, Oracle RL definitions, and ADF Business Components view objects.

You can create valuesets to define a list of values or a range of values of a specified type. After you create a valueset you can associate the valueset with a fact property of matching type. Oracle Business Rules uses the valuesets that you define to specify constraints on the values associated with fact properties in rules or in Decision Tables. You can also use valuesets to specify constraints for variable initial values and function return values or function argument values.

For more information, see:

1.1.2.2 What Are Rulesets?

A ruleset is an Oracle Business Rules container for IF-THEN rules and Decision Tables. A ruleset provides a namespace, similar to a Java package, for rules and Decision Tables. In addition you can use rulesets to partially order rule firing.

For more information, see:

1.1.2.3 What Are Dictionaries?

A dictionary is an Oracle Business Rules container for facts, business phrases, functions, globals, valuesets, links, decision functions, and rulesets. A dictionary is an XML file that stores the application's rulesets and the data model. Dictionaries can link to other dictionaries. Oracle JDeveloper creates an Oracle Business Rules dictionary in a .rules file. You can create as many dictionaries as you need. A dictionary may contain any number of rulesets. For more information, see Introduction to Dictionaries and Dictionary Links.

1.1.2.4 What Are Globals?

Globals are any variables or constants that may be accessed anywhere in the business rule. When you create globals you ensure that a business user can alter the rule behavior without touching the rule logic.

1.1.2.5 What Are Decision Functions?

A decision function provides a contract for invoking rules from Java or SOA (from a SOA/BPM composite application or from components within the composite application). The contract includes input fact types, rulesets to run, and output fact types. For more information, see Working with Decision Tables.

1.1.2.6 What Are Decision Points?

Oracle Business Rules SDK (Rules SDK) provides APIs that let you write applications that access, create, modify, and execute rules in Oracle Business Rules dictionaries (and all the contents of a dictionary). The Rules SDK provides the Decision Point API to access and run rules or Decision Tables from a Java application. For more information, see Working with Rules in Standalone (Non SOA/BPM) Scenarios.

1.1.2.7 What Are Business Phrases?

Business phrases are vocabulary elements that are used to construct tests and actions for verbal rules. As you write a verbal rule, a set of business phrases, derived automatically from terms, facts, globals and other dictionary elements, is made available for inclusion in tests and actions. You can define your own business phrases.

Business phrases are not used in general rules.

1.2 Understanding Oracle Business Rules Formats

Oracle Business Rules provides multiple approaches to writing rules. Rules can be modeled in different ways - as IF/THEN rules, and as Decision Tables.

There are two approaches to writing IF/THEN rules (or just rules) - as general rules, and as verbal rules.

  • General rules use a pseudo-code language to express rule logic

  • Verbal rules use natural language statements to express rule logic

  • Decision Tables are multiple related rules expressed in a spreadsheet-like format.

You write rules and Decision Tables in terms of fact types and properties. See Decision Tables. Fact types are often imported from the Java classes, XML schema, Oracle ADF Business Components view objects, or may be created in Rules Designer. Fact properties have a name, value, data type, and an optional valueset. A valueset splits the value space of the data type into values or ranges that can be used in Decision Tables, choice lists, and for design time validation (see What Are Facts and Valuesets?).

You can write verbal rule tests and actions using derived business phrases as well as user-defined business phrases. Derived business phrases are automatically created using facts, globals and other information in the dictionary while user-defined phrases can be explicitly authored to augment derived phrases. Further, user-defined phrases can either be pre-created or created as needed while composing the verbal rule.

Rules and Decision Tables are grouped in an Oracle Business Rules object called a ruleset (see What Are Rulesets?).

You group one or more rulesets and their facts and valuesets in an Oracle Business Rules object called a dictionary (see What Are Dictionaries?).

For more information, see Oracle Business Rules Runtime and Design Time Elements.

1.2.1 Rules

Rules are used to evaluate conditions and specify actions when the conditions are met (evaluate to true).

You can model rules using two different paradigms:

  • General rules - use a pseudo-code language to express rule logic.

  • Verbal rules - use natural language statements to express rule logic in domain specific sentences that are akin to spoken language. See How are Verbal Rules Different from General Rules?

Rules follow an if-then structure and consist of the following parts:

1.2.1.1 What Are Rule Conditions?

The rule IF part is composed of conditional expressions that refer to fact types.

For example, for a general rule:

IF Rental_application.driver age < 21

The general rule conditional expression compares a business term (Rental_application.driver age) to the number 21 using a less than comparison.

And for a verbal rule:

IF rental car driver is an underage driver

The verbal rule condition is a business phrase that can specify one or more logical tests. (See What Are Business Phrases?).

The rule condition activates the rule whenever a combination of facts makes the conditional expression true. In some respects, the rule condition is like a query over the available facts in the Rules Engine, and for every row returned from the query the rule is activated.

For more information, see:

1.2.1.2 What Are Rule Actions?

The rule THEN part contains the actions that are executed when the rule is fired. A rule is fired after it is activated and selected among the other rule activations using conflict resolution mechanisms such as priority.

A rule might perform several kinds of actions. An action can add facts, modify facts, or remove facts. An action can execute a Java method or perform a function which may modify the status of facts or create facts.

Rules fire sequentially, not in parallel. Note that rule actions often change the set of rule activations and thus can affect which rule fires next.

For more information, see:

1.2.1.3 How are Verbal Rules Different from General Rules?

Verbal rules allow you to use pseudo-natural language statements to express rule logic. They provide a way to write rules using domain specific sentences that are similar to spoken language.

Verbal rules work closely with business phrases, which provide the vocabulary for you to compose natural language tests and actions. See What Are Business Phrases?.

For example, a general rule test as shown in the example below:

IF
all of the following are true
policy is a policy
policyScore.type == Score Type.Policy
policyScore.id == policy.id
car is a Car
carScore is a Score Tracker
carScore.type == Score Type.Car
carScore.id == car.id
customer is a Customer
customerScore is a Score Tracker
customerScore.type == Score Type.Customer
customerScore.id == customer.id
score of a car == carScore.score
score of customer == customerScore.score
score of policy = policyScore.score

THEN
assign new BigDecimal var = newBigDecimal((1+((2-((customerScore + carScore + policyScore)/150))/100))*(Lower Threshold))
assign new double premium = var.setScale(1,BigDecimal.ROUND_HALF_UP).doubleValue()

The verbal rule expression of this same test might be:

IF
ready to calculate premium
THEN
calculate premium base on score of customer, score of policy and score of car

Business phrases such as 'ready to calculate premium', 'score' and so on would detail the logic for the conditions.

You can write verbal rules in a way that suits your style, 'top down' or 'bottom up'.

For example, you can write a verbal rule using business phrases that are not yet defined. Once you have the a verbal rule that expresses the logic for your tests and actions, you can then define the specifics of the business phrases.

You can also compose verbal rules using system provided derived business phrases. These are business phrases that are automatically created based on the existing terms, facts, globals and other dictionary elements.

Alternatively, you can write verbal rules using a bottom up style, by defining all the business phrases you'll need first, and then using them in the tests and actions of your verbal rules.

For more information, see Working with Rulesets and Rules

1.2.2 Decision Tables

A Decision Table is an alternative business rule format that is more compact and intuitive when many rules are needed to analyze many combinations of property values. You can use a Decision Table to create a set of rules that covers all combinations or where no two combinations conflict.

Although a decision table is functionally equivalent to if-then rules, you will find decision tables are ideal for specific circumstances:

  • Complexity

    Decision tables simplify complex rules. When there are multiple rules, each of which have multiple conditions and actions, a decision table is much easier to work with.

  • Conflict resolution

    A decision table will indicate if any of the conditions are in conflict.

  • Gap analysis

    You can analyze a decision table to determine if some conditions are not being accommodated.

For more information, see Working with Decision Tables.

1.3 Oracle Business Rules Runtime and Design Time Elements

Oracle Business Rules provides support for using business rules as a Decision Component or as a library in a Java application. A Decision Component is a mechanism for publishing rules and rulesets as a reusable service that can be invoked from multiple business processes.

To create and use rules in the Oracle SOA Suite or Oracle BPM Suite, or to create rules and integrate these rules into your applications, Oracle Business Rules provides the following runtime and design time elements:

1.3.1 Decision Component (Business Rules) in a SOA Composite Application

Oracle SOA Suite provides support for Decision Components that support Oracle Business Rules. A Decision Component is a mechanism for publishing rules and rulesets as a reusable service that can be invoked from multiple business processes.

A Decision Component is an SCA component that can be used within a composite and wired to a BPEL component. Apart from that, Decision Components are used for dynamic routing capability of Mediator and Advanced Routing Rules in Human Workflow.

Oracle Business Rules Rules Engine (Rules Engine) is available in a SOA composite application using the SOA Business Rule service engine that efficiently applies rules to facts and defines and processes rules.

For more information, see Oracle Business Rules Engine Architecture.

1.3.2 Using Rules Engine with Oracle Business Rules in a Java EE Application

The Rules Engine is available as a library for use in a Java EE application (non-SOA). Rules Engine efficiently applies rules to facts and defines and processes rules. Rules Engine defines a Java-like production rule language called Oracle Business Rules RL Language (RL Language), provides a language processing engine (inference engine), and provides tools to support debugging.

Using Rules Designer you can specify business rules separately from application code which allows you to change business policies quickly with graphical tools. The Rules Engine evaluates the business rules and returns decisions or facts that are then used in the business process.

A rule-enabled Java application can load and run rules programs. The rule-enabled application passes facts and rules to the Rules Engine (facts are asserted in the form of Java objects or XML documents). The Rules Engine runs in the rule-enabled Java application and uses the Rete algorithm to efficiently fire rules that match the facts.

For more information, see Oracle Business Rules Engine Architecture and Oracle Business Rules SDK.

1.3.3 Oracle Business Rules RL Language

Oracle Business Rules supports a high-level Java-like language called Oracle Business Rules RL Language (RL Language). RL Language defines the valid syntax for Oracle Business Rules programs. RL Language includes an intuitive Java-like syntax for defining rules that supports the power of Java semantics, providing an easy-to-use syntax for application developers. RL Language consists of a collection of text statements that can be generated dynamically or stored in a file.

Using RL Language application programs can assert Java objects as facts, and rules can reference object properties and invoke methods. Likewise, application programs can use XML documents or portions of XML documents as facts.

Programmers can use RL Language as a full-featured rules programming language both directly and as part of the Oracle Business Rules SDK (Rules SDK).

Business analysts can use Rules Designer to work with rules. In this case, the business analyst does not need to directly view or write RL Language programs. For more information, see Rules Designer.

1.3.4 Oracle Business Rules SDK

Oracle Business Rules SDK (Rules SDK) is a Java library that provides business rule management features that a developer can use to write a rule-enabled program that accesses a dictionary, or to write customized rules programs that add rules or modify existing rules. Rules Designer uses Rules SDK to create, modify, and access rules and the data model using well-defined interfaces. Customer applications can use Rules SDK to access, display, create, and modify collections of rules and the data model.

You can use the Rules SDK APIs in a rule-enabled application to access rules or to create and modify rules. The rules and the associated data model could be initially created in a custom application or using Rules Designer.

This guide describes the Oracle Business Rules SDK Decision Point API. Using a Decision Point you can access a dictionary and run the rules in the dictionary.

For more information, see Working with Rules in Standalone (Non SOA/BPM) Scenarios.

1.3.5 Rules Designer

The Oracle Business Rules Designer (Rules Designer) extension to Oracle JDeveloper is an editor that enables you to create and edit rules.

Rules Designer provides a point-and-click interface for creating and editing General Rules and Decision Tables. Because you can work directly with business rules and a data model, you do not need to understand the RL Language to work with Rules Designer.

Rules Designer also provides Verbal Rules, with guided authoring (auto-suggest and filtering), and a keyboard based interface. For more information on using guided authoring and keyboard based interface, see How to Add Verbal Rules in SOA Composer.

Rules Designer supports several types of users, including the application developer and the business analyst. The application developer uses Rules Designer to define a data model and an initial set of rules. The business analyst uses Rules Designer either to work with the initial set of rules or to modify and customize the initial set of rules according to business needs. Using Rules Designer, a business analyst can create and customize rules with little or no assistance from a programmer.

Alternatively, in top-down modeling, a Business Analyst can descriptively define the rules which can be implemented by the developer later. These different modeling approaches require collaboration between the developer and the analyst.

In most cases, Rule modeling is done iteratively, with both of them contributing to the creation of a Domain Specific Language that can be used to define rules using less technical and more natural-language like sentences.

For more information about verbal rules, see Working with Rulesets and Rules.

1.3.6 Oracle SOA Composer Application

When a dictionary is deployed in a SOA composite application, Oracle Business Rules lets you view the dictionary or edit and save changes to the dictionary. You can use the SOA Composer application (SOA Composer) to work with a deployed dictionary that is part of a SOA composite application.

For more information, see Using Oracle SOA Composer with Oracle Business Rules at Runtime.

1.3.7 Oracle Business Process Composer Application

The Business Process Composer rules editor enables you to view and edit a rules dictionary. Rules dictionaries are displayed in a tabbed window similar to the process editor and data association editor.

For more information on using Rules in BP Composer, see Working with Oracle Business Process Composer Rules Editor in Oracle Fusion Middleware Developing Business Processes with Oracle Business Process Composer.

1.4 Oracle Business Rules Engine Architecture

A rule-based system using the Rete algorithm is the foundation of Oracle Business Rules.

A rule-based system consists of the following:

  • The rule-base: Contains the appropriate business policies or other knowledge encoded into IF/THEN rules, verbal rules and Decision Tables.

  • Working memory: Contains the information that has been added to the system. With Oracle Business Rules you add a set of facts to the system using assert calls.

  • Inference Engine: The Rules Engine, which processes the rules, performs pattern-matching to determine which rules match the facts, for a given run through the set of facts.

In Oracle Business Rules the rule-based system is a data-driven forward chaining system. The facts determine which rules can fire so when a rule fires that matches a set of facts, the rule may add facts and these facts are again run against the rules. This process repeats until a conclusion is reached or the cycle is stopped or reset. Thus, in a forward-chaining rule-based system, facts cause rules to fire and firing rules can create more facts, which in turn can fire more rules. This process is called an inference cycle.

A Non-Rete Algorithm is also available for use. For more information about both, see The Rete Algorithm and The Non-Rete Algorithm.

1.4.1 Declarative Rules

With Oracle Business Rules you can use declarative rules, where you create rules that make declarations based on facts rather than coding. Here is an example of declarative rules:

IF a Customer is a Premium customer, offer them 10% discount
IF a Customer is a Gold customer, offer them 5% discount

In declarative rules:

  • Statements are declared without any control flow.

  • Control flow is determined by the Rules Engine.

  • Rules are easier to maintain than procedural code.

  • Rules relate well to business user work methods.

When a rule adds facts and these facts run against the rules, this process is called an inference cycle. An inference cycle uses the initial facts to cause rules to fire and firing rules can create more facts, which in turn can fire more rules. For example, using the initial facts, Rules Engine runs and adds an additional fact, and an additional rule tests for conditions on this fact creating an inference cycle:

IF a Customer is a Premium customer, offer them 10% discount
IF a Customer is a Gold customer, offer them 5% discount
IF a Customer spends > 1000, make them Premium customer

The inference cycle that Oracle Business Rules provides enables powerful and modular declarative assertions.

1.4.2 The Rete Algorithm

The Rete algorithm was first developed by artificial intelligence researchers in the late 1970s and is at the core of Rules Engines from several vendors. Oracle Business Rules uses the Rete algorithm to optimize the pattern matching process for rules and facts. The Rete algorithm stores partially matched results in a single network of nodes in working memory.

By using the Rete algorithm, the Rules Engine avoids unnecessary rechecking when facts are deleted, added, or modified. To process facts and rules, the Rete algorithm creates and uses an input node for each fact definition and an output node for each rule.

Fact references flow from input to output nodes. In between input and output nodes are test nodes and join nodes. A test occurs when a rule condition has a Boolean expression. A join occurs when a rule condition ANDs two facts. A rule is activated when its output node contains fact references. Fact references are cached throughout the network to speed up recomputing activated rules. When a fact is added, removed, or changed, the Rete network updates the caches and the rule activations; this requires only an incremental amount of work.

The Rete algorithm provides the following benefits:

  • Independence from rule order: Rules can be added and removed without affecting other rules.

  • Optimization across multiple rules: Rules with common conditions share nodes in the Rete network.

  • High performance inference cycles: Each rule firing typically changes just a few facts and the cost of updating the Rete network is proportional to the number of changed facts, not to the total number of facts or rules.

1.4.3 The Non-Rete Algorithm

The Non-Rete algorithm (NRE) is an alternative to the Rete algorithm that consumes less memory than the Rete algorithm. For many business rules use cases it will also result in improved performance. The core of NRE algorithm is a new rule condition evaluation approach. Key points about the new algorithm:

  • Simpler internal rule representation.

  • Byte code generated for rule tests, rule actions, and user defined functions.

  • More efficient modify operation.

  • Rule conditions not evaluated until the containing ruleset is on the top of the stack. After initial evaluation, re-evaluation occurs on fact operations as needed.

  • Ability to avoid unnecessary re-evaluation when rulesets are only present on the ruleset stack once during rule execution.

  • Preserves rule execution semantics.

The two main differences between the two algorithms are:

  • Rule condition evaluation:

    • In the Rete algorithm, rule conditions are evaluated when fact operations occur (assert, modify, retract).

    • In the Non-Rete algorithm, rule conditions are evaluated for the first time when the ruleset is on the top of the stack, then on fact operations after that.

  • Rule firing order. There are cases where the rule firing order is not defined, for example when a single fact activates multiple rules at the same time and the priorities are identical. In these cases, the order in which the rule activations fire may be different.

    Note:

    It is possible that an existing set of rules has an implicit dependency on the order in which the rules fire with the Rete algorithm even though that order may not be defined. The order may be different with the Non-Rete algorithm which may expose a latent bug in the rules as authored.

1.4.3.1 Configuring the Non-Rete Algorithm

In Rule Designer, the algorithm can be selected in the Dictionary Settings panel in the preferences tab. Algorithm selection is automatically handled for SOA and BPM composite applications. For JEE applications or other non-SOA/BPM applications, the algorithm selection will need to be specified when the RuleSession or RuleSessionPool is created.

For more information about RuleSessions, see Using a RuleSession in the Oracle Fusion Middleware Language Reference Guide for Oracle Business Rules.

It is common that multiple rulesets are executed during a rule execution. It is also common that each ruleset is pushed onto the ruleset stack once and once rules in that ruleset have completed firing, it is not pushed onto the stack again during that rule execution. With the Non-Rete algorithm additional performance gain can be realized for these cases by specifying that the rulesets will only appear on the stack once. When the Non-Rete algorithm is selected, click the 'Rulesets Are On Stack Once' check box in a decision function definition to enable this feature.

For information about when to use the Rete or Non-Rete algorithms, see Rules Engine Algorithm in the Rules Language Reference for Oracle Business Process Management.

1.4.4 What Is Working Memory?

Oracle Business Rules uses working memory to contain facts. Facts do not exist outside of working memory. A RuleSession contains the Oracle Business Rules working memory.

1.4.5 Rule Firing and Rule Sessions

A Rule Session consists of rules, facts and an agenda. An assert or retract adds or removes fact instances from working memory.

When facts in working memory are changed:

  • Conditions for rules are evaluated

  • Matching rules are added to the agenda (Activated)

  • Rules which no longer match are removed from agenda

  • Rules Engine runs and executes actions (fires), for activated rules

Figure 1-3 shows these parts of Oracle Business Rules runtime.

Figure 1-3 Rules in Rule Session with Working Memory and Facts

Description of Figure 1-3 follows
Description of "Figure 1-3 Rules in Rule Session with Working Memory and Facts"

A rule action may assert, modify, or retract facts and cause activations to be added or removed from the agenda. There is a possible loop if a rule's action causes it to fire again. Rules are fired sequentially, but in no pre-defined order. The rule session includes a ruleset stack. Activated rules are fired as follows:

  • Rules within top-of-the-stack ruleset are fired

  • Within a ruleset, firing is ordered by user-defined priority

  • Within the same priority, the default is that the most recently activated rule is fired first. For more information, see the setStrategy function in the Rules Language Reference for Oracle Business Process Management.

For the Rete algorithm, only rules within rulesets on the stack are fired, but all rules in a rule session are matched and, if matched, activated. For the non-Rete algorithm, this is true for rules in the ruleset on the top of the stack. It is also true for rules in rulesets that have been popped from the ruleset stack unless "Rulesets Are On Stack Once" has been checked.