Stale condition
- Industry term
A stale condition is a specific event, date, or change, written down with a saved decision or note, that says when the record needs checking again.
On the day you decide, you know which facts the decision rests on, and months later nobody remembers. A condition keeps those facts beside the decision, so whoever looks later can test one line against the present instead of rereading the note and guessing whether it still holds.
Where you’ll meet it
Your team's decision log, a shared document, says “Chose the free plan of our project tracker.” A year later the team has doubled, and the free plan's limits get in the way every week. The note gives no hint of what the choice depended on, so nobody thought to reopen it.
What to do
Add a line to that decision saying what would change it, such as “revisit if we pass ten people or the free plan drops a feature we use.” Give each new decision a line like that, and once a month ask your assistant which conditions have come true.
Easy to mix up
| Stale condition | Reminder |
|---|---|
| Yes, as part of the note's text | No, it stays in the calendar of whoever set it |
Check yourself
You save two notes about a client: what each person said on Tuesday's call, and who to send invoices to. Which one can go without a stale condition?
Go deeperSoftware calls the same problem cache invalidation
Programs that keep saved copies of data face the same question, and they answer it in two ways. An age limit marks a copy out of date after a set time, and an event, such as the source changing, marks it out of date at once. A stale condition can be either kind, written into a record that people read.
A condition works when someone can test it. “If the price goes up” can be checked against an invoice, and “if things change” cannot. A condition tied to a source, such as a policy page's version number, can be watched by a program, while vaguer ones go on a list for a person to review.