When uncertain about lifespan, expire at 3 months not 1…
Err toward shorter expiration windows when uncertain about information lifespan, setting expiration at 3 months if unsure rather than 1 year, because expired items can be renewed while accumulated stale information cannot be easily detected.
Why This Is a Rule
The costs of too-short and too-long expiration windows are asymmetric. A too-short expiration (item expires while still valid) triggers a review: you see the expiration notice, check whether the information is still current, and either renew it (30 seconds) or confirm it's genuinely expired (useful). A too-long expiration (item becomes stale before expiring) produces silent corruption: you unknowingly use outdated information, make decisions on wrong data, or share obsolete references — and you never receive a signal that anything is wrong.
The asymmetry makes the heuristic clear: when uncertain, choose the option whose failure mode is visible and cheap (too-short: triggers a review) rather than the option whose failure mode is invisible and expensive (too-long: stale data silently corrupts decisions). This is the same logic behind conservative engineering safety factors: better to over-inspect than to under-inspect, because the cost of inspection is known and bounded while the cost of undetected failure is unknown and potentially catastrophic.
The 3-month default for uncertain items is chosen because most business and technical information has a shelf life of 3-12 months. Pricing changes quarterly, software updates monthly to quarterly, organizational decisions shift quarterly. Defaulting to 3 months catches most staleness within one quarter while requiring only quarterly renewal effort for items that remain valid longer.
When This Fires
- When assigning an expiration date (Tag time-sensitive information with explicit expiration…) and unsure about the information's lifespan
- When debating between "it might last a year" and "it might last three months"
- When building default expiration policies for categories of information
- Complements Tag time-sensitive information with explicit expiration… (expiration at capture) with the decision heuristic for uncertain cases
Common Failure Mode
Optimistic expiration: "This is probably valid for at least a year, so I'll set expiration to December." But "probably" means you're uncertain, and uncertain + long expiration = high risk of silent staleness. The item quietly becomes outdated by April, but the expiration flag won't surface it until December — 8 months of potential stale-information harm.
The Protocol
(1) When assigning an expiration date, ask: "Am I confident about this information's lifespan?" (2) If confident → set expiration to the known end-of-validity date. (3) If uncertain → default to 3 months from today. This triggers a review in 3 months where you'll reassess with fresh information. (4) When the 3-month expiration triggers, you have three options: Renew (information is still valid → set new expiration 3-6 months out), Update (information has changed → update the content and set new expiration), Archive (information is genuinely expired → remove from active system). (5) Track renewal rates: if you're renewing the same items every 3 months repeatedly, consider extending their default expiration to 6 months. If items frequently expire as genuinely stale at 3 months, your default is well-calibrated.