Use Trigger Dates
Trigger dates are a useful and common way to handle rule change. They very explicitly capture the rule change event. Trigger dates, as the name suggests, require identifying a key date from which the changes must take place, and an attribute to compare this date with.
For example, where claims made before 1 June 2004 are to be assessed differently to claims received on or after that date, "1 June 2004" would be the trigger date and the attribute "date of claim" would be the base level attribute. For policy models which have not previously needed to deal with rule change, this may involve introducing a new base level attribute and populating previous saved cases with a sensible value for this attribute.
Tip: Temporal reasoning functionality allows you to extend the ability of a policy model to cope with changing rules beyond what can be achieved by hard coded trigger dates alone.
Example 1 – Add a new requirement
Previous rule:
the person is exempt from paying a late fee if
the person has been granted exemption from paying a late fee by the deciding officer
New rules:
the person is exempt from paying a late fee if
the person has been granted exemption from paying a late fee by the deciding officer
or
both
the date of assessment is on or after the 1 June 2004 policy change numbered 1003A and
the person can be considered exempt from the late fee
the date of assessment is on or after the 1 June 2004 policy change numbered 1003A if
the date of assessment >= "2004-06-01"
Note that the reason for the change should, if possible, be included in the attribute text to assist tracing the reason for the change to the source material.
Example 2 – Change existing requirements
Previous rule:
the agreement can be considered binding if
the agreement is in writing and
the agreement has been signed by the parties
New rule:
the agreement can be considered binding if
all
the 1 June 2004 legislative amendment does not apply and
the agreement is in writing and
the agreement has been signed by the parties
or
all
the 1 June 2004 legislative amendment does apply and
the agreement is in the certified form and
the agreement has been signed by persons with full authority to enter into such agreement
As far as possible, previous rules should be kept together and new rules should be kept together.
Care should be taken to avoid creating multiply proven rules with text that was in both the current and previous rules. If the attributes in both the current and previous rules have the same meaning, the attribute proof should be contained in a rule logically separate to the trigger date (that is, in a new conclusion line). If the attributes contain similar text but are now logically distinct, it may be necessary to append the attribute text with the trigger date. This includes reference tags. For example:
[Source: Section 4] the agreement can be considered binding if
all
the 1 June 2004 legislative amendment does not apply and
[Source: Section 4a] the agreement is in writing and
[Source: Section 4b] the agreement has been signed by the parties
or
all
the 1 June 2004 legislative amendment does apply and
[Source: Section 4a post 1 June 2004] the agreement is in the certified form and
[Source: Section 4b post 1 June 2004] the agreement has been signed by persons with full authority to enter into such agreement
The benefit of trigger dates is that you can have freestanding rules without needing to reproduce other policy model maintenance which may be occurring. For example, if screens were being updated to include the claimant's name on all screens or if the rules were being updated elsewhere to correct an error in the policy model, both rule sets would benefit from this change.