Thanks W. I understand your point about overusing salience -- I have read not to rely on it, but find that I pretty often "need" to order my rules. I seem to have two causes for this: a hierarchy of rules (a la, if then else); and, a number of actions I want to execute before any business rules (like adding a new SEvent object) and then again after the business rules (like removing the large event). Any recommended reading on patterns that help get away from using salience? In my case, I have many events coming in that look the same. I am looking for particular transitions on one property of the event (e.g., "when the same flavor of event comes in, and the status property changes from "On" to "Off" do something"). Additionally, I only want to execute my action on the transition from On to Off, once over a period of time (I use an object in memory to keep track of when the last action was executed.) The reason I'm explaining these details is that I think this means I need to keep the facts in order (vs. just knowing which I have and have not evaluated for the transition). For my current solution, I created a simple java class that has a method getCount(): public class XCounter { static AtomicLong count = new AtomicLong(0); public Long getCount() { return count.incrementAndGet(); } } Then, I created a function (I'm using guvnor) called addOne that checks to make sure the object above exists and creates it if it doesn't, and calls getCount(). When I create the new small event SEvent, I set a new property (xid) on the object with a call to getCount(). I compare xid's on the SEvent rather than use the "after" capability. (Similar I think to your suggestion I think but in the rules vs in the app inserting the events). This seems to work keeping everything in order, BUT I am using persistence (it is a long-running session) so I need to do some testing to see if the object/value of XCounter is persisted with WM. Otherwise, obviously if the system restarts the xid on any SEvents in memory will be out of order. Do you have any thoughts about this implementation? Thanks again, -J ps. Don't you think the drools temporal operators in stream mode should work deterministically? In other words, drools should track the order in which events were inserted so that the "after" always works - even if they are inserted during the same ms)? -- View this message in context: http://drools.46999.n3.nabble.com/Fusion-5-5-Deterministically-identifyin... Sent from the Drools: User forum mailing list archive at Nabble.com.