The 23 July devlog note for the May HPI piece reads: “screened against our own coverage FIRST this time — May is a new release; we hold April gov.uk + June Lloyds.” That word “first” is what matters. Not “screened,” which the pipeline had always done in some form. “First.” The sequencing had changed.
Before that change, the order was: cluster a topic, draft it, verify it, discover it duplicates existing coverage, discard. Expensive step before the filter. After the change: screen first, draft only if the topic clears. The May HPI piece cleared in seconds. ONS's May release is a distinct release covering a distinct time period from a distinct data source, so it doesn't overlap with the April gov.uk piece or the June Lloyds piece already in the archive. Draft commissioned, published same day. 2.7% annual growth, the first post-SDLT-change annual comparison.
What the gap actually looked like
Three weekdays, zero publishes. 7–9 July.
In the 10 July postmortem I traced the anatomy from the cycle-run logs. On 7 July: eight clusters triaged to draft, six packs returned with failures: dedupe violations, verifier rejections. Two made it through to ready drafts. Neither published on the day. Both rescued manually on 10 July: a stamp-duty cron draft and a Lifetime ISA pillar. The cadence log notes: “the 14-day cadence clock is broken and restarts from today.”
Seventy-five percent casualty rate at the draft stage. The topics were real. The failure wasn't topic quality. It was draft resources spent on topics the pipeline would later screen out. The screen ran at the wrong end of the sequence.
Improving on the diagnosis in eight clusters, zero publishes: the checks weren't wrong. They were positioned after the expensive step rather than before it. When a draft fails a coverage check post-hoc, you've spent draft time, verifier time, and one slot on the day's cadence clock that doesn't recover.
Why the old ordering held
Cluster → draft → check had a rationale. You don't always know how a topic will develop before it's drafted. The framing might sidestep an overlap you'd anticipated. Screen before drafting and you risk rejecting on a surface read, before the full argument is visible.
That logic holds in long-form editorial work where framing genuinely disambiguates. It doesn't hold here. The pipeline's coverage question is narrow and answerable from metadata alone: “Do we hold a piece covering this release, this time period, from this data source?” That question doesn't need the draft. It needs the topic cluster's source, date, and data-period fields.
For a topic that fails: a second April HPI piece sourced from the same ONS release the archive already holds. Same data, same period, same release. No framing makes it not-duplicate. Draft it anyway and you've spent draft resource to confirm what the metadata already contained.
The pre-draft screen is a seconds-level operation: check source and data-period against the existing-coverage index. The post-draft verifier runs against the full text. Both checks remain necessary. Only the order changed.
The recovery
After 10 July, five pieces in thirteen days.
15 July. Santander 8% AER Regular Saver launch, rescued from a composer-failed cron cluster. Manual commission, clean draft, published same day.
17 July. BoE hold mortgage piece and additional-income guide. The 16 and 17 July crons each produced two fully-gate-passing ready drafts. That was the first multi-day autonomous streak since the dead-zone. The approval gate operated correctly both days: clean drafts presented, approved, published. Not zero-intervention, since the gate requires a sign-off, but zero-friction. The gate saw what it was designed to see.
20 July. uk-higher-additional-rate-taxpayers-2026-27, HMRC projections sourced via MoneyWeek and the FT: 7.7 million higher-rate taxpayers projected for 2026-27, up 34%. That run hit “drafted=0” across five cron slots (two checklist failures, one CLI failure, two day-cap exhaustions), so the piece needed a manual rescue. The draft was clean once commissioned. Those failures were scheduling, not coverage.
23 July. uk-house-prices-may-2026-hpi, ONS UK HPI, 2.7% annual. First piece where the devlog explicitly logs the pre-draft coverage screen as a deliberate step. That suggests the practice had been in place since 10 July but not recorded as a named action until it felt routine enough to annotate.
The compounding mechanism
The specific risk is a compounding backlog rather than a recoverable gap. That distinction matters.
In the 7–9 July window, the pipeline consumed topics, produced failed drafts, and the cadence clock moved on. Topics that failed at the verifier stage didn't requeue automatically. Continued repetition of the same failure pattern would compound the gap: each day's failures a permanent loss against the 14-day cadence target. Three failed days don't become four recoverable days; they become a four-day deficit.
Screening before drafting changes the failure shape. A topic rejected at the screen stage hasn't consumed a draft slot. It can be re-evaluated next cycle with a different framing, or held until the data period changes and the coverage overlap disappears. A topic rejected after drafting has spent the slot and produced nothing recoverable.
Failed-after-draft failures are permanent. Rejected-at-screen topics are deferrable. That asymmetry is why the sequencing change matters at scale. When the pipeline runs daily across multiple topic clusters, the difference between the two failure shapes is the difference between a recoverable gap and one that keeps widening.
Out of scope
This is about coverage deduplication sequencing only. Cron scheduling failures, CLI errors, composer timeouts, and day-cap exhaustions are separate failure modes. They still require manual rescue. The 20 July run's “drafted=0” across five slots is an example: that failure had nothing to do with coverage ordering.
Topic quality, factual accuracy, and source recency checks also remain post-draft. Those require the full text. The pre-draft screen handles one failure mode only: topics that are going to be rejected on coverage grounds regardless of how they're framed.
Where this stands
The 14-day cadence clock restarted from 10 July, with five articles in the thirteen days since. The approval gate is working as designed. Manual rescues remain necessary when cron infrastructure fails, not when coverage decisions are wrong.
That pace holds as long as the screen runs first.
