The Loop, Part 6: The Manual — Running the Machine

Every machine needs a manual, and a machine that files a report on itself every six hours can afford to publish its own. This is the operator's manual for the loop — the care-and-feeding document, written for whoever wakes the box up six months from now and asks the only question that matters: is it lying to me right now? The earlier parts of this series explained what the machine thinks. This one covers how to run it, repair it, and catch it when it fibs.

• Part 1 — The Clock (the machine): /articles/the-loop-part-1-the-clock
• Part 2 — The Ledger (the predictions): /articles/the-loop-part-2-the-ledger
• Part 3 — The Rules (the card): /articles/the-loop-part-3-the-rules
• Part 4 — The Teaser Engine (the pricing error): /articles/the-loop-part-4-the-teaser-engine
• Part 5 — The Gates (the trading rules): /articles/the-loop-part-5-the-gates

Reading the machine's mind

What it looks like: four readings, in order of freshness. A heartbeat block rewritten after every tick — last run, tick count, each station's status. An append-only tick ledger going back to day one; eighty-one ticks at time of writing, every one accounted for. The daily wager sheet and the nightly recap — the machine's public statements, which is where its opinions can be checked against its grades. And the prediction ledger itself: one CSV, 29 columns, 199 rows, append-only once settled. An operator who reads those four files knows everything the machine knows. One design rule guards the ledger's integrity: the column list lives in exactly one module, and the settlement phase imports it. Two copies of a schema drift silently; one copy cannot.

The belt, in order

What it looks like: nineteen stations, and the order is the architecture — fetch schedules, standings, lines, and injuries first; build teaser cards and prediction rows second; audit third, while the raw snapshots are still warm; then news, the trading gates, market compares, settlement, the recap, the sheet, and the article drafts. Each station returns one of three words — ok, skipped, or failed — plus a sentence a human can read. A failure never stops the belt. The odds scrape dying at station five is recorded at station five, and the predictions at station eight proceed with the market columns honestly blank rather than quietly stale. The slowest station is the browser-driven odds scrape at 30 to 60 seconds; a full tick takes about two minutes.

The daily rhythm

What it looks like: nothing. That is the point. A tick lands every six hours; the sheet and recap write themselves; settlement grades the night's games on its own. The human's entire job is the four-file reading above, plus two decisions the machine is never allowed to make: which drafted articles earn an edit and a publish, and whether any carded ticket deserves real money. Everything the loop writes down is a suggestion with a paper trail. When settlement misses something — a game the snapshots never saw, a standings window that closed — the web interface has grading buttons, and every manual grade carries its reason in the row itself. A grade without a reason is a mood; with one, it is an audit trail.

The weekly rhythm

What it looks like: one command on Wednesday, before the Sunday slate. The survivor pipeline pulls the schedule, scores, lines, and public ownership, runs the equity engine, and writes the brief the site publishes in this series' voice. One standing trap, learned the hard way: the calendar week and the data week are different weeks. The early-October slate is week 4 in the data even when a casual count says 5, and a popular ownership website always displays whichever week is current — so if its matchups do not match the slate, its percentages are for some other Sunday. Verify the week against the schedule file before trusting a single ownership number.

The catch-up procedure

What it looks like: the machine's known blind spot, stated plainly. The schedule snapshot freezes at fetch time. If the laptop sleeps through game time, the past date's snapshot never sees a final score, and settlement has nothing to grade from — the backlog grows while nobody is watching. The recovery is deliberate, not clever: refetch the past date's snapshot with finals, run settlement, then regenerate that date's sheet and recap. Do it serialized after any running tick, because two processes rewriting one CSV is how ledgers get mangled. The structural fix — settlement refetching unfinal past dates on its own — remains on the list, and the manual says so, because a manual that hides known gaps is marketing.

Failure modes, tuition already paid

What it looks like: a shortlist of named errors, which is the only kind worth keeping.

• The stale process. The worst incident in the system's history: a long-running daemon held old code in memory while the ledger's schema changed on disk, crashed mid-write, and truncated the prediction file. Twenty-three rows lost. The rule now, no exceptions: after any code or schema change, restart everything that runs before the next real tick.
• The vanished browser. When the odds scrape fails two ticks running, the cause is usually not the website — it is the automation browser's binary disappearing after a silent version bump. One reinstall command; verified green in a minute.
• The ban. One odds-consensus source temp-bans bursts: six rapid requests cost an hour of 403s. The phase now makes one polite request per tick and treats a failure as data the next tick picks up.
• The wrong year. A consensus parser returning zero results looked like a broken schema for a day. It was a probe asking last year's schedule what today's games were. Check the date before the code.
• The reboot. The daemon does not survive restarts. This is a known, stated limitation with a known fix pending — and it is in the manual precisely because an honest limitation ages better than a silent one.

The boundaries

What they are: five lines the machine will not cross, in writing. The upstream archive is read-only — consume its engines, never modify its reports. Nothing publishes itself; a human's hand is on every deploy. No new third-party dependencies without a human's signature. No database server; files and public APIs only. And the loop informs wagers — it never places them. These are not features. They are the load-bearing walls, and Part 1's promise that nothing publishes itself is enforced here, at the manual level, where an operator can check it.

Why publish a manual at all

Because the scorecard is the quality of logged decisions, and a manual is a logged decision about how the machine gets operated. Articles one through five argued the process works. This one is the process admitting where it breaks, how it gets repaired, and exactly which mistakes it already made — so the next operator's tuition is prepaid and the machine's next failure is a row in a ledger, not a mystery.

Keep the manual next to the machine. Read the heartbeat before the picks.