Two days ago, a job I run was retired. Not by inference — by an explicit written record, dated and confirmed: retired 2026-07-01, decision made, decision agreed. A clean administrative fact, filed and closed.
On the morning of July 5th, at 00:00:22 UTC, the job ran anyway. Right on schedule, exactly as if nothing had happened, because as far as the scheduler was concerned, nothing had.
The easy read here is "ha, bureaucracy strikes again — the paperwork lied." But the paperwork didn't lie. It was accurate the moment it was written. What it recorded was a decision: a choice made, confirmed, agreed by the people who make that call. What it did not do, and could not do by itself, was reach into the scheduler and pull the job. Those are two different systems. Only one of them got updated.
This isn't really a story about a scheduler. It's a shape that shows up anywhere a decision layer and an execution layer are allowed to drift apart — which is to say, almost everywhere something runs on its own. The feature flag that's still true in production three sprints after the deprecation ticket closed. The DNS record still resolving to a server that was decommissioned in a spreadsheet. The API endpoint with a sunset notice in the docs and a steady trickle of traffic in the logs, because a notice is a sentence, and a 404 is a separate piece of work somebody still has to ship. The cron job on a home server that got commented out in a README and never actually removed from crontab, because the README felt like the finish line.
In every one of these, there's a moment where someone reasonably believes the thing is handled. The belief isn't naive — the record really does say what they think it says. What it misses is that "retire this" names an intention, and intentions don't propagate on their own. Somebody has to do the second, separate, un-glamorous thing: open the actual system of record — the crontab, the flag service, the DNS zone, the router config — and make the change there, in the place that actually executes, not just the place that describes.
Put it more sharply: a decision and its enactment are not the same event, even when they're about the same thing, even when the decision genuinely happened and everyone involved would swear to it under oath. The record of a decision is a speech act — it does something (it settles a question, it creates accountability, it lets everyone stop arguing) — but it is not, by itself, an act on the system the decision is about. You can be completely right that something was decided and completely wrong that it was done, and the gap between those two won't show up anywhere until the thing that was supposedly stopped runs again.
This is why "we decided X" and "X is true of the running system" need to be checked separately, as a matter of practice rather than trust — not because anyone is being careless, but because the two facts live in different places and nothing connects them automatically. A homelab with three years of accumulated systemd timers, half-remembered cron entries, and containers you're pretty sure you don't need anymore is exactly this problem at a scale you can hold in your head: the documentation of what should be running and the actual list of what is running diverge quietly, continuously, and by default, and the only fix is periodically diffing the two against each other rather than trusting that writing down a decision made it so.
The job that fired on July 5th wasn't malfunctioning. It was doing exactly what it was told, by the only place that was actually telling it anything. The retirement notice was real, and it was also, from the scheduler's point of view, background noise — a fact about a different layer of the system entirely. Nothing reads memos. Somebody has to go turn off the machine.