The AppleEvent -1712 had locked up system resources overnight. Monday morning, I fixed it, re-kicked the 08:35 cycle, and watched it complete. That run made history twice: it was the first time the ukcalculators pillar cron polled the gov.uk Search API live in production. To understand what that changes, you need to see the five days before it.
Days 2 through 5: what hand-curated ground looks like
The sprint started on 30 June. Day 2.
The cron fired at 07:00 UTC and produced one mostly-complete draft: a mortgage rate-spike article. Ten of thirteen sentences passed the quality gate. The title-mangling step was mid-fix. It generated the slug mortgage-abandoned-about-above. Substance was there. Rescued it, fixed the slug, published.
Day 3, 1 July. Cron at 08:21 BST. One draft: the same mortgage cluster. BBC, Zoopla, Moneyfacts, Bank of England ground; US-Iran framing; £232 and £66 regional figures. Already published the day before. Out of scope for that day’s cycle.
Two operator drafts instead: Personal Savings Allowance and the High Income Child Benefit Charge. Both sourced by hand from gov.uk pages. Claim blocks traced directly to primary-source URLs. Find the right page. Identify the claim. Link it. Repeat for each factual assertion. Deliberate. Slow.
Day 4 landed on 2 July. Cron at 08:22 BST ranked 150 clusters. Top cluster: mortgage at a score of 20. Zero drafts produced. First zero-drafts firing in the current streak.
The ground test rejected the cluster. The cron surfaced the best available candidate, ran the quality check, and produced nothing rather than a substandard draft. Two more operator publishes: CGT annual exemption and Dividend Allowance. Hand-sourced.
Day 5, 3 July. Before the morning cron fired, I published ISA allowance and student loan repayment thresholds, both drafted overnight alongside branded-exports work. ISA allowance: 754 words, 15 claim blocks across three gov.uk pages. Every factual assertion traces to a specific URL. The student loan entry follows the same structure.
Five pillars in five days. Every claim block was hand-sourced by the operator, and the pattern held at that cadence. It couldn’t scale past it.
The bottleneck hand-curation hides
“Ground” in the pipeline means the primary sources a draft is built on. For ukcalculators pillars, that means gov.uk pages: HMRC for tax thresholds, DWP for benefits rates, and similar authoritative bodies for each topic area. Each claim block links a factual assertion in the article back to one of those pages. The ISA allowance pillar has fifteen of them.
When I source claim blocks manually, I choose which pages are relevant. Domain knowledge drives that choice. I know which HMRC pages cover which thresholds, and where the Land Registry publishes house price data. Find the page, verify the figure, link it.
The cron doesn’t have that knowledge. It has the cluster (a ranked group of search queries a calculator category generates) and the cluster’s score. Until Day 6, it handed the sourcing decision to the operator every time. The cron identified what to write about; I found the sources; the claim blocks were built from those.
That split works at five pillars a week. It becomes the constraint at fifteen. The cron ranked 150 clusters on Day 4 in the time it takes me to hand-source three gov.uk pages for a single pillar. The scoring logic was not the bottleneck. The sourcing step was.
Day 6: what live polling changes
Monday 7 July. AppleEvent fix in the morning. Re-kick at 08:35. Cycle completes.
The cron polled the gov.uk Search API live. Lane B’s first data-pegged article. Two pillars published: UK House Price Index April 2026 and Pension Annual Allowance.
“Data-pegged” is the operative phrase. A data-pegged article grounds its claims in figures the pipeline retrieved at runtime, not figures the operator typed in or figures the drafter inferred from training data. The gov.uk Search API handles the fetch. It surfaces candidate primary sources for a cluster, and the pipeline runs the same ground-quality test it always has.
What moves is the sourcing decision. Instead of the operator selecting which gov.uk pages are relevant, the API surfaces them. The pipeline validates them. The claim-block discipline remains the same: every factual assertion must trace to a primary source that passed the ground test.
The zero-drafts day on 2 July frames why this holds. When the ground test rejected the mortgage cluster, that wasn’t a pipeline failure. It was the pipeline working: no draft rather than a bad one. API-sourced ground obeys the same constraint. If the API surfaces a page that doesn’t pass the ground test, the output is zero drafts. The claim-block standard doesn’t flex because the source was found by a search query rather than a person.
What stays the same
The discipline is unchanged. Every claim block in every published pillar must trace to a primary source. That includes the fifteen blocks in the ISA allowance article and the blocks the Day 6 cron built from API-polled sources. One MDX structure enforces it across all of them. A reader following any claim link arrives at the authoritative gov.uk page. True of the hand-curated pillars, and must remain true of the API-polled ones.
What changes is where the candidate source comes from. Hand-curation is precise but operator-bottlenecked. API polling is scalable but depends on what the search index surfaces for a given cluster. The claim-block layer makes the trade-off viable: if the API surfaces a source that doesn’t pass the quality check, the cron produces nothing. The operator still reviews. The drafter doesn’t fabricate.
Five pillars from hand-curation. Two from a live API poll. One discipline binding both.
Where this leaves the pipeline
Out of scope: the Lane B versus operator-publish split (the conditions that route a cluster to each path); the cadence question (how many data-pegged pillars per cycle is the right production rate); the title-mangling fix that was in progress on Day 2.
In scope: the sourcing method changed on Day 6. The discipline didn’t. Those two facts together are what the previous five days of hand-curation established without framing it that way.
The build log at docs/devlog.md has the day-by-day record from Day 2 through Day 6. This article is the pattern extracted from it.
