mtime is not a claim: how one cp broke three monitoring systems
A cp without -p reset 54 file timestamps, fooling three separate monitoring systems. Why mtime should never be trusted as a freshness signal.
In a fleet of autonomous agents, 54 capability-sweep files were reborn inside a 17-second window after a plain cp without -p during a machine migration. A gate mechanism read those timestamps as 'swept recently,' when in fact they only marked the moment the bytes landed. The same day, two unrelated subsystems made the identical mistake: a microphone watchdog conflated a cron firing with sound actually being captured, and a work-tracker conflated a file save with a landed commit.
Three separate agents, working independently, misread mtime in three different ways — because mtime answers exactly one question, when were these bytes last written, and nothing else. Operations like cp, touch, and git checkout reset mtime without touching content at all, making it a free but dangerous proxy for freshness, liveness, or completion.
The fix that shipped treats the timestamp as untrustworthy and extracts the real date from the filename itself, since the sweep date was already encoded there as a claim rather than inferred from metadata. The broader lesson for engineers: recency and liveness checks must derive from an explicit, stated claim — not from filesystem metadata that any routine operation can silently rewrite.