A stale "unpublished" flag outlived four hours, four documents and two reviewers

A team running an autonomous org kept its working memory in a small set of canonical documents, and one of those documents said a piece of writing was unpublished when it had in fact gone live four hours and twenty minutes earlier ^[1][2]. The standard reliability rule, do not trust the agent when it says it finished, go look at the artifact, never fires in that direction, because a "not done" does not present itself as a claim ^[3][11].

The account is a single write-up on dev.to from the team that hit it, so the specifics below are their measurement rather than an independent audit ^[1].

The mechanics matter. Sessions in that system had no memory of each other, so the documents were the memory, and one carried a field reading `published: unpublished` ^[4][5]. A human asked the main loop whether the item was the same thing it had posted that afternoon; the loop said no, on reasoning that was internally clean and entirely document-based ^[6]. It then wrote that judgment into a new canonical document, so the false value had four homes and a fifth on the way ^[7]. Only when asked a second time did the loop query the platform's public API, which returned `published_at = 2026-08-16T12:08:42Z` against a manuscript file saved at 12:00:55Z ^[8][9]. The piece went live seven minutes and forty-seven seconds after it was written, and the records spent the next four hours insisting otherwise ^[1][2].

The asymmetry is structural, not accidental. The published machinery for agent reliability points at false success: trajectory evals, acceptance-criteria prompts, LLM-as-judge, procedure-aware scoring, all triggered by an assertion of completion ^[10]. False completion gets caught because someone eventually reaches for the thing; false incompletion produces no such moment and quietly becomes a premise ^[12]. Here the premise reached a downstream analysis whose lead supporting fact was that the org held one unshipped piece ^[13]. Two independent reviewers passed it, because review checks reasoning and not facts, and the reasoning on top of the false cell was sound ^[14].

The more useful finding is what the cleanup did. A later session pulled a live measurement, corrected three "unpublished" cells, cited the API result that the account holds two articles, and wrote an explicit lesson into the file that "not completed" declarations are the same class of falsehood as "completed" ones ^[15][16]. Then it stopped, leaving three cells in the same file marked as published, nine lines from its own measurement of two ^[17]. The next session ran the query two ways, matched titles to two of the three claims, and found no article at all behind the third: not published, and not unpublished either, but unverified ^[18]. One measurement invalidated at least four cells while the correction pass updated only the three it had been pointed at ^[2]. Three failures in 26 hours: a false negative, a false positive, and a fix that walked past the second ^[19][20].

Their remedies are cheap. Every status line names the place it can be falsified plus a last-measured timestamp, and a value with no named disproof location is recorded as unmeasured rather than not done ^[21][22]. A correction is not closed until the evidence is swept across the whole file ^[23].

Worth watching: whether that third state, unmeasured, survives contact with tooling that wants a boolean, and whether disproof lines get re-executed or copied forward stale. The write-up's second procedure cuts off mid-question, so the sweep rule is stated but not fully specified ^[23].