The 07:00 UTC cron on 30 June produced one draft, slugged mortgage-abandoned-about-above because the title-normalising step was mid-fix. Verification against live gov.uk pages passed 10 of 13 sentences. Three failed.
That result rescued the draft rather than publishing it. CJ corrected the three failing sentences and it shipped that day alongside the T-007 Marriage Allowance pillar. Two publishes from one cron cycle, one autonomous and one rescued.
The rescue was not the pipeline failing. It was the pipeline doing exactly what it was built to do.
What the verifier checks
Diverging from the framing that verification without correction is expensive triage: for gov.uk factual content, dropping a draft that fails is not a waste of the verification pass. It’s the correct output.
The verifier checks each factual sentence against a live gov.uk URL. Not the topic. Not whether the sentence sounds plausible. Whether the specific figure or rule in that sentence exists on the page cited. The ISA allowance pillar, published on 3 July, had 15 hand-curated claim blocks across three gov.uk pages. 754 words. Each claim block tied to a URL. That’s not heuristic; it’s a lookup.
The distinction matters. Large language models optimise for plausibility, not accuracy. A sentence stating the ISA annual allowance is £20,000 sounds equally plausible whether the figure is £20,000 or £19,500; the model can’t tell the difference and generates what sounds correct given its training data. The verifier checks what is actually correct at publication time, against the source that governs.
The publish-or-drop binary
The architecture has three outcomes:
- All claims pass: publish
- Most claims pass with isolated failures: rescue candidate, operator intervention required
- Core claims fail: drop
The 10-of-13 mortgage result sat in the middle category. That’s not a failure mode. Publishing 10-of-13 and letting three wrong sentences run: that would be the failure mode. On a site that provides UK financial figures to people making real decisions about mortgages, ISA contributions, and tax planning, three incorrect sentences aren’t tolerable. The cost of a wrong figure exceeds the cost of a missed publication cycle.
The verifier doesn’t know that; it only knows pass or fail per claim. The publish-or-drop logic above it makes the binary decision, and correction is an operator task, not a pipeline task.
Why gov.uk
The precision comes from the source. Gov.uk publishes authoritative, URL-stable financial rules: the ISA allowance, the Personal Savings Allowance, the pension Annual Allowance, each at a known URL. When figures change, gov.uk changes first. The verifier’s next run of any pillar referencing an updated URL catches the discrepancy before it publishes.
Without gov.uk grounding, the verifier would compare LLM output against search results, training data, or another LLM call. None of those are the authority. The source needs to be the authority for the binary gate to be trustworthy.
The pillar format creates a natural constraint. Every calculator on the site computes based on a specific published rule: the ISA annual allowance, the student loan repayment threshold, the Capital Gains Tax exemption. The pillar article explains the rule the calculator applies. If the article states the wrong rule, the calculator and the article disagree. Gov.uk is the authority that resolves both.
The first time this ran in a live cron, not a manual invoke or a dev test, was the 6 July cycle. The cron had been locked up by an AppleEvent -1712 error earlier that morning. The re-kicked 08:35 run completed the full chain, including the new gov.uk Search API sources polling live data. First real cron run of gov.uk-grounded verification. Not a backfill.
Zero is also a valid output
The 2 July cron fired at 08:22 BST, ranked 150 clusters, identified mortgage as the top candidate by calculator score at 20, fetched candidates, and produced zero drafts.
That isn’t a bug. A cron that produces nothing when the available ground doesn’t support accurate claims is behaving correctly. The pipeline’s job is to publish accurate content. Zero is accurate output when nothing clears the bar.
A pipeline that produces five weak publishes a week looks more productive than one that produces two solid ones and three zeroes. The two solid ones are the only ones the site can afford to have. The zeroes aren’t failures of the cron; they’re the cron functioning as a quality gate rather than a content factory.
The 1 July cron made the same mistake from the other direction: it produced one draft on the mortgage rate-spike cluster, but the ground was the cluster already published the day before. Same BBC, Zoopla, Moneyfacts, and Bank of England sources, US-Iran framing, £232 and £66 regional payment figures. Duplicate ground, different draft, same underlying data. The verifier doesn’t detect duplication (that’s a separate layer), but the pillar pipeline is a precision machine, not a throughput machine.
The operator role
The 30 June rescue defines what operator intervention means in this pipeline. It’s not content creation. It’s not prompt engineering. It’s correcting three specific failing claims against three specific gov.uk pages, where the pipeline has flagged the failures but the fix is a one-sentence edit.
That’s narrow by design. The draft supplies structure. The verifier supplies a list of failures. The operator corrects the failing sentences. Three components, minimal overlap. The operator isn’t rewriting the article; they’re replacing wrong figures with correct ones.
The 3 July ISA allowance pillar went the other direction: 15 claim blocks, all passing, published before the cron fired. That’s the full pipeline working end-to-end with no rescue step. The 30 June mortgage result was the boundary condition, close enough to publish after a single corrective pass, evidencing that the verifier’s threshold sits in a useful place.
What this isn’t
The verifier is not a correction engine. It identifies failing claims; it does not rewrite them. Automated rewriting would introduce the same plausibility-versus-accuracy gap the verifier exists to close. The human is in the loop at exactly the point where a wrong sentence needs to become a right one.
The verifier is not a completeness check. A draft that omits important information but states nothing false passes cleanly. Completeness is a different problem. Gov.uk grounding doesn’t solve it, and the verifier doesn’t try.
The verifier is not evidence that LLMs produce wrong financial figures at a high rate. 10 of 13 passing on a first-run mortgage draft is a strong result against a live gov.uk source. What the verifier catches is the subset where the model’s version of a rule has diverged from the current published figure, or where it synthesised across multiple sources and landed on a plausible number that isn’t the authoritative one. Small in frequency; high in consequence.
The scope is narrow on purpose: factual claims against authoritative sources, binary pass-or-fail per claim, publish when all pass, operator rescue or drop when some fail. That narrowness is what makes the gate reliable enough to run unattended.
