The cron ran at 07:00 UTC on the 30th of June. It produced one draft: a mortgage rate-spike article grounded in April 2026 data from BBC, Zoopla, Moneyfacts, and the Bank of England, with a US-Iran geopolitical framing the sources had been running since April. The slug the pipeline chose was mortgage-abandoned-about-above, a collision artefact from a title-mangling step still mid-fix.
Ten of thirteen sentences passed the verifier. Three didn’t. The article published on ten.
That ratio is the story.
What the verifier is checking
The pipeline grounds drafts in source material fetched at generation time. Each sentence is supposed to be traceable to a cited outlet. The verifier’s job is to check the link holds: that the claim in the sentence matches what the source actually says, at the figures the source actually reports, with the framing the source currently carries.
The failure mode isn’t fabrication. Fabrication is the grounding step’s problem: a sentence that invents a figure with no source gets caught earlier. The verifier’s failure mode is drift. A sentence that was accurate when the source was fetched, but the source has since been updated. Or the model smoothed the figure at generation. Or the framing the source used six weeks ago no longer applies.
Three sentences in the June 30th draft failed that check. The devlog doesn’t record which ones. What it records is that they didn’t publish.
What publishing those three would have cost
The UK Calculators site isn’t a news feed. It’s a library of pillar pages: standing documents targeting specific high-traffic queries about tax thresholds, mortgage affordability, allowance limits. A pillar page doesn’t have a 24-hour news cycle. It accumulates traffic and backlinks across months. A drifted claim on a mortgage affordability page compounds. A figure out by a few hundred pounds, or a rate statement that no longer reflects the BoE’s current position, accumulates impressions across months.
Corrections are possible but expensive: the page needs to be re-indexed, the claim needs to be re-sourced, and anyone who’s already cached the wrong figure has already cached it. The verifier catches drift before it reaches that stage. That’s its only job.
Three sentences caught at draft time is operationally cheap. Three sentences caught by a reader after indexing is not.
Why the same article appeared the next day
Tuesday the 1st of July, cron fires at 08:21 BST. Output: one draft. The same mortgage rate-spike cluster: same BBC and Zoopla and Moneyfacts and BoE ground, same US-Iran framing, same regional figures. The same article.
This is where deduplication does work the verifier doesn’t. The verifier is operating at sentence level: does this claim hold against its cited source? Dedup is operating at cluster level: has this source material already produced a published article? The two checks are asking different questions.
A draft can pass the sentence verifier with all thirteen sentences correct, and still be wrong to publish if the ground hasn’t moved since yesterday’s article. The dedup layer checks provenance, not content. The Day 3 draft didn’t publish.
Day 4: zero drafts
Wednesday the 2nd of July. Cron fires at 08:22 BST. Output: zero drafts.
The triage step completed. 150 clusters ranked; top by calculator score was mortgage at 20. Candidates fetched. But the ground hadn’t moved. The pipeline identified the top cluster, fetched the source material, and produced nothing. The staleness check stopped the process before a draft was even attempted.
Zero drafts on a stale-ground day is better than one draft repeating the same article for the third time. The gate operated one step earlier than on Day 3, because the problem was one step earlier: the inputs hadn’t changed, so the output shouldn’t either.
This was the first zero-drafts firing in the current sprint streak. It wasn’t a failure. It was the pipeline correctly recognising when not to publish.
Three gates, three scopes
The June 30th to July 2nd sequence ran through all three layers of the quality gate:
- Sentence verifier. Does each claim hold against its source at time of publication? Operates on draft content. Day 2: caught three sentences.
- Dedup. Has this source cluster already produced a published article? Operates on provenance. Day 3: caught the whole draft.
- Staleness check. Has the source material moved enough to justify a new draft? Operates on inputs, before drafting begins. Day 4: produced zero drafts.
Each layer has a different operating range. Without all three, the failure modes are: drifted claims publish (Day 2 without verifier), the same article publishes twice (Day 3 without dedup), and a draft cycle burns on unchanged ground (Day 4 without staleness check).
The layers don’t overlap. They cover different failure modes at different stages of the same pipeline.
What the name reveals
mortgage-abandoned-about-above is going to get fixed. The title-mangling step is mid-fix. The slug is a symptom of an implementation detail that’s already in the queue.
The article still published on Day 2 despite it. The slug broke the URL aesthetics. It didn’t break the content. The verifier doesn’t check slugs, and it shouldn’t: slug normalisation is a different problem, a different gate, a different sprint. The verifier checks what can break a pillar page, and wrong slugs break permalinks, not facts. That distinction is the scope discipline the pipeline runs on.
What comes next
Day 6 is live. The gov.uk Search API sources polled in a real cron for the first time on Day 6/14: two operational firsts in the same cycle. The pipeline is building an operating history: which clusters rank persistently, which sources update fast enough to warrant re-drafting, how the verifier rejection rate varies by source quality.
The June 30th draft is one data point. Ten sentences published, three caught. The open question is whether that ratio holds as the sprint moves away from well-covered news clusters (four major sources, clear news peg, high signal) toward thinner material where the grounding is weaker and the drift is harder to catch.
If the verifier rejection rate climbs on thinner clusters, that’s useful data. It tells you where the grounding step needs more source coverage, or where the verifier needs a tighter threshold. The gate measuring what it should is the prerequisite for improving anything else. The sprint is collecting that data now.
