another good link, that makes it understandable.

it looks like a "one-to-one" port of existing drools rules is problematic. Drools has a way for you to veto a rule firing, it also can allow us to skip rule groups. It looks like the equivalent involves just ensuring proper behavior by writing appropriate when clauses. I do like how using a defrecord to predicate on is simple.

i suppose the "clara way" to control groups would be to modify the productions --- add predicate(s)

i'm getting infinite loops: (defrule has-email "allow rule" [User (= "<mailto:[email protected]|[email protected]>" email)] [:not [Decision (contains? #{:allow} type)]] => (insert! (->Decision :allow)) (println "allowed")) (defrule has-email-deny "deny if not allowed" [:not [Decision (contains? #{:allow :deny} type)]] => (insert! (->Decision :deny)) (println "denied")) trying to make "allow" take precedence over "deny" decisions, but either my "contains" or universal non-existence seems to not be working.

Regarding looking at fired rules, the idiomatic way to get output from the session would usually be to have facts that represent that output and query on those facts. The tracing listener will tell you what rules fired, but it will also include rules that were later retracted. The API guarantees are generally around the final state of the session, not what rules are fired on the way there. It's possible to design rules in a way that constrains this, but this has to be done carefully and wouldn't be my first approach to solving a given problem. The tracing listener is primarily intended for debugging and performance problem diagnosis.