There are several principles that must be followed when writing rules using Oracle Policy Modeling. There are also five axioms that apply to the operation of rules in the Oracle Determinations Engine.
In order to ensure the quality of rules created, Oracle Policy Modeling enforces a number of principles in rule authoring. The most important of these are:
There are five axioms that need to be observed for correct rules system operation. While it may certainly be possible to construct a functioning rulebase by violating one or more of these axioms, the resulting rulebase will be hard to maintain, hard to test, fragile and unreliable. These axioms have guided Oracle Policy Modeling product development and can be recognized in the types of rules that can be created using Oracle Policy Modeling and the error messages that appear if one of these axioms is violated.
The five axioms are:
Any conclusions reached by the business rules management system must be independent of the order in which information is provided.
This is reasonably self-evident, but many business rules management systems fail this basic test. By providing order independence, a safe contract is provided between the rulebase and the user interface designer (the screen designer can order attributes on screens however they desire), as well as the persistence layer (the order of attributes do not have to be preserved).
If the input attributes are changed, no influence caused by the previous values may persist.
To put it another way, changing a value of an attribute within a session should be equivalent to inputting the entire set of attributes into a new session. This axiom provides both for Oracle Determinations Server (which relies on this axiom), as well as load-balancing web servers that support session failover. Event rules in the current system can violate this axiom (worst offenders are warning events), and should be used (and handled) with care.
Adding new information can only lead to conclusions being reached, not forgotten or changed.
If the rulebase has concluded something, then the introduction of new information cannot result in a new conclusion – only by changing existing information can a conclusion be changed or forgotten.
One construct that this axiom forbids is the "not known" operator in a condition of a rule – evaluating to true if the attribute has not been collected yet, and false if it has. This is a dangerous construct, as it involves reasoning on the basis of the order that information is presented (a clear violation of Axiom 1), as well as violating this principle that underlies every other operator.
Every rule must be able to conclude a result given sufficient information.
Axiom 3 introduces the concept that a business rules management system proceeds from conclusions being unknown to known. This axiom requires that they can actually get to the known state. A business rules engine that cannot conclude a value is incomplete – its inability to conclude a value results in rulebase looping or "goal exhaustion", the equivalent of a software crash. If a rule set has insufficient specification to cover every possibility, then it must at least return "uncertain" indicating the engine's uncertainty as to what the result should be.
An attribute cannot have multiple proofs. An attribute with multiple proofs causes a number of violations of previous axioms, as well as introducing some new problems.
Firstly, unless the two proofs are completely distinct (and open-ended), there will be a race condition that violates Axiom 1 (ie they will race to see which one fires first, and the outcome can change depending on which rule fires first). Trying to band-aid this is impossible – for example if you allow one rule to have priority over the other, such that even if the other rule has already fired first, the primary rule can override it, then you fail Axiom 3.
If the rules are completely disjunctive, but do not cover every possibility, then you violate Axiom 4. If the rules are completely disjunctive, and cover every possibility, you still run into trouble because it is non-determinative which rule will be asked first by the GetNextQuestion runtime mechanism. Furthermore, this could change between different compiles of the rulebase, different versions of Oracle Policy Modeling, and so forth.
The other problem is that completely disjunctive rules are hard to maintain – if you make modifications to any of the rules, you have to update the other rules to maintain the strict disjunction, otherwise the rulebase will violate one of the other axioms.
All in all, multiply proven attributes will end up creating a broken rulebase unless you use rule fragments to specify the order in which the rules should apply. For more information see Prove an attribute using multiple rules.
This axiom also applies to shortcut rules. Using a shortcut rule to prove an intermediate attribute is a violation for the same reasons as presented above. A regular shortcut rule – ie one that proves a base attribute – is an interesting side issue to explore. Firstly, multiple shortcut rules proving a base level attribute can cause Axiom 1 violations. Secondly, a user-provided value for a base level attribute should have higher priority than a shortcut rule concluding the same attribute – otherwise there would be a violation of Axiom 3. In other words, introducing a new attribute could fire the shortcut rule, overriding an existing user answer, possibly causing an existing conclusion to change. Logically, the result from a shortcut rule should be treated as though it were a base level attribute – just merely having provided a shortcut for setting it. The user is then free to override this value when appropriate.