The Mon→Tue cron fired at 07:00 UTC. It produced one draft: mortgage-abandoned-about-above — the slug was ugly because the title-mangling step was still mid-fix. Thirteen sentences in the body. Ten passed the verifier. Three didn’t.
The draft still published.
The pipeline
Lane B is the content arm of UK Calculators: daily cron, cluster ranking, candidate fetching, LLM drafting, sentence-level verification, publish. The pillars are factual articles tied to specific UK financial figures — mortgage rates, tax allowances, pension thresholds, exemption limits. The figures come from gov.uk; the drafts come from the model.
This is a category of content where 77% correct is not acceptable. If a calculator article quotes a stale base rate or an expired exemption figure, the reader uses it to make a financial decision. Accuracy here is not a quality preference; it’s the product.
The three cases
A draft that fails all thirteen sentences doesn’t ship. Day 4 of the sprint, 2026-07-02, was the first zero-drafts firing: 150 clusters ranked by calculator score, mortgage at the top, candidates fetched, ground insufficient to support a draft that cleared the bar. The cron logged it and moved on. That’s the easy case — the pipeline knows it has nothing; no decision required.
A draft that passes all thirteen sentences ships clean. Day 5, 2026-07-03: the ISA allowance pillar published before the morning cron fired, drafted in the same overnight session as the branded-exports work. 754 words, 15 hand-curated claim blocks across three gov.uk pages. Passed. Published. That’s the target case.
Ten of thirteen is the dangerous case. Structure is right. Sourcing is credible for most of the piece. Three claims somewhere in the body are either unsupported, stale, or wrong. The 10/13 case is dangerous specifically because it is indistinguishable from the 13/13 case at a surface read. A reviewer doing a spot-check reads fluent prose and credible-sounding claims. The three bad sentences don’t flag themselves. They sit in the same paragraph structure, with the same citation posture, as the ten that are correct. Without sentence-level verification, all thirteen look the same: text, produced by the model with identical apparent confidence.
That’s the silent failure mode.
Why the model can’t tell you
The model produces sentences by the same process regardless of whether they are correct. A sentence asserting the current base rate is 4.5% looks syntactically identical to one asserting it correctly. The confidence signal in the output is flat either way. This is the structural reason external verification exists: the model cannot tell you which of its sentences to trust, because it generated all of them the same way.
An aggregate document quality score captures fluency, structure, and coherence. It cannot capture factual accuracy per claim, because accuracy is not a property of the document; it is a property of each claim relative to a source. A binary gate set at any reasonable aggregate threshold passes the 10/13 draft. The three failed sentences ship.
What “corrective” means
A binary gate answers: does this draft pass? A corrective verifier answers: which sentences pass, which fail, and what the failure is. The mortgage-abandoned-about-above draft returned three failures. That output went to the operator as a set of specific corrections, not a blocked state. The operator patched three sentences and the draft published as Day 2’s cron rescue alongside the fresh Marriage Allowance pillar.
Fourteen pillars in fourteen days is the sprint target. At that pace you cannot discard every draft below 100% and wait for the cron to surface the cluster again the following morning. A discard means either re-prompting and hoping the next output scores 13/13, or missing the day’s publish slot. The corrective output eliminates both: it answers whether the blocked draft needs three targeted fixes or a structural rebuild. On Day 2 it was three fixes. That is the difference between a publish and a miss.
Where the failures cluster
The three failed sentences in a 10/13 draft are not random. They cluster on the claims that are hardest to source: figures with a specific effective date, policy detail that changed quietly between gov.uk updates, regional breakdowns that exist in the source material but weren’t in the ground the model was given. These are exactly the sentences a reader would go to the calculator site to verify. They are also exactly the sentences a binary gate cannot distinguish from the ten that are correct.
The corrective verifier doesn’t fix the sourcing problem. It surfaces it at the right granularity. “This draft failed” is not actionable. A per-sentence result with a reason per failure is. The operator corrects the specific claims rather than rewriting the piece.
Week two
Day 6, 2026-07-06: the morning cron locked before completing — an AppleEvent -1712, system resources held by the prior session. Cj cleared the cause and re-kicked at 08:35. The cycle completed and published two pillars: UK House Price Index April 2026 and Pension Annual Allowance. The significant change on Day 6 was the gov.uk Search API sourcing going live in a real cron for the first time — Lane B’s first data-pegged article, figures pulled from the API at draft time rather than from a static snapshot.
Data-pegged sourcing shifts the failure-mode profile. A sentence grounded in a live API call either retrieves a current figure or it fails retrieval. There is no stale-figure failure mode — only a successful-or-not one. The 10/13 pattern still applies in week two, but the type of failure the verifier surfaces changes: retrieval failures rather than stale-ground mismatches.
What this isn’t
Out of scope: the cluster-ranking and candidate-fetching steps that determine which topics get drafted. Out of scope: the zero-drafts case, where the source ground is too thin to support any draft at all. The corrective verifier is the right tool for 10/13. It is not the right tool for 0/13 — that is a sourcing problem one layer upstream.
The build log
Each day of the fourteen-day Lane B sprint is in docs/devlog.md in the UK Calculators repo. Day 2 has the 10/13 detail. Day 4 has the zero-drafts event. Day 6 has the AppleEvent -1712 diagnosis and the first gov.uk API milestone.
If you are building a factual content pipeline on top of an LLM and gating on an aggregate quality score, those entries are worth reading before you ship. Then build the corrective verifier. The cost is less than the cost of auditing the sentences that slipped through without it — and considerably less than the cost of a reader using an expired figure to make a financial decision.
