Have you considered making the reasons for being suspicious objects in their own right and inserting them independently? Let's say: SuspectedFraudReason (abstract parent class) TransactionsTooOften (extends SuspectedFraudReason) TransactionsTooHigh (extends SuspectedFraudReason) then indicate the reasons by inserting a new instance of an object, rather than modifying your results object. If you have rules that depend on other indicators of fraud, then they only get evaluated when that particular class of SuspectedFraudReason is inserted, rather than every time you modify the results object. At the end, you can use a query() to collect all the reasons. -- View this message in context: http://drools.46999.n3.nabble.com/Preventing-re-evaluation-on-modificatio... Sent from the Drools: User forum mailing list archive at Nabble.com.

Thanks for the feedback. Wolfgang, that's a good thought, but we do need to do some re-evaluation along the way - just not as much as we're doing right now - so the 'dirty update' approach doesn't seem applicable here. Robert, your post got me thinking. If I'm interpreting what you're saying correctly - Drools is smart enough to know which rules depend on which types of objects in their LHS, so if you modify an object of a particular type, only the rules that depend on that type get re-evaluated. It seems completely logical, but I hadn't thought about it that way. Am I understanding the mechanics correctly? If so, I think we need to re-design our 'output' fact a bit. It currently contains several lists of codes - 2 lists for the order, 1 for the buyer, and 1 for each of the recipients. It's bound to a variable in the LHS of nearly every rule and is updated in the RHS of a majority of them, which I now realize is causing nearly every rule to be re-evaluated after the firing of a majority of the rules. As a result, performance deteriorates rapidly as the number of facts grows. I'm thinking that we should put the lists of suspect codes directly into the facts that they're related to so that when a list is updated, only the rules that care about that type of fact will get re-evaluated. We'd get rid of the 'output' fact altogether and instead, after the fireAllRules() call completes, we'd iterate through all of the facts we put into the rules engine and retrieve the lists of codes from each. How does this approach sound? -- View this message in context: http://drools.46999.n3.nabble.com/Preventing-re-evaluation-on-modificatio... Sent from the Drools: User forum mailing list archive at Nabble.com.

What you wrote sounds fine. Having a sort of "root" object where List fields contain Odds and Ends, and some rules rely on Odds (but not Ends) being updated and others that don't it's not a good approach to make root a pattern in each rule. It's like information hiding: A rule working with Odds should not have access to Ends. A frequently given advice is: insert List elements as facts and reason with them if they represent independent entities. If necessary, locate siblings via a "parent" pointer. -W On 15 November 2011 14:29, Jamie <jshaw(a)llbean.com&gt; wrote: