The cron fired at 08:22 BST on 2 July. It ranked 150 candidate clusters. Mortgage topped the ranking with a score of 20. Candidates fetched. Zero drafts.
That was the first zero-draft firing in the current streak. Two days earlier, the same mortgage cluster had produced a mostly-complete draft: 10 of 13 sentences passing the verifier. A day after that, the cron produced one more draft from the same cluster: same BBC, Zoopla, Moneyfacts and Bank of England ground, US–Iran framing, the same £232 and £66 regional affordability figures. On 2 July, mortgage came first again. This time nothing passed. No draft.
That was correct.
What changed at the input layer
Improving on the earlier sprint that established the verifier as the pipeline’s real editorial gate, the question this work addressed was more fundamental: what is the verifier actually checking against?
The early pipeline verified draft sentences against news article sentences. A sentence passed if it matched the tone and substance of the news source. The problem was that a fabricated figure could match a plausible news sentence: both sounded correct, neither was grounded in anything authoritative. The verifier was checking against the wrong thing.
The fix moved upstream. Before the drafter runs, the pipeline now fetches gov.uk pages relevant to the calculator’s topic and extracts hand-curated claim blocks: specific factual assertions from official sources. The verifier then checks draft sentences against those blocks, not against the news article. A sentence passes if a gov.uk claim backs it. If nothing backs it, it fails.
What a claim-block grounded pillar looks like
The ISA allowance pillar, published on 3 July as a pre-cron operator publish, ran against 15 claim blocks drawn from three gov.uk pages. 754 words. Every specific figure in the article traces back to one of those 15 assertions.
That is architecturally different from the earlier pipeline. In the earlier version, a figure might appear because the news article contained it, or because the drafter inferred it from context. In the claim-block version, if a figure appears in the draft and no claim block backs it, the verifier rejects the sentence. The figure either comes from gov.uk or it does not appear.
Why zero drafts follows from that
The mortgage cluster’s sources are news-primary: rate movements, lender behaviour, affordability commentary. HMRC does not publish live mortgage rate tables. The BoE publishes base rate decisions, but those are not the calculator-content type the ukcalculators pipeline targets. When the drafter tried to produce sentences about mortgage rates grounded in gov.uk claims, there were not enough. Zero sentences cleared the bar. Zero draft.
Day 3 had shown the same signal from a different angle. The cron produced one more mortgage draft: same sources, same framing, the same £232 and £66 regional figures. Without claim blocks that require a gov.uk anchor, the pipeline would keep producing mortgage content day-on-day as long as the news cluster stayed active. The claim-block requirement made that impossible: no gov.uk blocks, no draft.
The slug the pipeline generated for the Day 2 mortgage draft was ‘mortgage-abandoned-about-above’. That is a separate problem. The title-mangling step was mid-fix during that run. Slug normalisation is out of scope here.
What happens on zero-draft days
The operator fills the gap. On 2 July, the CGT annual exemption pillar and the Dividend Allowance pillar were published as operator publishes, completing the tax-free-allowances trilogy alongside the Personal Savings Allowance from the day before. Two articles shipped. The cron produced none of them.
The pattern across Days 2–5 was consistent: cron produced mortgage drafts from the same news cluster, diminishing returns each day; operator published gov.uk-grounded pillars by hand: PSA and HICBC on Day 3, CGT annual exemption and Dividend Allowance on Day 4, ISA allowance and student loan repayment thresholds on Day 5. When the cron could not pass the mortgage cluster through the claim-block gate on Day 4, it produced nothing rather than another recycled news-primary draft. That is the gate working.
Day six: the mechanism in production
6 July was the first day the gov.uk Search API polled live inside a real cron cycle. The morning run had locked up earlier with AppleEvent -1712, system resources held from the overnight session. I identified and cleared the cause manually. The cron re-kicked at 08:35. When it completed, two data-pegged pillars came out: UK House Price Index April 2026 and the Pension Annual Allowance, Lane B’s first data-pegged articles.
Both were grounded in gov.uk data the API had returned in the same cycle. The figures in the published articles came from the same source the pipeline fetched that morning. Fetch → claim blocks → verified sentences → published pillar. The AppleEvent timeout was a launchd resource-management issue, separate from the claim-block architecture and not what made Day 6 significant. What made Day 6 significant was that the mechanism ran end-to-end in production for the first time.
What five days of data show
Day 2 (30 June): one mostly-complete mortgage draft, 10 of 13 sentences passing. Day 3 (1 July): one more mortgage draft, same sources, signal that news-only ground recycles. Day 4 (2 July): zero cron drafts, two operator publishes with gov.uk backing. Day 5 (3 July): 15 claim blocks, 754 words, pre-cron operator publish. Day 6 (6 July): gov.uk API live in production, two data-pegged pillars after the AppleEvent fix.
The right metric is not cron drafts per day. It is claim-backed sentences per published article. A day with zero cron output and two clean gov.uk-grounded operator publishes beats a day with two mortgage drafts that each need sentences struck for fabrication.
Day 4’s zero-draft cron is not evidence the pipeline is broken. The gate is calibrated correctly. The pipeline could have produced a draft. It would have failed the verifier or shipped fabricated figures. It produced nothing instead. That is the design working.
