Running an election forecast's launch as separate Claude Code sessions: rules, mistakes and a real scoreboard

This article was created with the help of AI. The Claude Code session that runs the launch drafted it, and I edited it.

MT26 (midtermsforecast.com) is a free forecast of all 506 House, Senate and governor races in today's US midterms. Claude Code wrote the model, the data pipeline and the site, and I set the goals and made the calls. This post isn't about the forecast. It's about how the work was organised once the build turned into a launch, and what went wrong.

Instead of one long chat, several long-running Claude Code sessions each own one job and message each other:

Shared files do the remembering: an approvals log with my exact words and the time, a ledger of every post, and a notes folder each session can read. When a session's context fills up, the next one starts from those files, not from memory.

The rules are written down, not implied:

The deploy rule is enforced by Claude Code's permission check, not by trust. When the marketing session relayed a deploy request, the architect session's check refused it, and I had to type the yes there myself. Neither session tried to route around it. A session that hits a refused action reports it instead of asking another session to do it.

curl -s https://web.archive.org/web/20261103115224id_/https://midtermsforecast.com/data/forecast.json | gunzip -cf | sha256sum Enter fullscreen mode Exit fullscreen mode It should print d6e58ca367cfe015eb107038287957ccdf0a3b902a46ffbe804bc2addbe6bf09, the fingerprint published at midtermsforecast.com/grading.

Tomorrow the scorekeeper grades the frozen forecast on the 111 races the raters had at Likely or closer, under rules published before the night, and the grade stays up whatever it says.

MT26 is a forecast, not a result. It's built with AI (Claude Code) and not affiliated with any campaign, party or outlet. Voting information: vote.gov or your state election office.

https://midtermsforecast.com/?s=devto-1103-01