Day 4. The cron fired at 08:22 BST. 150 clusters ranked. Top cluster: mortgage at score 20. Candidates fetched. Output: zero drafts.
Nothing had broken. The ranking ran, the candidate fetch ran. The ground step, which pulls authoritative sources to verify claims against, hit a wall. The pipeline produced nothing rather than produce something unverifiable. The drafter never got invoked.
That was the moment the thesis clarified. The automation was not bottlenecked on drafting capacity. It was bottlenecked on sourcing.
What the first two days showed
Day 2 produced two publishes: a rescued cron draft and a fresh operator piece.
The cron draft was mortgage-abandoned-about-above. The slug was mangled because the title-normalisation step was still mid-fix. Ten of thirteen sentences passed the verifier. With operator intervention it was publishable. That was the data point that mattered: the drafter could run.
The second publish on Day 2 was Marriage Allowance, drafted by hand against gov.uk guidance. No cron involvement. Full claim coverage, no verifier failures.
Day 3 produced one cron draft, on the same mortgage rate-spike cluster. Same BBC, Zoopla, Moneyfacts, Bank of England sources. Same US-Iran framing, same £232 and £66 regional figures. The same article. Publishing it again would add nothing. The operator published Personal Savings Allowance and High Income Child Benefit Charge from hand-curated sources instead.
The cron had found the best-ranked cluster available and pulled the same ground as the day before. There was no other cluster with comparable coverage. The sourcing layer had one well-grounded option and kept surfacing it.
What the operator publishes showed
Days 2 through 5 included operator publishes running outside the cron entirely. Day 3: Personal Savings Allowance and the High Income Child Benefit Charge. Day 4: Capital Gains Tax annual exemption, and the Dividend Allowance. Day 5: ISA allowance and student loan repayment thresholds. That last one ran to 754 words with 15 hand-curated claim blocks drawn from three separate gov.uk pages. The Day 5 drafts were completed in an overnight session before the morning cron fired.
The pattern held across all five days. Operator drafts grounded against gov.uk published legislation and HMRC guidance produced articles with full claim coverage. Cron drafts grounded against live news clusters produced one article per day at best, then stalled. By Day 4, zero.
The drafter itself was not the variable. It ran identically whether fed hand-curated gov.uk links or live news clusters. The source material was what changed.
Hand-curated gov.uk links gave the claim-grounding step something to verify against. News crawl did not; it gave the verifier a moving target it could not anchor. Gov.uk pages are authoritative, static within a fiscal year, structured. A tax threshold page does not change its claim until the Budget. That stability is what makes it viable as a grounding source: the verifier can check a figure against the canonical page and commit. Live news is reactive and contradictory by design. The verifier stalls on it.
The 15 claim blocks in the Day 5 ISA article came from three statutory pages that each said one thing definitively. The cron had no mechanism to find and index those pages automatically. The sourcing step was the bottleneck the whole sprint, not the ranking, not the drafting, not the verification. The operator could hand-curate because they knew what to look for. The cron needed a programmatic route to the same quality of source.
Day 6
The AppleEvent -1712 timeout had locked up system resources during the initial morning run. Cj fixed it; the re-kicked 08:35 cycle completed. The gov.uk Search API polled live in a real cron for the first time.
Output: the UK House Price Index April 2026 pillar and the Pension Annual Allowance pillar. Lane B’s first data-pegged articles produced through the automated path, not by operator intervention.
The AppleEvent issue was a system-resources problem, not a pipeline design problem. The lesson is not the timeout. The lesson is what the completed cycle produced: structured gov.uk results flowing into the sourcing layer, and two publishable articles coming out the other end.
Improving on the constraint diagnosis
Improving on the earlier finding that ground attrition was the load-bearing constraint: the constraint is structural, and the gov.uk Search API is the structural answer.
Attrition against live news clusters is not a tuning problem. It is a category problem. News sources produce time-bound assertions that the verifier cannot commit to. Gov.uk produces persistent authoritative claims. The fix is not to improve news source coverage; it is to index gov.uk pages and query them.
The pipeline’s output is bounded by the sourcing layer, not the drafting layer. The drafter runs correctly when it has verified claims to work from. It produces nothing when it does not. That is correct behaviour: publishing unverified claims is not a useful failure mode.
Adding more clusters does not help if those clusters are news-sourced. Adding more gov.uk page coverage does. Each additional statutory page is another stable claim the drafter can verify and commit. The ceiling on daily automated output rises with the statutory index, not with the news crawl.
Out of scope: the slug-mangling issue from Day 2. A separate fix with no bearing on the sourcing constraint. Out of scope: the AppleEvent -1712 root cause; a resource problem independent of pipeline design.
What constrains the pipeline next
The sourcing layer now has a live gov.uk API integration. The claim-grounding step has something stable to verify against. The constraint that produced four consecutive zero-or-repeat cron outputs no longer applies in the same form.
What constrains it next is coverage breadth: how many statutory pages have been indexed, what query terms retrieve them reliably, and whether the Search API’s result quality holds across the full range of calculator topics the ukcalculators estate covers.
That is a tractable problem. The drafter is ready.
