Day 4. The cron fired at 08:22 BST. It ranked 150 clusters, pulled the top candidate — mortgage rate-spike, calculator score 20 — fetched the ground, and exited clean. No errors. No failures. No output.
That was the second zero-draft day in five. The logs looked identical to a successful run.
The week at a glance
Eight pillars published across five days, all operator path except one:
- T-006 (60% tax trap) — Day 1
- T-029 (Mortgage Guarantee Scheme 2025) — Day 1
- Marriage Allowance — Day 2, from a rescued cron draft
- Personal Savings Allowance — Day 3
- High Income Child Benefit Charge — Day 3
- CGT annual exemption — Day 4
- Dividend Allowance — Day 4
- ISA allowance + student loan repayment thresholds — Day 5
The cron’s contribution across five days: one draft worth publishing (Day 2, the mortgage rate-spike piece, slug mortgage-abandoned-about-above — the title-mangling step is mid-fix — with 10 of 13 sentences passing the quality check) and one draft on ground already covered (Day 3, the same rate-spike cluster, materially the same BBC/Zoopla/Moneyfacts/BoE sources, the £232/£66 regional figures unchanged, US-Iran framing swapped in as the news hook). Day 1 was a zero-draft day with B-076 still open. Day 4 was a zero-draft day with the triage completing correctly and the top candidate simply not providing enough source density.
Six of the eight pillars came off manual operator work. The pipeline was not broken. Haiku correctly produced nothing when the extraction step couldn’t build enough claims from what was there.
Where the earlier diagnosis stopped
Improving on the quality-gate finding in the inheritance tax piece — where 145 words shipped because the gate was measuring the wrong thing and 949 words was the correct target — this sprint exposed the stage upstream of that gate entirely.
The gate problem is downstream of drafting: an article was produced, passed a miscalibrated check, and went out too short. The fix is recalibrating the gate.
The extraction problem is upstream of drafting. No article is produced at all. The gate never fires. Haiku reaches the fetched gov.uk content, finds fewer viable claims than the drafting threshold requires, and returns empty. The pipeline logs a clean exit. Nothing ships until the operator steps in.
These are two distinct failure modes at different pipeline stages. They can co-exist in the same sprint, as they did here: the gate issue surfaced on the inheritance tax piece, the extraction issue produced five days of partial or zero-draft cron output across the tax-free-allowances and mortgage clusters. Fixing the gate is necessary but not sufficient. The extraction bottleneck was always present; the sprint made it the binding constraint.
What thin ground looks like in practice
The ISA allowance article illustrates the extraction job at full load. Three gov.uk pages, fifteen claim blocks hand-curated, 754 words drafted off those blocks. The claims required finding and cross-referencing: the £20,000 annual allowance, per-type sub-limits, age and residency conditions, transfer rules. Each one sourced, each one structured. That work took time. The drafting, once the blocks were in place, was fast.
Day 4’s zero-draft had the opposite source structure. The top mortgage cluster had a calculator score of 20 — high topic relevance — but the fetched gov.uk ground was a rates page covering a single threshold figure. Haiku extracted what was there. It wasn’t enough to build a viable claim set, so nothing went to the drafter.
Thin ground, specifically: a gov.uk page covering a single metric, no worked examples, no adjacent guidance that unpacks the statutory implications for different taxpayer profiles. The ISA article needed three pages and fifteen blocks. The mortgage rate cluster had the structural equivalent of one block’s worth of primary source. That asymmetry is why calculator score and ground quality are different signals, and why the pipeline needs to measure both separately.
The diagnosis the sprint produced
Claim extraction is the bottleneck, not drafting. Specifically: Haiku extraction underperforms when the fetched gov.uk ground is structurally sparse, and the current pipeline dispatches extraction without first measuring whether the ground justifies it.
The open ticket is B-076. The fix it points toward is a pre-extraction density check: measure the token volume and structural density of the fetched ground before dispatching Haiku, and route clusters below the threshold to a manual augmentation queue rather than firing extraction on thin material and returning a zero-draft result that looks clean in the logs.
The triage step already ranks by calculator score. It does not account for ground quality. A mortgage rate-spike cluster scoring 20 is correctly identified as high-priority for topic relevance. It says nothing about whether the fetched source material has enough structure to support automated claim extraction. Those are orthogonal signals. The pipeline currently uses topic score as a proxy for extraction viability.
That proxy fails in exactly the conditions this sprint produced: high-relevance topics on thin regulatory ground, where the gov.uk page is authoritative but sparse.
Cadence implications
Two operator-path pillars per day is workable for a 14-day sprint on queued gov.uk topics. It is a full context switch per article. At two per day that’s ten working decisions across the sprint’s first week, all of them requiring source location, claim extraction, structure decisions, and editorial review.
The cron path, when it works, is a different shape entirely: triage fires at 06:00, draft lands before the working day starts, editorial review at lunch, publish in the afternoon. One light working session versus two focused hours per article. Day 2’s published piece demonstrated that shape. The gap between it and the six operator-path pieces is precisely ground density.
B-076 and a pre-extraction density gate would close that gap for the majority of the remaining queue. Some clusters will always need operator augmentation — single-metric topics without enough adjacent gov.uk coverage to support an automated claim set. The pipeline should identify those explicitly and route them to a manual queue rather than producing silent zero-draft results.
Out of scope
This sprint is not fixing B-076; it’s producing the diagnosis. The automated cron-to-publish flow is the target state, not the current sprint’s deliverable.
The Day 3 duplicate-ground issue — the cron returning a draft on a cluster already covered by yesterday’s published piece — is a separate gap: deduplication in the candidate selection step, not the extraction stage. It’s noted. It is not the same problem.
