The re-kicked 08:35 cycle completed on 6 July and produced ten drafts. The new gov.uk Search API sources had just been polled live in a real cron for the first time. The devlog called it “making history twice.” The second milestone was Lane B’s first data-pegged article: UK House Price Index April 2026.
Four days earlier, the 08:22 cycle had completed the full triage pass. 150 clusters ranked. Top candidate: mortgage at a score of 20. The ground step ran. Drafts produced: zero. First zero-draft firing of the sprint.
The cron was identical on both days, and so was the intention. Output moved in opposite directions. The variable that shifted was not the schedule.
The sprint’s rhythm
The 14-day pillar sprint started 30 June, Day 2. The 07:00 UTC cycle ran on time and produced one draft: the mortgage rate-spike cluster, slug mortgage-abandoned-about-above (the title-mangling step was mid-fix). 10 of 13 sentences passed the verifier gate. Day 3, the cron fired at 08:21 and produced another draft on the same cluster, reworking the identical BBC, Zoopla, Moneyfacts, and BoE source material, the same US-Iran framing, the same £232 and £66 regional figures. Not genuinely new content. The ground was the same ground.
Day 4, the cycle fired at 08:22. Triage completed cleanly. 150 clusters ranked. Then nothing. The ground-to-draft step consumed candidates and returned zero output.
The operator publish track ran in parallel throughout. Day 3 produced Personal Savings Allowance and HICBC, both fresh gov.uk single-source drafts, running alongside the cron’s mortgage variation. Day 4, with the cron at zero, CGT annual exemption shipped, then Dividend Allowance: the last two pieces completing the tax-free-allowances trilogy. Day 5, ISA allowance and student loan repayment thresholds published before the morning cron fired. The ISA piece was 754 words built from 15 hand-curated claim blocks across three gov.uk pages. That level of source curation doesn’t happen automatically. It happened because I selected the source manually before running the drafter.
The cron during this period was producing either another mortgage cluster variation or nothing. It was not the pillar-content engine the sprint needed.
What “ground-fetch quality” means in practice
Improving on the earlier observation that ground attrition is the load-bearing constraint: what the sprint made concrete is that ground quality isn’t a single variable. It splits into source coverage, source freshness, and source authority. All three need to be present for the drafter to produce anything usable.
The mortgage cluster that produced drafts on Days 2 and 3 had all three. BBC, Zoopla, Moneyfacts, Bank of England: current content, authoritative attribution, accessible pages. The cron could fetch them. The drafter had usable material.
The clusters that produced nothing on Day 4 had a different failure mode. Not missing sources, but missing good sources at fetch time. A cluster that resolves to 150-word aggregator summaries, paywalled landing pages, or JavaScript-rendered tables with no indexable content does not produce a draft. It produces silence. Triage had already ranked those clusters highly, and the fetch ran to completion. What came back was too thin to draft from.
The gov.uk Search API addressed a specific gap: official primary-source material for tax thresholds, allowances, and scheme eligibility, exactly the topics the pillar sprint was targeting. Before the API integration reached the cron, those clusters fetched whatever commercial search returned: comparison sites, HMRC-adjacent guides, summaries. After it landed, the same clusters resolved to authoritative gov.uk pages. Enough to draft from.
That’s the mechanism behind the Day 6 result. The change wasn’t scheduling, or a prompt tweak, or a verifier adjustment. It was a source-layer change.
The operator publish gap
The operator publish flow doesn’t eliminate the ground step; it curates the input before that step runs. Manual publishing means pre-screening for clusters where I already know the authoritative source exists and is reachable. The ISA allowance piece used 15 claim blocks from three specific gov.uk pages because I fetched those pages deliberately. The cron doesn’t do that. It takes the highest-ranked candidate and fetches what’s available from commercial search.
The gap between operator-publish quality and cron-draft quality is not a drafter gap. The drafter is the same component in both paths. What changes is what reaches the drafter.
Gov.uk Search API integration closed most of that gap for the categories the sprint was focused on. The PSA and HICBC articles on Day 3 were single-source gov.uk drafts, meaning even the manual path was constrained to gov.uk material. The cron, post-integration, can reach the same source tier automatically.
Day 6’s ten drafts were the first evidence of that working at scale in a single cron run.
The actual relationship between timing and output
The cron fired within a minute of its scheduled time on every day of the sprint. Output ranged from zero to ten. Timing was the one variable that didn’t move.
The sprint before this one proved scheduling is solvable. This sprint spent five of its fourteen working days demonstrating that, once scheduling is solved, source quality becomes the visible bottleneck. That’s not a planning failure. It’s the expected progression: remove one constraint, the next one surfaces.
Day 4’s zero-draft result isolated the variable cleanly. Triage ran, ranking ran, fetch ran, and the draft step returned nothing. The failure was at the fetch-to-content-quality boundary. Not what got selected. Not how it got processed. What quality of material the selection resolved to.
Day 6’s ten-draft result confirmed the diagnosis. Same pipeline, better ground, ten outputs.
Out of scope
Whether ten drafts per morning is the right throughput target is a cadence question. B2’s rules engine governs publish rate, not draft volume. The design assumption is: produce eligible drafts, publish at controlled cadence. A surplus queue is not a problem.
Which clusters fall outside the gov.uk API’s coverage, and what ground quality looks like for those categories, is a separate diagnostic. The sprint gives a directional answer on the topics it covered. A complete coverage map requires the full fourteen-day output set.
What the sprint is actually measuring
The 14-day sprint generates articles. It’s also a bounded observation window on the pipeline under real operating conditions. The articles are evidence. The constraint identification is the finding.
Going from zero to ten is not a gradient. It’s a step function that appears when the limiting factor changes layer. Source improvements behave that way; they don’t produce smooth curves. That pattern matters for sprint design: if the next sprint targets a different content category, it needs a source-quality baseline check before the first cron run, not after the first zero-draft morning.
