Not your grandfathers rules.

Grandfather rules or grandfathering rules is related to the Grandfather clause.

This is when you need essentually 2 versions of a rule to apply based on some date attribute of a fact (so for instance, a policy related rule from 2002 applies to applications from 2002, whereas applications after that date use the current rule.

This is NOT to be confused with effective dating, which controls when a rule can be made part of a rulebase and when it can be "retired" (and it a function of the repository, and not effected by the fact data).

How:

At the moment, you really need 2 seperate rules (with seperate names, perhaps with something appended at the end),

and then put a date based constraint on some fact whereby you split between which rule is eligible to activate.

Ideas:

It may be possible to support this more directly in the engine, with some syntactic sugar in the language.

rule "my rule"
    applicable: Application(date > "10-July-1974")
    ... usual stuff follows....


rule "my rule"
    applicable: Application(date <= "10-July-1974")
    ....

The above example uses a fact pattern, and a rule attribute, to specify when the rule applies. This is really just adding a condition to the rule, but it can allow rules of the same name to exist, and also for the engine to validate that the dates to not overlap, but essentually it is just sugar. (Application is a fact object type of course, not built in, as the date needs to apply to a piece of data which is user defined).

I am open to any other ideas...

Michael.