The mortgage-abandoned-about-above draft landed on Day 2 of the new cadence. The slug was ugly (the title-mangling step was still mid-fix) but the content was mostly complete. Ten of thirteen sentences passed the verifier’s claim-accuracy checks against the fetched ground. Three failed.
Without a corrective step, that’s a decision point with no good options. You have structured information about what went wrong (the verifier told you) but the pipeline stops there. Someone reads three failure reasons and decides: manually rewrite the failing sentences, bin the draft, or publish the passing ten and quietly drop the three. None of those scale past a handful of publishes a day.
The corrective step rewrote the failing three against the same source material the verifier had used. The draft cleared on the second pass and published. Day 2 closed with two articles: the rescued mortgage rate-spike piece and T-007 Marriage Allowance via the operator path.
Four mornings either side of that established the pattern’s operating range, and where it stops being relevant.
What verification alone produces
The verifier runs claim-by-claim. Each sentence that asserts a number or a regulatory fact gets checked against fetched ground: gov.uk pages, BoE data, Moneyfacts feeds. Every check returns pass or fail with a reason. A draft scoring 10/13 isn’t a bad draft. It carries three specific, addressable problems.
Without a corrective step, that score is the pipeline’s terminal output. You’ve spent compute on the fetch, the generation run, and the verifier. You have structured information about failure and no automated path from that information to a fix. What the pipeline produced is a triage ticket. Someone acts on it, or the draft sits.
At cadence, two publishes a day across a 14-day sprint, that accumulates. Day 3 produced one draft on the same mortgage rate-spike cluster the pipeline had already processed on Day 2: the same BBC + Zoopla + Moneyfacts + BoE ground, the same US-Iran framing, the same £232/£66 regional figures. The verifier would have caught the duplication immediately. Without a corrector, the output is a verified duplicate and a human decision about what to publish instead. The verification pass caught the problem. It produced nothing actionable automatically.
That’s the gap the corrective step closes.
What the corrective step does
The corrective pass runs after the verifier. It takes three inputs: the failing sentences, the failure reasons, and the source material the verifier checked against. From those it rewrites.
The rewrite is grounded against the same source the verifier flagged. A sentence that fails because it cites a figure not present in the fetched gov.uk page gets rewritten with the correct figure from that page, not from model training. The corrector resolves discrepancies against the verified source. It doesn’t invent replacements.
The scope constraint is intentional. The corrector doesn’t touch the passing ten. Rewriting the whole draft would mean rerunning every sentence through the verifier and reintroducing questions about sentences that were already clean. Targeted rewrite on the verified-failing sentences keeps the correction bounded: the verifier’s failure list is the corrector’s exact input spec, not a suggestion for general improvement.
On Day 2, three sentences failed. Three sentences were rewritten. Thirteen of thirteen on the second pass. Published.
The four-morning distribution
Four mornings in a row show the range you’d expect from a pipeline that depends on live news ground.
Day 1 (2026-06-29): Zero drafts. Cron fired at 07:00 UTC. Haiku claim-extraction failed on the one cluster that survived the ground stage. B-076 is still unfixed. No draft reached generation. Nothing reached the verifier or the corrector. Day 1’s two publishes came from the operator path: T-006 60% tax trap and T-029 Mortgage Guarantee Scheme 2025.
Day 2 (2026-06-30): One draft, rescued. The corrective step ran. Two publishes: the rescued mortgage piece and T-007 Marriage Allowance via operator path.
Day 3 (2026-07-01): One draft produced, not rescued. The cluster repeated Day 2’s mortgage ground. The verifier caught the duplication before the corrector ran. Day 3’s two publishes came from the operator path: Personal Savings Allowance and HICBC, both fresh gov.uk single-source drafts.
Day 4 (2026-07-02): Zero drafts. First zero-drafts morning in the current streak. Cron fired at 08:22 BST. 150 clusters ranked; mortgage scored highest at 20. Candidates fetched, but the ground stage failed before a draft reached generation.
The corrective step was relevant in exactly one of those four mornings. The other three fell outside its operating range.
Where the corrector can’t help
When the ground stage fails, the draft doesn’t exist. When the cluster is a duplicate, the verifier rejects before the corrector runs. The corrective pass needs a partially correct draft as input. Zero drafts means it has nothing to work with. Verified duplicates are terminal before the corrector gets context.
The corrective step is not a recovery path for upstream failures. Days 1 and 4 are ground-stage and extraction-stage problems. They need fixes at those layers.
B-076 is still open. It’s the Haiku claim-extraction bug that dropped Days 1 and 4 to zero drafts. The corrector is working correctly at its own layer; B-076 is a different problem at a different layer.
The operator path that covers the gaps
Days where the cron produces zero or a duplicate are covered by the operator path. Day 5 published ISA allowance and student loan repayment thresholds before the morning cron fired, both hand-drafted from gov.uk source material. The ISA allowance piece ran to 754 words across 15 hand-curated claim blocks verified against three gov.uk pages.
The asymmetry is intentional. The cron targets news-reactive content: clusters from current coverage, ground from live feeds, drafts generated against material that may be fresh, stale, or already covered. The operator path targets pillar content: stable regulatory facts from primary sources the operator selected before drafting. Different content types, different ground reliability, different verification requirements.
The verifier + corrector pair earns its compute on cron output because that’s where the probabilistic gap lives. Pillar content starts from source material the operator curated; the claim-extraction approach doesn’t transfer directly. Out of scope: automated corrective pass on operator-path drafts.
The arithmetic of rescue versus bin
The rescue pattern fired once in four mornings. One in four is not a failure rate. It’s the distribution a news-reactive pipeline produces when ground is unreliable and duplication is a real risk.
Verification without correction would have closed Day 2 as expensive triage: fetch cost, generation cost, verifier cost, and then a human session to produce something publishable from the same ground. The corrective step closed it as a publish.
The compute added by the corrective pass is bounded to the failing sentences rewritten. The alternative isn’t free. Binning the draft doesn’t recover the fetch or the generation run. It adds a human session on top. At 14-day cadence with two publishes a day, the corrective step earns its compute cost the first time it runs on a draft like Day 2’s.
B-076 will close eventually. When it does, the cron will produce more drafts than four mornings suggests. The corrective pass will run at higher frequency. The pattern it establishes on Day 2 scales. Binning those 10/13 drafts instead doesn’t.
