I have been experimenting with using the same set of rules for both record validation (when a completed record come to us from a 3rd party) and field validation (when the record is filled out via a web app). I don't want to have two separate sets of rule validation (twice the maintenance, twice the confusion). I have no problems with the record validation, but some issues with field validation that I would like to get input on. First - the idea for the field validation is to use Ajax to send the field contents to the server when the field looses focus, so that we can provide rapid feedback to the user if they have entered a field incorrectly. Most of the intra-field validation will take place at the end of the user input, when the form is submitted. The fact that Drools has lots of null protection was very helpful ... I could partially fill in a sub-record with the field input, submit it to the rules engine, and only those rules accessing a filled-in (non-null) field would be evaluated. I am interested in feedback on this concept. The general issue I'm having with my experiment is that not all null-security is created equal. 1) if I have a Boolean field then Drools throws an exception if the rule is based on that field and the field is null. I found a work around by testing if the field is equal to true. 2) if I have a String field then Drools throws an exception if that field is tested with 'matches'. The only work around I've come up with is to use a null-protected utility method instead of the built-in 'matches'. 3) if I have a String field then Drools throws an exception if that field is tested with 'in'. Here again, the only work around I've come up with is a utility method. Is my concept flawed from the start? Any suggestions on addressing the issues mentioned above? Any suggestions on issues I have yet to encounter? Thanks Ron