The cron fired at 07:00 UTC on the Monday–Tuesday cycle. The draft came back as mortgage-abandoned-about-above. The slug is ugly because the title-mangling step is still mid-fix. None of that matters. What matters is the verifier output: 10 of 13 sentences passing.
Three sentences needed corrective rewrites. The article published. The April mortgage rate-spike piece, queued since April, cleared the backlog on Day 2 of a 14-day sprint.
That is the design decision worth documenting. The question the rescue forces is not “is this draft clean?” but “at what level does the gate operate?” Article-level gates would have killed this draft a second time. Claim-level gates surfaced exactly what needed fixing.
The problem with whole-article gates
The obvious first instinct for a verification step is binary: article passes, or article holds. If any claim fails, nothing ships. Clean semantics. Easy to reason about.
The failure mode is waste. A draft with 12 verified sentences and 1 bad one holds indefinitely unless something intervenes manually. At volume, “holds indefinitely” becomes “never ships.” The content pipeline stalls not because the content is broken, but because the verification architecture cannot distinguish a salvageable draft from an unsalvageable one.
The April mortgage draft was the first live test of the alternative. It had already gone through one failed cycle and sat in the queue for weeks. A whole-article rejection gate would have killed it again. Three fixable sentences would have blocked ten sound ones indefinitely.
What claim-level verification returns
A verifier that gates at the sentence level produces three things differently from one that gates at the article level.
It returns a claim-by-claim result, not a pass/fail flag. The 10/13 ratio is the primary output, not a side-effect. Each sentence carries its own disposition.
It surfaces the correctable subset explicitly. Three sentences failed. That list is actionable. A corrective rewrite loop targets those three sentences. The ten passing sentences never re-enter the rewrite path.
It separates the publication decision from the rewrite loop. The editor sees ten confirmed sentences and three candidates for correction, not a monolithic “this draft failed.” Those require different effort and different judgment.
The April mortgage draft published with corrective rewrites applied to the three flagged sentences. One item cleared from a queue that had been blocked for weeks.
Day 3 illustrated the other case
The next morning the cron produced one draft on the same mortgage rate-spike cluster: BBC, Zoopla, Moneyfacts, Bank of England ground, US–Iran framing, £232/£66 regional payment shift figures. The same source material as the article that had just shipped.
That one got discarded. Correctly.
Same ground, same thesis, nothing new. The distinction between “three sentences need fixing” and “this is a duplicate of yesterday’s article” is clear at the sentence level too. Claim-level verification didn’t have to work hard to surface it.
Day 4: a different failure mode
Day 4 produced zero drafts. First zero-draft firing in the current sprint: 150 clusters ranked, mortgage topping at a calculator score of 20, but nothing cleared the drafting threshold.
That is not a verification failure. The pipeline ran correctly, and nothing was ready to draft.
Worth keeping the two failure modes separate. “Drafts exist but verification killed them” is a signal about source quality or verifier calibration. “No drafts produced” is a signal about the candidate pool. Conflating them sends the calibration effort in the wrong direction.
Built claim-first versus rescued claim-first
Day 5 published two pillar pieces: ISA allowance and student loan repayment thresholds. The ISA allowance article ran to 754 words with 15 hand-curated claim blocks sourced across three gov.uk pages.
Each claim block carried its own source attribution at write time. The verification step had a different job from the mortgage draft rescue: checking already-attributed claims against declared sources, not tracing sources for claims that arrived unattributed.
That is a different shape of draft from the April mortgage piece. News drafts arrive from a cluster of secondary sources: press coverage, lender data, rate tables. The verification step has to do more attribution work at the end. Pillar pieces built directly against primary legislation pages arrive pre-structured at the claim level.
The 10/13 outcome on the mortgage draft and the clean run on the ISA piece describe the same architecture at two points in the process: one built claim-first, one rescued claim-first. The verifier’s job differs. The granularity it operates at does not.
What the 10/13 ratio signals
10 of 13 is not a threshold that triggers automatic approval or rejection. It is a signal about the shape of the repair work.
Three failing sentences from a draft grounded in real data (mortgage rate movements, Bank of England base rate decisions, regional payment shift figures) will typically be factual precision issues: the source is sound, a specific claim overstates or misstates a number. Corrective rewrites at the sentence level close that in minutes.
Invert the ratio. 3 of 13 passing means rewriting ten sentences, which is replacing the draft rather than correcting it. At that ratio, discard and re-draft from source is the better call. The 10/13 pattern told me I was in the first situation.
The architecture implication
A verifier returning only pass/fail at the article level cannot surface the 10/13 distinction. It loses information directly relevant to the editorial decision. Claim-level granularity changes not what the verifier checks, but what the pipeline can do with the result.
The same distinction applies to the rewrite loop. A claim-level verifier can drive targeted rewrites: here are the three sentences, here is what each one got wrong, rewrite just these. An article-level verifier can only return “this draft failed.” The rewrite effort that follows is undirected. The editor re-reads the whole draft looking for what caused the failure.
By Day 6, the gov.uk Search API was sourcing live data in a real cron cycle for the first time. UK House Price Index and Pension Annual Allowance pieces ran off polled primary data rather than pre-fetched ground. API-sourced content fails differently: freshness and specificity errors that a static pre-fetched ground set doesn’t produce. Claim-level verification becomes more valuable as source complexity grows.
Out of scope: automated corrective rewrite. The three flagged sentences were corrected by hand. A rewrite loop against the flagged-sentence list is a future sprint. The granularity decision stands independent of whether the correction is manual or automated. Get the grain right first.
