The 08:21 BST cron on day three of the fourteen-day run produced one draft. Cluster: mortgage rate-spike. The verifier passed it.
That cluster had already shipped the morning before.
The day-two draft had a slightly awkward provenance. The slug the pipeline chose was mortgage-abandoned-about-above, with the title-mangling step still mid-fix at the time. The content stood up. Ten of thirteen sentences passed verification against source outlets: BBC, Zoopla, Moneyfacts, Bank of England. US-Iran framing on the rate environment, £232 and £66 regional repayment figures, the standard BoE base-rate chain. Sufficient ground, sufficient sourcing. It published.
Day three: the cron returned to the same ground. Same four source outlets. Same framing. Same headline figures. The verifier looked at the sentences and saw thirteen checkable claims on a mortgage rate-spike cluster, and they were checkable, because those sources hadn’t changed overnight.
Neither the cron nor the verifier made a mistake. That’s the problem.
What the verifier is doing
The verifier works on sentences. Each claim in a draft is tested against the sources that grounded the cluster. Source supports it → claim passes. Source doesn’t support it → claim fails or gets rewritten. The day-two draft passed at 10/13. The day-three draft would have passed at a comparable rate, because it was drawing on the same sources that still said the same things.
That is correct behaviour for a sentence-level verifier. The job it has been given is: are the claims in this draft supportable? Both drafts answer that question identically, because both are grounded in the same unmodified sources.
What the verifier has no view of: whether this cluster has already generated a published article.
That’s not a missing feature. It’s a scope decision. Sentence-level truth and cluster-level novelty are different questions. The problem on day three is that no component in the pipeline was assigned the second question.
Where the pipeline stalled
The day-two triage ranked the mortgage rate-spike cluster at the top of the queue. The drafter ran, the verifier ran, an article shipped. Day three followed the same cycle from an identical starting point. The drafter produced a draft from the same ground; the verifier cleared it. The only thing that stopped a near-duplicate from publishing was manual recognition. I looked at the day-three draft, identified the source material from the previous morning, and discarded it. Two fresh gov.uk single-source drafts on Personal Savings Allowance and HICBC went instead.
That manual check is not scalable. At fourteen daily firing cycles, hand-reviewing each draft for cluster recurrence adds work the pipeline should be doing itself.
Day four ran the same cluster again. This time: zero drafts. Triage completed, 150 clusters ranked, mortgage still at calculator score 20 (top of the list). When candidates were fetched, the ground produced nothing. The drafter found no sentences that would clear the verifier. Silence, not a near-duplicate.
What changed between days three and four isn’t fully documented. The most likely reading: the source ground had been harvested twice in 24 hours and had nothing new to yield. The verifier’s accuracy on individual claims produced zero-drafts on day four (no sourceable sentence, no passing claim, no draft), but that’s cluster novelty detection by accident, via source exhaustion, not by design.
Source exhaustion as a novelty gate is a coincidence, not a mechanism.
The layer that’s missing
Improving on the gate measured the wrong thing: that piece identified the verifier approving a structurally thin draft. 145 words cleared sentence-level checks but failed as an article. The mortgage cluster case adds a second failure mode. The verifier has no memory of which clusters have already published. Structural thinness is a draft-level failure; cluster recurrence is a selection-level failure. They sit at different layers.
Novelty detection belongs at the selection layer:
- After triage ranks clusters by calculator score
- Before the drafter runs on the top-ranked cluster
- A published-clusters record (a list of cluster IDs that have already shipped) checked against the triage output
If the mortgage rate-spike cluster is in that record, it doesn’t enter the drafting queue. The verifier never sees it. The drafter doesn’t run. The cycle moves to the next cluster in the ranking.
This is not a tighter verifier. Adding novelty awareness to the verifier would mix two concerns that don’t belong in the same component. The verifier should ask: are these claims true? A separate component, earlier in the chain, should ask: has this cluster already been covered? One check per component. The correction on day three required a gate that ran before the verifier was called.
What the run exposed
Days two through four gave a clean sequence. Cluster published on day two. Same cluster re-drafted on day three and caught manually. Same cluster zero-drafted on day four via source exhaustion. Three different outcomes, one root cause: no explicit novelty gate between triage and drafting.
Days five and six showed the other case. ISA allowance, student loan repayment thresholds, UK House Price Index April 2026, Pension Annual Allowance: four clusters across two days, each with fresh gov.uk source ground, no recurrence at the cluster level. The verifier’s sentence-level accuracy was the correct tool for those clusters because novelty wasn’t a problem. The pipeline ran cleanly because the cluster rotation worked.
The problem is that high-traffic clusters will keep appearing at the top of the triage ranking. Mortgage rate coverage generates more search demand than most financial topics. Without a novelty gate, the triage output will repeatedly surface the same high-score clusters until their source ground is exhausted, relying on exhaustion as the filter.
A published-clusters list prevents that without touching the verifier, the drafter, or the triage scoring logic. One lookup, before the drafting queue populates.
Out of scope
Cluster cooldowns are a separate problem from first-publish novelty detection. Deprioritising a published cluster rather than hard-blocking it would let it re-enter the queue when genuinely new source material arrives.
The title-mangling bug that produced mortgage-abandoned-about-above on day two is a presentation problem, not a selection problem.
Whether day four’s zero-drafts came from source exhaustion or verifier rejection is worth instrumenting. It doesn’t change the argument for a novelty gate. The gate should have prevented the drafter from running on that cluster regardless.
