The cron fired at 08:22 BST on the fourth morning of the sprint. It ranked 150 clusters. Scored them. Fetched candidates. The top result was mortgage, score 20. Then it produced zero drafts and exited cleanly.
Day 3 had produced one draft on the same mortgage cluster — same sources, same BBC and Zoopla and Moneyfacts and Bank of England ground, same US-Iran rate framing, same £232/£66 regional payment figures. We’d already published that article the day before.
Zero drafts meant the pipeline had checked the ground and found nothing new to say. That’s not a bug. It’s the pipeline telling you where it’s stuck.
The four-stage architecture
Before an LLM touches anything in this pipeline, four things have to happen.
Cluster ranking picks the topic. Topics are scored by calculator signal, search volume, and recency. The highest-scoring cluster becomes the target.
Candidate fetch pulls live sources for that cluster. News articles, official pages, data releases — whatever the fetcher can reach.
Ground-truth validation asks whether the fetched material is novel relative to what’s already published. This is the gate. It checks for overlap, staleness, and coverage redundancy.
Draft generation is stage four. Sonnet drafts against validated ground.
The LLM is the last step. It has no memory of what was published yesterday unless stages one through three hand it that context. If the ground-truth check fails, nothing reaches stage four. Stale sources, an already-covered cluster, material that doesn’t pass the novelty gate: any of those and the pipeline produces zero drafts and exits.
On Day 4, the ground layer found that mortgage was done. Both the ranking step and the ground step had worked correctly. There was simply nothing to draft.
The pattern across six days
Day 2 produced one mostly-complete draft: the mortgage rate-spike cluster, 10 of 13 sentences passing, grounded in BBC and Zoopla and Moneyfacts and Bank of England sources. That draft got rescued and published. Day 3 produced one draft on the same cluster, same sources, same numbers. We didn’t publish it. Day 4 produced zero.
That progression is the pipeline tracking novelty. Day 2 was novel, Day 3 was already covered, and by Day 4 the cluster was exhausted. The right output on Day 4 was nothing.
Days 5 and 6 look different because the constraint had moved.
On Day 5 I published ISA allowance and student loan repayment thresholds before the morning cron fired, both drafted in the same overnight session. The ISA allowance piece ran to 754 words, built on 15 hand-curated claim blocks drawn from three gov.uk pages. I went to gov.uk directly, pulled the relevant sections, verified each claim against the actual legislation. The cron hadn’t found that material because it wasn’t yet connected to that part of the source corpus.
Day 6 was the first morning the gov.uk Search API polled live in a real cron cycle. The pipeline had new ground. It produced drafts. The UK House Price Index for April 2026 and the Pension Annual Allowance pillars went live, the first data-pegged articles in Lane B of the sprint.
The bottleneck
A pipeline that always produces a draft, regardless of what the ground layer returned, is optimising for volume rather than veracity. For UK Calculators, where every published claim needs a traceable official source, a draft grounded in stale or already-covered material is worse than no draft. It either publishes something redundant or creates editorial debt when the operator catches the overlap in review.
The LLM is not the constraint here. Stage four is fast. Point Sonnet at a validated prompt and it returns a draft. The ground gate is what takes work.
The constraint is stage three.
On any morning when the pipeline produces zero drafts, one of three things is true: the top-ranked cluster is already covered; the sources for that cluster haven’t updated since the last cycle; the ground fetch failed. None of those are fixable by improving Sonnet. They’re fixable by improving source coverage, tuning cluster-ranking weights, or connecting a live API where you were previously working from cached material.
What the gov.uk Search API changes
Before Day 6, the ground layer worked from sources the cron had collected through other means. On Day 5 I found the ISA allowance angle by going to gov.uk manually: 15 hand-curated claim blocks from three pages, a session-dependent and non-repeatable process. The cron couldn’t have replicated that because it wasn’t connected to the right part of the source.
Once the gov.uk Search API polled live, the pipeline had access to material that refreshes with the publication schedule of a government department. The mortgage cluster had a news-cycle lifespan and exhausted in two days. The gov.uk corpus has a different lifespan. It updates when policy changes, which is on a legislative timetable, not a news cycle. That’s a structurally different category of ground.
Day 6 made history in the sprint not because Sonnet drafted better. It was because the ground layer finally had a direct line to its primary source.
Zero drafts as a healthcheck
The correct frame: zero-draft mornings are a passing test, not a failing one.
The signal “nothing new today” from the ground layer is equivalent to tsc returning no type errors. It is the correct output for a day when the source corpus hasn’t changed. The days to watch are when it says nothing new but there was, in fact, something new on gov.uk. That’s a coverage gap, not an LLM problem.
Day 4’s zero-draft morning was honest. The cluster was exhausted; the gate held. Day 5 exposed a coverage gap: there was material on gov.uk I could find manually that the pipeline couldn’t find automatically. Day 6 started closing that gap.
Six days in, the pattern is: the pipeline produces fewer drafts per morning than I produce correctly-scoped operator publishes per day. On days when I publish two pillars manually, the cron fires once and produces one draft, or zero. That ratio isn’t a failure mode. It’s what a ground-truth-gated system looks like when it’s operating on sources that update irregularly.
The right optimisation target isn’t more drafts per morning. It’s better source coverage, so that when something new appears in the gov.uk corpus, the pipeline finds it before I find it manually. Eight days of the sprint remain to test whether it does.
