T-004 was scheduled next. Score 11 in the topic-authority backlog, NRB and RNRB explainer, the Nil-Rate Band and Residence Nil-Rate Band thresholds, the foundational numbers that determine whether an estate pays inheritance tax at all. High demand signal. Clear search gap. Good score.
Two operator-driven publishes landed on 2026-06-25. Neither was T-004.
The first shipped as the headline IHT rate. After two redraft attempts, that was what Haiku could verbatim-extract from the sources that came back. The verifier passed it. T-004’s NRB figures didn’t appear.
The second came from a different direction entirely. I asked for coverage of the government changes around council tax removal. I pulled research on Property Tax Reform 2026: mansion tax proposals, council tax admin changes, the second homes premium notice rule. A different topic, a different day’s work, same pattern: what the sources contained cleanly was what shipped.
The backlog had a plan. The verifier had authority. The verifier won.
What the backlog does
The topic-authority backlog scores content candidates. T-004 (NRB + RNRB explainer) sits at 11. T-006 (60% tax trap) is elsewhere in the queue. T-007 (Marriage Allowance). T-029 (Mortgage Guarantee Scheme 2025). Each score combines demand signal, content authority, and search gap: a ranking of what the site needs most. The design assumes the queue determines what ships next.
It doesn’t.
What the verifier actually does
The verifier is a claim-extraction pass. Haiku runs over the grounded sources and attempts to extract verified claims: statutory figures, named policy changes, attributable positions. What passes the verifier is a function of what the sources returned, not what the backlog requested.
If Haiku can’t extract sufficient verified claims on the scoped topic, the draft fails the pass. What does pass is whatever had enough extractable source material. The verifier doesn’t consult the backlog. It reads the sources and makes its own call.
This is not a bug in the verifier. It’s the verifier doing exactly what it’s designed to do. The issue is that the backlog and the verifier are not in dialogue.
The pattern across a week of publishes
The 2026-06-25 pair wasn’t isolated. The same dynamic played out across the following days.
2026-06-29: cron fired on time at 07:00 UTC. First on-schedule weekday firing in a while. Produced zero drafts. Haiku claim-extraction underperformed on the one cluster that survived the ground stage. B-076 is still unfixed. The backlog had candidates; the verifier blocked them all.
2026-06-30: I rescued a mortgage rate-spike draft from the previous cron run. It had 10 of 13 sentences passing the verifier’s claim threshold. That was enough. It shipped alongside T-007 (Marriage Allowance pillar), a fresh single-source draft that cleared the bar cleanly. Two publishes, two different verifier outcomes for two different source profiles.
2026-07-01: Personal Savings Allowance and HICBC (High Income Child Benefit Charge) pillars, both from fresh gov.uk single-source drafts. Cron on time at 08:21 BST. Two clean publishes. Day 3 of 14 in the current cadence clock.
The pattern is consistent. When the sources are specific and unambiguous, meaning a gov.uk policy page, a statutory rate, a named rule with a date, the verifier passes the draft. When the sources are diffuse or multi-claim, extraction underperforms and the draft stalls or fails.
The backlog score doesn’t appear anywhere in that sentence.
The architectural gap
The backlog scores topics by demand signal: what the site needs, what searches exist, what competitors have covered. These are real signals. The score is a genuine ranking.
The verifier approves content by extraction yield: what the sources returned, what Haiku could pull verbatim, what cleared the claim threshold. These are also real signals. The pass is a genuine gate.
They’re not connected. The backlog doesn’t know whether T-004’s NRB figures are available in the current source set. The verifier doesn’t know that T-004 was scored 11 and was supposed to be next. They run independently, and the verifier runs last.
The practical consequence: what ships is determined by the intersection of “what the backlog scheduled” and “what the sources yield”. When those sets align, the system works as designed. When they diverge, when the sources come back thin on the scoped topic but rich on something adjacent, the verifier resolves the conflict by passing what it can verify. The backlog position of the adjacent topic is irrelevant.
A structural gap, not a calibration miss
Improving on the gate-measurement analysis from a previous article: that piece documented 145 words on inheritance tax passing the gate when the topic warranted 949. The conclusion was that the gate measured the wrong thing.
That’s accurate. But it frames the problem as a calibration issue: fix the gate’s measurement criteria and the system works. The 2026-06-25 publishes suggest the gap is structural, not a calibration miss.
Even a correctly calibrated verifier, one that requires 900 words or a specific set of NRB and RNRB figures, produces the same outcome if the sources don’t yield those claims. The verifier can only pass what the extraction surfaces. If T-004’s sources return IHT rates but not NRB thresholds, a stricter gate doesn’t produce T-004 content. It produces either a failed draft or a correctly verified draft on a different sub-topic.
The gap isn’t the gate measuring wrong. The gap is the backlog scheduling topics without knowing whether the current source set can verify them.
What closes the gap
Source-extractability needs to factor into the backlog score. Not replace the demand signal. A topic with a strong search gap and a clean gov.uk single source should still score higher than a topic with a weak gap and contested multi-source coverage. But the score should reflect both.
Before a topic enters the queue at score 11, it should have a source inventory. Gov.uk pages confirmed. Claim count estimated. Haiku extraction tested in dry-run against the expected source set. If the extraction yield is low, the backlog score should reflect that, or the topic should be flagged as “source-pending” until the right source materialises.
T-007 (Marriage Allowance) passed cleanly on 2026-06-30 as a fresh single-source draft. That’s not an accident. Topics grounded in a named statutory document with a URL tend to extract cleanly. Topics grounded in “what’s in the news” tend not to.
The 2026-07-01 gov.uk pillar pair proved the model: two publishes, both clean, cron on time. Day 3/14 in the cadence clock, no stalls.
That’s what the backlog should be optimising toward: topics where the source set is known before scheduling, not topics where the verifier discovers the source quality at extraction time.
What's out of scope
Out of scope: fixing B-076 (Haiku claim-extraction underperformance under contested multi-source inputs). That’s a separate sprint. Out of scope: redesigning the backlog scoring algorithm from scratch. The demand signal is real and shouldn’t be discarded.
What this is calling out is the absence of a source-feasibility signal in the current scoring. The backlog is a wish list. The verifier is the editor. When those two disagree, the editor wins. The only way to make them agree more often is to let the wish list consult the editor before it schedules.
