2.5.8. Truth Maintenance with Logical Objects
In a regular insert, you need to explicitly retract a fact. With logical assertions, the fact that was asserted will be automatically retracted when the conditions that asserted it in the first place are no longer true and there are no possible conditions that could support the logical assertion.
Normal insertions are said to be STATED. Using a HashMap and a counter we track how many times a particular equality is STATED, essentially counting how many different instances are equal. When we logically insert an object we are said to JUSTIFY it and it is justified by the firing rule. For each logical insertion there can only be one equal object, each subsequent equal logical insertion increases the justification counter for this logical assertion. As each justification is removed when we have no more justifications the logical object is automatically retracted.
If we logically insert an object when there is an equal STATED object it will fail and return null. If we STATE an object that has an exist equal object that is JUSTIFIED we override the Fact. Eaxtly how this override works depends on the configuration setting WM_BEHAVIOR_PRESERVE. When the property is set to discard the default behaviour is to use the existing handle and replace the existing instance with the new Object. Otherwise we override it to STATED but we create an new FactHandle.
This can be confusing on a first read, so hopefully the flow charts below help. When it says that it returns a new FactHandle, this also indicates the Object was propagated through the network.
Figure 2.26. Stated Insertion
Figure 2.27. Logical Insertion
2.5.8.1. Example Scenario
An example may make things clearer. Imagine a credit card processing application, processing transactions for a given account and we have a working memory accumulating knowledge about a single accounts transaction. The rule engine is doing its best to decide if transactions are possibly fraudulent or not. Imagine this rule base basically has rules that activate when there is "reason to be suspicious" and when "everything is normal".
Of course there are many rules that operate no matter what performing standard calculations and other actions.There are possibly many reasons as to what could trigger a "reason to be suspicious": someone notifying the bank, a sequence of large transactions, transactions for geographically disparate locations or even reports of credit card theft. Rather then smattering all the little conditions in lots of rules, imagine there is a fact class called SuspiciousAccount.
Then there can be a series of rules whose job is to look for things that may raise suspicion, and if they fire, they simply insert a new SuspiciousAccount() instance. All the other rules just have conditions like "not SuspiciousAccount()" or "SuspiciousAccount()" depending on their needs. Note that this has the advantage of allowing there to be many rules around raising suspicion, without touching the other rules. When the facts causing the SuspiciousAccount() insertion are removed, the rule engine reverts back to the normal "mode" of operation and, for instance, a rule with "not SuspiciousAccount()" may activate to flush through any interrupted transactions.
If you have followed this far, you will note that truth maintenance, like logical assertions, allows rules to behave a little like a human would, and can certainly make the rules more manageable.