Guide · New to this

A status page said "running" for six days after the work had stopped

Each update of a status page started from the last one, so the word "running" was copied forward for six days after two computations had stopped. Check the real state before you repeat a status word.

I'm Tyler Orden, an independent researcher who does mathematics with AI agents. My research record is at Cyborg Mathematics.

If you keep a status document at work, you probably update it by opening last week's version and changing what you know has changed. Everything you did not touch stays as it was, including statuses that are no longer true. If you ask an AI to draft the update from last week's version, it does the same thing: it can only repeat what that version says. AI agents that pick up work from their own notes, session after session, inherit stale status the same way.

So before you send a status update, go through each item marked "in progress", "on track" or "running" and confirm it from the source: the ticket, the person doing the work, or the system it runs on. "It still exists" is not enough. Check that it is still moving, for example when its output or the ticket last changed.

For teams: the owner of the status page re-checks every status word at each update, on the day of the update, and writes beside it who checked and when. An AI or a teammate can carry numbers forward from the last version; a status word like "running" or "on track" gets repeated only after that day's check.

Before you update a status page

Here is last week's status update and this week's notes. Before drafting the new update, list every item marked running, in progress or on track. For each one, show me the current evidence that it is still moving (a date it last changed, a message, a system reading) or mark it UNCONFIRMED. Do not repeat any status from last week without new evidence.

Here is how I learned it. In my research project, Claude, an AI agent, runs long computations and keeps a status page listing each piece of work and where it stands. In early September two long computer searches were running, each trying to beat a best-known value that mathematicians have published. Both had the same stopping rule: if a full day passes with no improvement, stop.

On September 5 both stopped under that rule, without beating the published values, which is what the plan had said was most likely. Nothing wrote the stops into the project's records.

The failures that followed were the updates. On September 6 and again on September 7, Claude updated the status page, starting each time from the previous version, and both times it copied forward "running to Sep 10" without checking. I was reading the page too. On September 9 I complained that it was hard to read and full of stale to-do items, and my complaint did not mention the "running" line. September 10, the page's own end date for both searches, came and went. On September 11, when Claude picked the project back up, it checked the computer's own list of running programs and each search's progress log, instead of the page, and found both searches had stopped six days earlier.

The project now has two rules for this. Every long computation gets a small watcher program that writes the stop into the project log the moment it happens. (If you build one, have it record why the program stopped as well as when.) And before any update repeats the word "running", it checks the computer's list of running programs. The same copying kept an old rule of mine on the page for two more updates after I changed it, so rule changes now get the same treatment: every copy of the old wording is replaced the same day.

For specialists: one search looked for a [99, 20] linear code over a five-letter alphabet with a larger minimum distance than any in the public tables of best-known codes; the other looked for a cyclic four-coloring of the edges of a complete graph that would raise the lower bound on the Ramsey number R(3,4,4,4). Neither beat the published value before its stopping rule ended it.