20 July. The morning cron finished with drafted=0. Five failure modes in a single cluster run: two checklist failures, one CLI failure, two articles day-capped out. uk-higher-additional-rate-taxpayers-2026-27 (HMRC projections on 7.7 million higher-rate taxpayers by 2026–27, up 34% on current figures) was sitting drafted and gate-passing. The cron hadn’t published it. I did, manually. The word I wrote in the devlog was “rescued.”
That word appears four times across thirteen days.
The rescue log
10 July: a stamp-duty cron draft and a Lifetime ISA pillar piece, recovered after a three-weekday publish gap. The gap anatomy is instructive. 7 July logged as “success-no-publish” in the cycle records: eight clusters through triage, zero articles reaching the publish step. “Success” meant the cron didn’t crash. In publication terms, it meant nothing shipped. The 14-day cadence clock was broken. It restarted from the 10th.
15 July: santander-8-percent-regular-saver-2026, rescued from a composer-failed cluster. The piece had cleared every content gate: Santander’s 8% AER Regular Saver, the rate mechanics including the variable 5.00% 12-month bonus stepping down to 3.00%. It hadn’t published because the composer hadn’t reached it, not because anything was wrong with the article.
20 July: the fiscal-drag piece, as above.
23 July: uk-house-prices-may-2026-hpi, ONS UK HPI data at 2.7% annual, rescued from checklist casualties. This was the first run that screened candidates against our own published coverage before drafting, not after. May was a new release. April gov.uk and June Lloyds held out of scope. Coverage logic right. Cadence cycle wrong.
Each of these articles had earned its place. Each needed a manual pull to ship.
The diagnosis
The queue and the schedule are the same concern in the current architecture. The cron selects a candidate, drafts it, gates it, and publishes it in a single pass. If anything in that chain fails, the pass ends. Articles ready at the start of the pass but not published don’t carry forward. They re-enter the selection buffer the next time the scorer picks them.
That design works when failure is rare and timing pressure is low. It doesn’t work when the article has a publish window. The May HPI piece had a window. The fiscal-drag projections had a window. A day-capped article that misses Monday does not become more publishable on Thursday.
The five failure modes on 20 July were independent of one another. None of them affected the draft quality of uk-higher-additional-rate-taxpayers-2026-27. They happened to occur in the same cycle, and the cycle’s output was zero. A queue that can be zeroed by infrastructure failures orthogonal to article quality is not a queue. It’s a selection buffer with a publish step bolted on.
The conflation also means the system has no vocabulary for deferral. An article either publishes or it doesn’t. There’s no state for “ready but held”. No way to distinguish a clean hold from a cycle failure. Both look the same from the outside: the article didn’t ship today.
What separation buys
Queue and schedule as separate concerns gives you three things:
- Deferral is explicit. A day-capped article is recorded as deferred, not lost. It stays at the front of the queue until the condition clears, rather than falling out of the selection buffer and reappearing when the scorer picks it up again.
- Failures are isolated. A checklist failure on one article doesn’t affect another article’s queue position. The five failure modes on 20 July would have zeroed that day’s run without altering the queue state.
- The approval gate has a stable surface. Currently, the gate operates on whatever the cron surfaces each cycle. A persistent queue gives it a deterministic input that cycle health can’t perturb.
The third point matters because the gate is already doing its job. The problem is not gate quality. It’s that the gate’s inputs depend on the cron running cleanly.
The 17 July contrast
16 and 17 July produced the first multi-day autonomous streak. Two consecutive cron cycles, each with two fully gate-passing ready drafts. The approval gate operated exactly as designed. On 17 July, the BoE hold mortgage piece and the additional-income guide both cleared the full pipeline without manual intervention: draft, then gate, then approval, then publish. “Approval gate operating as designed” means something specific. The pipeline delivered clean candidates to the gate. I reviewed and approved. Articles shipped. Human oversight intact, manual rescue absent.
17 July didn’t look different from 20 July in terms of article quality. What differed was cluster infrastructure health. On the 17th, the cycle ran clean. On the 20th, five independent failure modes hit the same run. The pipeline has no way to insulate a ready article from a bad cycle. That’s the missing layer.
Where this goes
The cadence engine earns its keep when it can defer a ready-to-ship article without losing it. “Defer without losing” requires the queue to be the durable layer and the schedule to be a reader of that layer, not its owner.
The shape is straightforward: articles move through queue states of ready, deferred, published. The schedule tick reads from ready, attempts publish, and on any failure writes deferred with a reason and a next-eligible timestamp. The article stays in the queue. The next tick picks it up.
That is what the rescue operations have been doing by hand. Each time the devlog reads “rescued from today’s cron casualties,” the manual step is performing the deferral-without-loss function the queue doesn’t have yet. The rescue is the correct behaviour. The architecture just hasn’t made it automatic.
Out of scope: the scoring algorithm that determines which ready article a given tick selects, and the cadence rules that govern publish frequency within a window. Both are separate concerns. What matters here is that a failed tick doesn’t erase queue state. Currently it does.
