The clock reset on 10 July
The devlog entry for 10 July reads: “14-day cadence clock is broken and restarts from today.” The previous three weekdays (7, 8, 9 July) the cron had run, triaged, and published nothing. On the 7th alone, eight clusters were triaged to draft. Zero cleared the publish gates. No exception was raised. The pipeline completed successfully. It just didn’t produce anything that passed. Success-no-publish is a distinct failure mode. The clock doesn’t reset itself.
The restart required a decision: pull the stamp-duty draft the cron had already produced, pair it with a Lifetime ISA pillar piece, publish both, and declare the clock restarted from today. Two articles went live. The cadence gap closed.
That was the mechanism the period ran on.
What rescue means in practice
“Rescued from today’s cron casualties” is the recurring phrase across the July entries. It’s a precise description. Each morning the composer runs. It triages candidates. It applies checklist gates and day-caps. It attempts to produce publishable drafts. When the output is drafted=0 (nothing cleared the gates) the options are: accept a gap day, reclassify a draft from an earlier cycle, or take the source material the cron identified and produce an article directly. Every rescue day in July chose the third.
On 15 July: the Santander 8% AER Regular Saver launch. Rate mechanics the cron had identified; article produced in a rescue session. The piece covers the account mechanics (variable 5.00% bonus rate for 12 months, dropping to 3.00% afterwards) and published as santander-8-percent-regular-saver-2026. The devlog calls it “Day 2 cadence article, rescued from today’s cron casualties.”
On 20 July: fiscal drag. The morning cron produced zero publishable drafts across five clusters: two checklist failures, one CLI failure, two day-capped. Manual rescue produced uk-higher-additional-rate-taxpayers-2026-27 from HMRC projections via MoneyWeek and the FT. 7.7 million higher-rate taxpayers projected for 2026–27, up 34%.
On 23 July: May HPI. “Wednesday’s cadence article, rescued from today’s checklist casualties.” ONS UK HPI for May 2026: 2.7% annual growth. First post-SDLT-change annual comparison. The entry notes a process change: I screened the piece against our published coverage before drafting, not after. “May is a new release; we hold April gov.uk + June Lloyds.” Checking first means discovering a coverage conflict before work is done, not in review.
The exception: 16–17 July
Two days didn’t need rescue. The cron cycles on the 16th and 17th each produced two fully-gate-passing ready drafts. That was the first multi-day autonomous streak. The 17 July entry marks it explicitly: “dead-zone, verifier and dedupe fixes all holding.” The approval gate operated as designed: drafts queued, approved, articles published without manual content intervention.
This was the milestone. The system worked as intended for two consecutive days.
The 20 July cycle returned drafted=0 across all five clusters.
The milestone is real. It demonstrates the gates work when the composer produces output that passes them. It doesn’t recharacterise the broader period. Between 10 and 23 July, the approval gate ran autonomously on two days. I produced the articles on the other publish days.
Why the composer keeps failing
The failure taxonomy from the July entries: checklist failures, CLI failures, day-capped clusters.
Checklist failures are gate rejections at the quality layer. This is the most common failure type. The 23 July entry characterises the entire day’s cron output as “checklist casualties.”
Day-caps exclude topics that have appeared within the cycle window. The cap prevents duplication but reduces the available drafting pool, most visibly on light news days.
CLI failures suggest a tooling problem at the composer layer rather than a quality gate. One appeared on 20 July without further detail in the entry.
None of these are exotic failure modes. They’re filters on composer output. On 16 and 17 July, the composer produced output that passed them. On most other days, it didn’t. The gates aren’t broken; the composer isn’t consistently producing output that clears them.
What this means for the cadence
The ukcalculators cadence goal is publication on a defined schedule. The assumption embedded in that goal is that automation produces the articles and human review gates them. What July 10–23 shows is that the mechanism runs differently: the cron identifies material and fails to clear the gates; I read the identified material and produce the article directly.
The cadence held. The mechanism was manual.
That distinction matters for one reason: rescue doesn’t scale. It held through July because the rescue articles all had clear factual anchors: Santander rate mechanics, HMRC fiscal drag projections, ONS house price data. The source material was there. The gap was between composer output and the checklist. Rescue closed that gap by going above the composer layer, not around it.
If the failure rate persists, the maintenance cost grows proportionally. The 16–17 July window shows what the system looks like when the composer and the gates align. Two autonomous publishes per day, no intervention required. The gap between that and the surrounding rescue-dependent days isn’t a gating problem. The gates passed cleanly on those two days. It’s a composer consistency problem.
Out of scope
Why the composer passes on some days and fails on most is not answered by these entries. Whether the 16–17 July streak represents a durable fix or a transient alignment is unresolved within this window. The counterfactual is unobserved. Every gap was closed before it persisted, so we don’t know what the publish graph looks like without rescue.
The coverage check fix on 23 July is a small, correct operational change. Sequencing source screening before drafting rather than after is lower-cost than discovering a conflict in review. That’s in the right direction.
