--- On Thu, 8/21/08, thomas kukofka <thomaskukofka(a)web.de&gt; wrote: I'm not sure what is reasonable in your case, but if it's a simple test it might be better handled outside of business logic rules. (i.e. a GUI controller, which might be rules based itself, but you should segregate rules that handle business logic from those that handle other requirements) In those cases you certainly should not create the dependent output objects before hand. :) Lazy initialization is usually only warranted if creating the resource is costly or time consuming. (DB connections, high memory/cpu usage, things like that) Back to the original issue, it's not all that odd to have two rules in your case. There are two distinct phases: you haven't started gathering results, and you're in the process of gathering results. It makes sense that you'd have two rules to govern that. Also, if you have rules down the line that test for the existence/nonexistence of OutputObject, then you should create it conditionally. But, basically, having two rules for this kind of thing is not at all bad or odd. As a side note to the dev team: this would be a great use case for an "else" clause. Having that would collapse these two rules into one: rule "all-in-one rule" when "condition" A: oo: OutputObject() then #do something with the object update(oo); else-A OutputObject oo = new OutputObject(); insert(oo); end