The cron fired at 08:22 BST on day four. 150 clusters ranked. Top candidate: mortgage, calculator score 20. Candidates fetched. Zero drafts. The first zero-drafts firing in what had been a working streak. Every stage upstream of drafting reported success. The ground stage consumed the candidates and returned nothing.
That entry sits in the build log between two days that each produced one draft and a fifth day where the operator path published twice before the morning cron even fired. Across all five days, the pattern is identical: the scheduler is reliable; the ground-and-extract stage is not.
The setup
The ukcalculators pillar pipeline runs a weekday cron (07:00–08:22 BST across the streak) that handles triage, cluster ranking, candidate fetch, ground-and-extract, and draft generation in sequence. Alongside it, an operator-publish path allows direct publication: hand-curated claim blocks sourced directly from gov.uk, bypassing the automated ground stage entirely. Both paths ran from day one, though the parallel was not designed as a diagnostic. It turned out to be one.
What the cron produced across five days
Day 1 (2026-06-29). On-schedule firing at 07:00 UTC. Zero drafts. One cluster survived the ground stage; Haiku claim-extraction failed at the extract step (B-076, already flagged, not yet fixed). The publish stage was unreached.
Day 2 (2026-06-30). One mostly-complete draft: the April mortgage rate-spike cluster. The slug the pipeline picked was mortgage-abandoned-about-above, and the title-mangling step was mid-fix. Ten of thirteen sentences passed the gate. Rescued and published after operator review.
Day 3 (2026-07-01). One draft, at 08:21 BST. Same mortgage rate-spike cluster again, grounded on the same BBC, Zoopla, Moneyfacts, and Bank of England sources, with the same US–Iran framing and the same £232/£66 regional figures. The system re-grounded material it had already surfaced the day before. The reason is straightforward: the mortgage cluster was the highest-ranking candidate that survived the ground stage. Everything else had been dropped before extract ran.
Day 4 (2026-07-02). Zero drafts, at 08:22 BST. 150 clusters ranked. Top by calculator score: mortgage at 20. Candidates fetched. The ground stage consumed them and produced nothing. The log entry stops at “ground →”.
Two usable drafts in four days. One of them re-extracted material already in the system.
What the operator path produced across five days
The five publish batches ran as follows:
- 2026-06-29: T-006 (60% tax trap) and T-029 (Mortgage Guarantee Scheme 2025)
- 2026-06-30: T-007 (Marriage Allowance) alongside the rescued cron draft
- 2026-07-01: Personal Savings Allowance and HICBC
- 2026-07-02: CGT annual exemption and Dividend Allowance, completing the tax-free-allowances trilogy
- 2026-07-03: ISA allowance (
isa-allowance-uk-explained, 754 words, 15 hand-curated claim blocks across three gov.uk pages) and student loan repayment thresholds, both published before the morning cron fired
Ten publishes in five days. The operator path sources claim blocks directly from gov.uk. It does not pass through ground-and-extract.
What hand-curation reveals about the automated path
The ISA allowance article took 15 claim blocks extracted by hand from three gov.uk pages. The process: read the source, extract the claim, write the block, verify the number. 754 words total. The material is there, it is structured, and it is extractable.
The automated ground stage is supposed to do the equivalent at scale and speed. Day four’s failure is not a scale problem. 150 clusters ranked and zero output. The candidates existed. The source material was reachable. The ground stage is the part that is supposed to surface it, and on day four it did not.
The hand path proves the material is there. The cron path proves the automated extraction cannot be relied on to reach it without indicating when it fails.
The actual bottleneck
Two failure modes are visible in the five-day log:
Silent drop at ground. Day four: 150 clusters ranked, top candidate fetched, ground stage consumes them and returns nothing. No draft-stage error. No surfaced failure. The run completes with zero output and no indication of which clusters were dropped or why. This is also the implied explanation for day three: the mortgage cluster re-appeared as the top surviving candidate because everything else had been dropped at ground before it.
Extract failure after ground. Day one: one cluster survived ground, Haiku claim-extraction failed at the extract step. B-076. The failure was flagged; the fix had not shipped by day five.
Both produce the same observable symptom: an empty draft queue. The scheduler and triage layers appear healthy in the run log. The ground-and-extract stage does not surface its failures in a form that is visible without checking that stage’s output directly.
What the parallel paths showed
If the cron had run alone, day four would read as a quiet news cycle. 150 clusters ranked, candidates surfaced, zero output, plausibly explained by thin source material or a low-activity day in the UK tax and mortgage space. The operator path running in parallel ruled that out. CGT annual exemption and Dividend Allowance both published on day four, from the same codebase, on the same machine. The source material was there. The pipeline did not reach it.
The 14-day schedule was designed with the cron as the primary publication path and operator-publish as occasional override. Five days in, that assumption is inverted. The cron provides scheduling discipline and triage signal; the operator path provides the actual volume. That is not the intended architecture, and the gap between the two paths is now legible in the build log.
What needs fixing
Ground-and-extract needs to expose its failure surface: how many clusters entered the stage, how many exited, and why the others were dropped. A run log that shows “candidates fetched” followed by zero output is not a healthy log. The silence is the bug.
B-076 (Haiku claim-extraction failing at extract) has a ticket. The silent ground drops do not. They were not visible as a pattern until the five-day log was laid out.
Out of scope here: the title-mangling fix (a separate mid-flight issue), cadence rules for the 14-day schedule (B2, not yet shipped), and whether the operator path should be formalised as the primary path until the cron reliability is resolved. Those are separate decisions.
The five devlog entries for days one through five are the primary record. This is the pattern extracted from them.
