The cron fired at 08:22 BST on day four. It ranked 150 clusters. The top candidate by calculator score was mortgage, at 20. Zero drafts came out.
Not a timing failure. Not a ranking failure. The ranker did its job: scored 150 clusters, surfaced the best candidate. The ground stage, which pulls authoritative source material to anchor any draft, came up empty. The pipeline ran correctly and produced nothing.
That’s day four of fourteen.
What the pipeline actually does
The morning publish cron for ukcalculators fetches candidate topics, ranks clusters by a calculator-relevance score, retrieves ground-truth source material, extracts claim blocks via Haiku, and drafts an article. The cron is the outer loop: schedule it, let it run, get content.
The scheduling part is solved. Day one fired at 07:00 UTC, the first on-schedule weekday firing in a while. Day two matched it. Days three and four came in at 08:21 and 08:22 BST. Four runs, zero timing failures. That part works.
What the firing cadence cannot address is whether the ground stage has anything publishable to work with when it runs.
What ground failure looks like
Day three produced one draft. The cluster was mortgage rate-spike, using the same BBC, Zoopla, Moneyfacts, and Bank of England sources the pipeline had drawn from the morning before. Same US-Iran geopolitical framing, £232/£66 regional payment figures unchanged. The ranker surfaced it because the score still topped the list. It was a duplicate: the ground was already spent.
Day four ranked 150 clusters. Mortgage still topped the list at 20. The ground stage failed before producing a draft.
Day one had a different failure mode. Haiku claim-extraction was underfire on the one cluster that survived the ground stage. That’s B-076, an open bug blocking the extract step. One cluster, correctly ranked, correctly grounded, and the extractor failed. Zero drafts.
Three different failure shapes across four runs. The common factor sits downstream of the ranker: the ground stage had either stale material, duplicate material, or a processing fault. The ranker surfaces the best cluster it has; it cannot surface what the ground stage cannot support.
What’s actually shipping
The cron has produced roughly one article per successful morning run, with two zero-draft mornings in the first four days. The operator path has carried the output volume:
- T-006 (60% tax trap) and T-029 (Mortgage Guarantee Scheme 2025), day one via operator path
- Rescued morning draft (10 of 13 sentences through) plus T-007 (Marriage Allowance) shipped fresh, day two
- Personal Savings Allowance and HICBC pillars, day three
- CGT annual exemption and Dividend Allowance pillars, day four
- ISA allowance (754 words, 15 hand-curated claim blocks across three gov.uk pages) and student loan repayment thresholds, day five (both published before the cron fired)
Ten articles in five days. Two from the cron. The operator path is what’s keeping pace.
The difference is not scheduling or ranking. It’s ground. The operator-path articles are anchored in gov.uk policy pages the cluster database does not yet know about. The ISA allowance article drew 15 claim blocks from three gov.uk sources. That ground does not appear in the ranker automatically; it requires knowing which gov.uk pages are canonical for each topic and pulling them explicitly.
The structural mismatch
The ranker is a relevance signal. Given a set of clusters with attached source material, it orders them by calculator-score fit. It does not know whether the top cluster’s ground has already been published, whether sources have updated since the last run, or whether a given gov.uk policy page exists and is current.
The mortgage cluster illustrates this. It scores highly because mortgage-related queries hit the ukcalculators tools hard. That score does not decay when the source material stales. The ranker will keep surfacing mortgage until the cluster is explicitly marked as recently covered or until a news event pushes fresh material into the index.
Gov.uk policy pages refresh on policy cycles, not daily. The ISA allowance for 2026–27 was published once. Student loan repayment thresholds get revised annually. CGT annual exemption is a policy-year figure that moves at budget events. These are the most reliable sources for the claim-dense, authoritative articles the site needs, and they refresh at policy cycles, not at the cron’s 24-hour interval.
That mismatch is the core constraint. The cron runs every morning. The most authoritative gov.uk ground refreshes annually or at budget events. Between those two rhythms, the ranker recirculates the same clusters until they are either explicitly exhausted or until a news event brings in fresh source material.
What two weeks have confirmed so far
The first week of the fourteen-day cadence-clock has confirmed that firing reliability is not the problem.
Draft output is gated by two things in practice:
Ground freshness. Gov.uk sources refresh on policy cycles, not daily. A cluster that topped the ranker on day two can re-top it on day three with identical material, and the cron produces either a duplicate or nothing.
Ground coverage. The operator-path articles are running ahead of the cron because they draw from gov.uk policy pages not yet in the cluster database. The ISA allowance, the Marriage Allowance, the CGT exemption, the HICBC: each one required knowing which gov.uk pages to pull. That knowledge is not yet in the ranker’s index.
The solve for ground freshness is a deduplication layer: track published clusters, age them out, do not resurface until source material has genuinely changed. The solve for ground coverage is a systematic gov.uk policy index: map each calculator to its authoritative policy pages, pull those into the cluster database, let the ranker work with a complete picture.
Neither is a scheduling problem. The cron is fine.
Where this sits
Nine days of the fourteen-day cadence-clock remain. The pattern so far: the cron fires reliably, the ranker ranks correctly, and the ground stage determines whether anything ships. On days when the ground is fresh and the extractor runs cleanly, one article comes out of the cron. On days when it is stale, duplicated, or blocked by B-076, zero come out.
The operator path is covering the gap. By mapping which gov.uk policy pages belong to each topic area, it is also producing the ground coverage data the ranker will eventually inherit. Every operator-path publish adds ground coverage the cluster database does not yet have.
The open question is not whether the cron fires on time. It does. The question is how many policy-area clusters need authoritative gov.uk ground attached before the ranker can sustain output without daily operator intervention. The remaining nine days will give that count.
