Steve,

     I think you may be unintentionally combining two different things together.  I find it is easier to look at the code itself, so here is an excerpt from syslog_mgr.asl:

    /* Hook adapter actions.  Send attributes.
     ----------------------------------------- */
    persistentAdapter->setVariable("SYSLOGTIME", syslogTime) ? LOG, IGNORE;
    persistentAdapter->setVariable("HOST", host) ? LOG, IGNORE;
    persistentAdapter->setVariable("APPLICATION_NAME", applicationName) ? LOG, IGNORE;
    persistentAdapter->setVariable("PROCESS_ID", string(process_id)) ? LOG, IGNORE;
    persistentAdapter->setVariable("MESSAGE", message) ? LOG, IGNORE;
    persistentAdapter->setVariable("debug", string(debug)) ? LOG, IGNORE;
    persistentAdapter->start() ? LOG;

    /* Retrieve 'modified' ICS_Notification attributes.
     -------------------------------------------------- */
    discard = persistentAdapter->getVariable("DISCARD") ? IGNORE;

    if ( discard == "TRUE" ) {
      return;
    }

    The adapter calls the hook script and first is expecting to see the variable "DISCARD" set to a Boolean value.  If set, the data is thrown away and we move to the next line of the logfile.

    When you say "filter", I am assuming you mean the filter keyword in ASL.  The purpose of the filter is actually to selectively run the action block of a particular rule.  You *could* use that to selectively run the action block in which you set the "DISCARD" variable, but the filter expressions can only get so complicated before they become unreadable.  It is usually better to put the conditionals into the action block itself.

So:

RULE {

    blah:word eol

} filter {

    blah == "TEST"

} do {

...

}

is equivalent to:

RULE {

    blah:word eol

} do {

    if (blah == "TEST") {

       ...

    }

}