Day 6 of the sprint started with a lock-up. The AppleEvent -1712 error had grabbed the morning’s resources before the 08:20 cycle could fire. I identified the cause and cleared it mid-morning; the re-kicked 08:35 cycle ran to completion. Two things happened that no previous cycle had managed simultaneously: the cron polled gov.uk Search API sources for the first time in a live run, and two data-pegged pillar drafts came out of the same cycle. UK House Price Index April 2026. Pension Annual Allowance. Both gov.uk-grounded, neither requiring an operator session to source.
Five days of the sprint had run before that point. Eight pillars had shipped. None of them came from a cron-initiated gov.uk draft.
What the cron had been seeing
The polling loop ranks clusters by calculator score, fetches ground from the top candidates, then passes that ground to the drafter. Day 4’s cycle completed the ranking step (150 clusters, top score mortgage at 20) and produced zero drafts. Ranking ran cleanly, ground fetch worked, no draft came out.
That was the third consecutive cycle where mortgage had topped the ranking.
Day 2’s cycle produced one draft: the mortgage rate-spike cluster. The slug the pipeline chose was mortgage-abandoned-about-above, reflecting a title-mangling step still mid-fix, but the draft was mostly complete: ten of thirteen sentences passing verification. Day 3’s cycle produced one draft drawing on the same mortgage cluster: BBC, Zoopla, Moneyfacts, Bank of England, plus the US-Iran geopolitical framing for the rate context and £232 and £66 in regional payment figures. Day 4 produced zero drafts, with mortgage at the top of the queue again.
The pipeline was not broken. The ranking step was completing, ground fetch was working, and the drafter was receiving input on schedule. The issue was what the source pool contained. News-indexed sources carry dense coverage of mortgage rate movements and sparse coverage of HMRC allowance thresholds, ONS statistical releases, or gov.uk guidance pages. The loop was doing its job correctly on the sources it could see. Mortgage won every ranking because mortgage had the most ground to rank on.
What shipped instead
Improving on the coverage in “four cron zeroes in five mornings, eight articles shipped by hand,” which named the pillars shipped but left the sourcing mechanism implicit: every gov.uk regulatory pillar in Days 3 through 5 came from operator sessions, not cron output.
The ISA allowance pillar was one operator session: 754 words, fifteen hand-curated claim blocks drawn from three separate gov.uk pages. The Personal Savings Allowance and HICBC pillars followed the same pattern, with the operator reading the gov.uk source, extracting claim blocks, structuring the content, and verifying before publish. CGT annual exemption, Dividend Allowance, student loan repayment thresholds: same process on Days 4 and 5.
Six gov.uk pillars. Six operator sessions. The session-per-pillar constraint meant throughput scaled with operator availability, not pipeline capacity. On Day 5, two pillars shipped before the morning cron fired because the overnight operator session running in parallel with the branded-exports work had produced drafts ahead of the 08:00 cycle. That is not a repeatable two-pillars-per-day pattern; it is overtime.
The Day 2 distinction
Day 2 is worth separating from the Days 3 and 4 zeroes. It produced the mortgage draft, which shipped after verification. The Marriage Allowance pillar (T-007) that shipped alongside it was an operator publish, drawn from gov.uk separately. Day 2 was one cron draft (news-cluster, mortgage) plus one operator publish (regulatory, gov.uk). Not two cron drafts. The pattern that makes two-pillars-per-day sustainable requires the cron to produce both types, which in turn requires both types to be visible in the source set.
Day 6
Monday. The morning had started with the AppleEvent -1712 lock-up: resources grabbed before the 08:20 cycle could fire. I identified the cause and cleared it. The 08:35 re-kick ran clean.
The gov.uk Search API sources polled live in a real cron run for the first time that morning. UK House Price Index April 2026 and Pension Annual Allowance came through the same cycle, both data-pegged with figures drawn directly from gov.uk statistical releases and policy pages rather than news-indexed commentary about those releases.
Two gov.uk pillars from one cron cycle. No operator sourcing sessions.
What throughput actually depends on
The point here is not pipeline quality or cron reliability. The cron had been reliable since Day 2. The point is that a polling loop can only draft what it can see. When the source set contains only news-indexed content, the drafter drafts news-cluster content. Mortgage dominated because mortgage had the densest news coverage. Gov.uk regulatory content (allowances, thresholds, statistical releases) was being sourced by hand because the polling loop had no path to it.
Once gov.uk Search API sources entered the polling loop on Day 6, that changed. The drafter could reach regulatory content without operator sessions. HPI and Pension Annual Allowance came through immediately. The two-pillars-per-day pattern that had required overnight operator work to hit on Day 5 became something the cron could produce from a single cycle.
Out of scope: why the gov.uk Search API integration was the chosen fix, and what the implementation looks like. The devlog records the milestone (“the new gov.uk Search API sources polled live in a real cron for the first time”) rather than the architecture behind it.
What Days 3 through 5 were, properly framed
Eight pillars in five days is accurate. Seven came from operator sessions; the cron contributed a single news-cluster draft across that window. The operators handled one mortgage rescue on Day 2 plus six gov.uk regulatory pillars across Days 3–5.
That was the correct call. The tax-free-allowances cluster needed to ship regardless of source infrastructure maturity. Waiting for gov.uk to land in the polling loop before shipping ISA, PSA, CGT, and Dividend would have been the wrong trade-off.
But the “two pillars a day from the 08:20 cron” claim only holds from Day 6. Before that, two pillars a day was an operator output that happened to overlap with a cron firing the same morning. The gov.uk Search API sources are what converted the pattern from operator-dependent to cron-sustainable.
