Document begins

The state machinery

Two pieces of automation ran for the life of the campaign. Both were reasonable ideas. Both failed in ways worth publishing, because they are the failures every small group’s automation has and nobody writes down.

1. The state synthesiser

A script read the project’s issues and stream documents and generated a short summary: what is known, what is missing, what is most urgent. The idea was that anyone — human or agent — could open one file and know where things stood.

Here is the entire generated summary, as it stood on 19 May 2026:

What we know

• No FACT-labelled items found in current stream docs.
• Property listing status: unknown (last checked: 2026-05-19)

What we’re missing

• No open decision-needed issues. All known blockers resolved.

Most urgent item

• Issue #18 — Title search via Land Tasmania. Owner: unassigned.

Three things about that.

It was already wrong when it was generated. “No FACT-labelled items found in current stream docs” was false — the source register had ten, the title search had produced several, and the property status check was full of them. The synthesiser was looking for a label format that the documents had stopped using. It reported the absence of evidence as an absence of facts.

“All known blockers resolved” is the most dangerous sentence the project ever generated. It was produced on a day when the legal structure was undecided, the licensing pathway was unconfirmed, no valuation existed, and the building had never been inspected. It meant “no GitHub issue is currently tagged decision-needed”, which is a fact about issue labels, not about the world. Rendered in plain English into a file called current-state.md, it read as an all-clear.

It froze. That file was never regenerated. The summary above sat there, dated 19 May, for the remaining three months of the campaign — through the listing, the sprint, the deadline and the loss.

The failure is not that the automation broke. It is that it produced a confident summary of a proxy and named the file after the thing it was a proxy for.

2. The property watch

The second piece is sharper, and it is the one worth learning from.

The group wanted to know the moment the pub went on the market. So it wrote a watcher: a daily automated check against a property portal, appending one row a day to a log — date, status, source, notes.

It ran 91 times, from 20 May to 18 August 2026.

The property was listed for sale on 12 June 2026. The watcher’s entry for 12 June reads unchanged. So does 13 June, and 14 June, and every day after.

Why it said “unchanged”

Not a bug. The watcher queried realestate.com.au — Australia’s residential property portal — through a third-party API, searching the suburb and filtering for hotels.

The listing was published on commercialrealestate.com.au, the commercial portal, by a commercial agency, as an expressions-of-interest campaign.

The watcher was answering the question “has anything changed on the residential portal?” — correctly, every day, for three months. The group had asked it, in their heads, “is the pub for sale yet?”

Those are different questions, and the log format hid the difference perfectly. A column that says unchanged looks identical whether it means “I checked thoroughly and nothing happened” or “I checked somewhere the answer could never appear.”

The project’s own property status check — done by hand, in May — had listed nine separate portals and brokers to check, including the commercial one. The automation implemented one of them and inherited none of that breadth.

And then it degraded quietly

Thirty-five of the 91 runs returned error — all sources failed to return content. From early July the errors run in long unbroken stretches; the final six weeks of the campaign are almost entirely errors.

Nobody noticed, because nothing was watching the watcher. The failure was faithfully logged into a file that nobody had a reason to open, in a format where failure and success look the same at a glance. An error rate of 38% over three months is not a monitor; it is a file that grows.

What this cost

Very little, in the end — the group heard about the listing the ordinary way, from people. That is the honest accounting, and it is also the point. The automation contributed nothing to the single most time-critical piece of information in the entire campaign, while appearing on every status review as a box that was ticked.

What to take from it

Four things, and they generalise past this project:

1. Name the file after what it actually measures. current-state.md should have been open-issues-summary.md. The gap between the name and the content is where the false confidence lives.
2. A monitor that has never fired has not been tested. Ninety-one unchanged rows and zero changed rows should have prompted the question “would this even be able to tell me?” long before it mattered. Test the alarm by triggering it deliberately.
3. Errors must be louder than successes. A 38% failure rate that appears as one more row in a table is invisible. It needed to interrupt someone.
4. Automating one of nine checks does not automate the check. The manual method was broader than the automated one that replaced it, which is the usual direction of this mistake.

There is a fifth, which is the reason this page exists rather than being quietly dropped from the archive: the automation’s log was honest. Every failure is in the record, dated, in the group’s own files. It was possible to write this page three months later, precisely because the machine wrote down what it did rather than what it was hoping to do.