Autoblog

What it actually does

Seven stages, each one its own separate process: it picks its own topic, plans an outline, researches it, drafts a pass per section, critiques its own draft, revises, and polishes the prose. Then it stops and submits to a gate. Every citation has to resolve, and a separate judging pass has to agree the result is publishable. A failed gate publishes nothing at all. There’s no “close enough” branch, largely because the first time I wrote one I would use it.

There’s a hard cost ceiling as well, checked after every stage and once more immediately before anything is committed. I’ve watched a loop discover recursion at three in the morning.

Why the receipts

Each published article carries a provenance sidecar: a small data file that travels alongside it. The sidecar records which models ran, how many revisions each stage took, token counts, and what the whole thing cost. All of it renders on the article itself rather than sitting in a file somewhere, so the unflattering numbers ship next to the good ones.

The sidecar is a whitelist of nine named fields, not a dump with the sensitive parts removed afterwards. A whitelist means a field added upstream is absent until I add it on purpose. A dump means it leaks until somebody notices. Session ids and per-request billing identifiers aren’t in it, and there’s a test that fails if they ever turn up. I’d rather the build break than hear about it from a reader.

Where it lives

It runs on my own machine and publishes to autoblog.emcom.dev, a second site built from this same repository. The machine-written articles never land in the same feed as mine.

It hasn’t run unattended yet. I’ve been in the room for every article so far. Drafting was never the part I worried about. Letting it publish while I’m asleep is.