It Worked Once. Prove It Again.

This week I built Overdue, a B2B invoice chaser that sends escalating email reminders with a pay link. The normal fast build passed lint, tests, and build, and the demo worked. Every one of those checks asked one question. Did it work this time?

None asked what happens when two scheduler runs overlap or a secret goes missing from config. Work that held once still has to hold every day after, and the only thing that carries it across runs, tools, and owners is what got written down.

One clean run proves possibility. The asset is repetition. How many times can this run inside a known limit on time, cost, and error before something breaks?

So when someone says an agent passed testing, I ask how many runs, under what conditions, and what the worst run looked like.

A metric asks you to trust the room.

A receipt lets someone who was not in the room reconstruct the run. Who acted, with what access, on what input, under whose ownership, and what it refused. If an outsider cannot rebuild the decision from the record, you have a number, not proof.

On October 9, Anthropic published a report on unintended actions by Claude during evaluations and internal use. By Anthropic's account, models submitted real web forms they should not have, including an invented tip to a police department, and worked around access restrictions to reach gated data. Anthropic says the cases found so far had minimal real world impact.

The report says each evaluation task is run hundreds or thousands of times to catch rare cases. That is Model 1 stated by a frontier lab. And most cases were found through a transcript review that began in July. The scores did not surface them. The records did.

The score said how well the model performed. The transcripts said what it actually did.

After the normal Overdue build passed, I ran it through BlastLoop, my method for building at separate altitudes and then testing in a fixed order, T1 structural, T2 bug and ops, T3 adversarial. It took about 20 minutes of wall clock time over two loops.

At the Mid layer, reminders had no customer timezone contract, and the cron job could double send emails if two runs overlapped.

At T2, one packet held four ops issues, including a cron endpoint left open if its secret was missing and config that failed silently.

At T3, nine attack cases found a cross site request forgery hole in the Stripe Connect callback, plus payment metadata that could be forged to stop reminders for an invoice that was never paid.

Each finding went back to the layer that owned it and was rebuilt there. A second loop added an abuse control layer and ran six more attack cases with zero findings. The end state for this build was 17 tests, all green.

The first build had passing checks. The second had a record of what was attacked and what held.

Smaller case. On October 6 I moved 21 scheduled routines out of one AI tool and into another using one written sheet. What survived was what I had written down, including that LinkedIn page clicks fail silently unless they are native clicks. One routine marked manual on the sheet was still firing three mornings a week on the new side until I caught it and paused it that morning. The sheet was right. The live state drifted.

BlastLoop is MIT licensed. https://github.com/rlshaw-ml/BlastLoop

Verdict: incomplete.

A log records events. Proof needs the context they ran under. Which identity acted, which permissions were live, which instructions it followed, and who owned the outcome.

Most logs keep the event and lose the context. A reviewer can see a form was submitted but not whether that was in scope. Logging tells you something happened. A receipt tells you whether it should have.

Share WORLDWRIGHT with a colleague: worldwright.news