Rules That Schedule Themselves: Effective and Expiration Dates

Most policy changes have a date attached. The new pricing starts on the first of the month. The holiday promotion ends at midnight on the third. The surcharge applies only during the quarter.

Until now, honoring a date like that meant someone remembering to flip a rule on, and someone else remembering to flip it back off. AI Rule Engine rules can now carry the date themselves.

An active window on any rule

Every rule can have an effective date, an expiration date, or both:

• The effective date is the inclusive start of the window. Before it, the rule is skipped.
• The expiration date is the exclusive end. At and after it, the rule is skipped.
• Leave either blank for “always active” or “never expires”. A rule with neither behaves exactly as it always has.

Outside its window a rule is skipped exactly like a disabled one: its condition is never evaluated and its actions never run. Nothing partial, nothing to reason about.

You enter both dates in your own time zone, with a companion time field for each and a clear button to remove one, and they are stored in UTC so a rule means the same instant to everyone on the team. An expiration that is not later than the effective date is flagged before you can save it.

Visible at a glance

Set the dates in the per-rule settings pane, from either view of the RuleSet. In the decision table, a row with a date limit shows a small calendar icon next to the rule name: one style while the rule is live, a dimmed one while it is still scheduled or already expired. Hover it for the exact dates. The rule list flags the same thing.

So a scheduled change is not hidden in a settings pane where you have to go looking for it. You can see, from the table, which rules are live today, which are waiting, and which have already retired.

Prove it works, before and after the date

A dated rule is awkward to test the ordinary way. Once the date has passed you cannot cover the “before” case, and before it arrives you cannot cover the “after” case.

Test cases now take a Run as of value: a simulated date and time for the run. Every rule’s window is judged against that instant instead of the real clock. Write one test just inside the window and one just outside it, and the pair keeps proving the rule turns on and off when it should, forever, not only on the day you wrote them. A RuleSet invoked from inside the run inherits the same simulated clock, so nested dated rules resolve consistently.

The simulated clock applies to sandboxed test runs and nothing else. A real run always uses the actual current time, so an expired rule can never be replayed by supplying a date.

Checked, not just configured

Dates are the kind of setting that goes stale quietly. The new Verify tab reads your RuleSet and reports the rules that are past their expiration and can never fire again, and the ones that are scheduled and skipped until later, so a rule that is silently doing nothing shows up as a finding rather than a mystery.

Under inference the clock is read once at the start of a run, so a rule cannot expire between passes of the same cascade.

Write the change once

The value here is simple: the change goes in when you decide it, not when you remember it. Author next quarter’s pricing today, alongside this quarter’s, with the dates that separate them. Put the promotion’s end date in when you put its start date in. Then let the RuleSet keep its own calendar.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team