Thanks for the reply, Wolfgang. If I understand your scenario correctly, I think you are describing the expected activation patterns during the firing of this rule. I agree with your description, and our logs show something very similar. Responding to your specific suggestions - 1. The data model is a given - we have no control over it. 2. No-loop true is used on all our rules, including this one. In the example, I had removed rule attributes for brevity. 3. Unfortunately, the data semantics are also not under our control, and the rule has to test all these objects in order to work right. Further diagnosis indicates that what looked like multi-activated rules are actually not all the same rule instance, even though their content is the same - the log4j appender being used was improperly trimming the ends of the distinguishing identifiers when it logged them. However, although these rules are different instances of the rule, their conditions are identical, so I'm still puzzled why a set of conditions that are not met in the data will lead to an activation / deactivation. I'm going to have to dig deeper, I guess. Thanks. Tom Murphy Business Process Consultant Wells Fargo HCFG - CORE Deal Decisioning Platform 800 S. Jordan Creek Parkway | West Des Moines, IA 50266 MAC: X2301-01B Office: 515 324 4853 | Mobile: 941 320 8014 This message may contain confidential and/or privileged information.  If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein.  If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.  Thank you for your cooperation. Date: Tue, 1 Sep 2009 08:04:46 +0200 From: Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; Subject: Re: [rules-users] Why so many ACTIVATION/DEACTIVATION events? To: Rules Users List <rules-users(a)lists.jboss.org&gt; Message-ID: <17de7ee80908312304y52499c00m88f3a45c6b225825(a)mail.gmail.com&gt; Content-Type: text/plain; charset="windows-1252" Hi Tom, your understanding of "Activation" is fine, so let's see what happens if your rule "RS..." fires. (I'm abbreviating names.) Initially, neither PolSet nor PolSetId are there, so "RS..." activation #1 is on the agenda, fires and executes the consequence. Now, PolSet is created and inserted as a new fact. This causes reevaluation of all rules, including "RS..." (with its activation #1 still executing). The not(PolSet and PolSetId) is still true, and therefore the LHS yields true, and "RS..." activation #2 is put on the agenda. Continuing with #1, PolSetId is created and inserted, causing reevaluations of all rules. Now the not(PolSet and PolSetId) is false, so that "RS..." #2 is removed again. As for a remedy, you might consider several approaches. Notice that I have to guess what else might be going on, so I could be way off with (3), for instance. (1) Is it really necessary to have PolSet and PolSetId as two separate facts? (It might still be possible to have PolSet as an *object* for establishing linkage to the parental TransDet, without being a *fact*.) (2) Add the rule attribute no-loop true to "RS..." (3) If the absences of PolSetId alone is sufficient for triggering the rule(s), omit PolSet from rule "RS..." and add another rule which creates the "missing link" when you have a TransDet, the existence of at least one PolSetId and no matching PolSet, to create the latter. Cheers -W 2009/9/1 <Tom.E.Murphy(a)wellsfargo.com&gt;