Rules past their date

Every system has rules that were meant to last a season: a festive override, a launch discount, a manual check added after one bad month. The reason ended. The rule did not, and nobody owns the question of whether it should.

The usual way

1. Ops, October 2024: Festive orders get 30 extra days for returns. Temporary, until the end of January.
2. February: The promotion ends. The extended window stays in ops/festive.py, because nobody was asked to remove it.
3. Twenty months later: Returns are still accepted on day 55, all year round. Finance sees the cost in the returns line and nobody can say why.

With AppThentic

Every approved rule carries a review date, set by its owner when they approve it. om lists every rule past that date.

Rules past their review date · 3

• Festive orders get 30 extra days for returns · Ops lead · due Jan 2025Stale
• Payouts above ₹5 lakh need a second approver · Priya S. · due Mar 2026Stale
• New accounts cannot withdraw for 7 days · Head of Risk · due Aug 2026Stale

1. List them. Each rule past its review date, with its owner, its reason, and what it costs today: here, returns accepted after day 30, every month of the year.
2. Ask the owner one question. “Festive returns were extended until January 2025. Keep, change or retire?”
3. Record the answer. Keep sets a new review date. Change goes through Change impact. Retire is recorded with who decided and when, and goes to the developer who owns the code.

When the owner has gone

The rule goes to whoever took over the area, with the original reason in the original owner’s words. See When someone leaves.

What leaders see

Every rule past its date, by area, with how long it has been overdue and who owns the answer.

Who uses it

Product and operations leads, and the owners of rules that were only ever meant to be temporary.