Currenty timer initialisation is not defined very well and rules don't obey salience, which can make them harder to use. Agenda interaction and scheduling: 1) Rule activations are added to the agenda like any other rule. 2) When the rule is popped from the agenda, instead executing the RHS the timir started is started. 3) Each time the timer is triggered the rule is added to the agenda and continues to obey salience. This time when the rule is popped from the agenda it executes the consequence. Fact modification behaviour: Modify on scheduled rules currently retriggers the initial delay, if that's 0 it can cause the rule to refire straight away, which I believe never wanted. 1) If the timer expression does not used any modified fields, it should not be re-scheduled. 2) Reschedule should be done for the repeat period only, we shoud not trigger another delay. 3) The first time it is scheduled after the period has changed it should subtract the amount for time difference left over from the last period. For those that want timer rules to fire independant of the agenda, we will probably add an annotation to specify the rule is not to be handled via the agenda. This will give behaviour roughly to what we have now. One reason why this change is important is with the upcoming algorithm change for lazy rete. We need to use the agenda and rule priorities to determine when to evaluate rules. Any rules not handled by the agenda will have to be left eager, so there are significant performance gains from this, as well as userbility gains from having timer rules that still obey salience. Mark