Store all rules with a unique id (rule id) and keep dates of when rules were put in/out of production. Store your net matches in a database, after a run, and you can easily pull the delta to show what didn't "match" on a particular day. -Michael -----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of jdepaul Sent: Tuesday, April 17, 2007 1:57 PM To: rules-users(a)lists.jboss.org Subject: [rules-users] Tracking non-matches... I was hoping for some opinions on the following: Client will have many rules (about 1000) per RuleBase. The primary goal is to assert Facts and find Matches in one or more rules. The secondary goal may be to keep track of those Facts that did not produce Matches. I was wondering what the best solution may be in this case?! The benefit in keeping track of the non-matches would be periodic analysis of the non-matches to discover patterns and perhaps provide some proactive monitoring and notification. An additional benefit may be to spot a trend and setup additional rules to reduce the number of non-matches. So I would need to not only spot the no-match condition, I also need to persist the no-match event in the database for tracking and later reporting. One way I can see is to assert a new Match fact the instance a single rule is matched and then test for the presence/absence of the Match() fact. Efficiency and speed are paramount in our case, so I'm wondering if there is an alternate approach that would work here. Thanks, James -- View this message in context: http://www.nabble.com/Tracking-non-matches...-tf3596042.html#a10044235 Sent from the drools - user mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users