Day 2 of the streak. The mortgage rate-spike draft came out of the overnight cron with ten of thirteen sentences passing the verifier. Three failed. The grounding check found no supporting claim in the source set. They were not wrong in any obvious way. They were plausible sentences about UK mortgage markets in spring 2026, the kind an LLM produces confidently from training data even when the source set it was given contains nothing that supports them.
The natural reflex at that point is to tighten the prompt. Add an instruction: “only assert what you can trace to the provided sources.” Add a negative constraint: “do not write sentences without a cited ground claim.” Maybe a few examples to anchor it.
That reflex is wrong. Fourteen consecutive publishing days made the case.
The two approaches
The pipeline drafts articles grounded in gov.uk data: tax thresholds, allowances, regulatory figures. The LLM receives a set of sourced claim blocks; the article is meant to stay within them. Two strategies exist for enforcing that constraint.
Prompt-level constraint. Tell the model what it must and mustn’t do. Cheap to implement. Also probabilistic: the model will comply most of the time and fail unpredictably when generating at length, when the source material is thin, or when two claims are related but not explicitly connected in the ground data. Model compliance with a constraint is a learned behaviour subject to context-window pressure, temperature, and interaction effects with every other instruction in the prompt.
Corrective verifier. Let the model generate freely. After generation, a deterministic check runs against every sentence: does this claim appear in the source set? The answer is pass or fail. No interpretation. No probability distribution to weight. Failed sentences are either rewritten against the nearest matching source or dropped. The draft reaching the queue is the one that survived the check.
The first approach requires no build work. The second requires significant build work. Over fourteen days, the second is the one that held.
What the data looked like
Day 3 produced one draft, on the same mortgage cluster the pipeline had published the previous day. Same BBC, Zoopla, Moneyfacts, and Bank of England ground. Same US-Iran framing, same £232/£66 regional figures. The LLM, given nearly identical source material, generated a structurally similar article. The pipeline rejected it as a repeat cluster, which is correct behaviour. The verifier did not need to run on a structurally duplicate draft; the cluster logic handled it first.
Day 4: zero drafts. The cron fired on time at 08:22 BST, ranked 150 clusters, and picked mortgage at 20. Candidates were fetched but nothing passed from ground to draft stage. This is a sourcing failure, not a verifier failure. The distinction matters: the verifier corrects generation; it cannot fix a source layer that returned too little to work from. A prompt constraint would also have produced zero drafts, but for a different reason, and with no diagnostic information about where the pipeline stalled.
Day 5 was the cleaner test. The ISA allowance pillar shipped at 754 words with 15 hand-curated claim blocks drawn from three gov.uk pages. That is the size of the ground: 15 blocks, three sources. Every sentence in the published article mapped to one of those blocks or it did not survive. No prompt instruction produced that result. A structured check did.
Day 6 changed the sourcing layer. The gov.uk Search API polled live in a real cron for the first time. Before that, ground data was injected by hand. Moving the fetch into the cron loop meant the verifier had a live, structured source set rather than a static one. It also changed the failure mode: a source outage now surfaces before generation rather than producing a verifier-rejected draft mid-cycle.
Why the prompt loses this comparison
The three sentences that failed the Day 2 verifier were not obviously wrong. They were plausible. An LLM generating about UK mortgage rates will produce confident-sounding sentences even without cited support, because the training corpus contains enough about the subject to fill the gaps. That is exactly the failure mode a prompt instruction cannot address.
A prompt tells the model what to value. A verifier measures the output against a fixed standard. These are not the same operation. The model’s compliance is probabilistic and degrades in identifiable conditions: long context, thin sources, high-similarity adjacent claims. The verifier’s check is deterministic. It does not degrade across fourteen days, across different cluster topics, or across changes to the generation prompt.
There is also a compounding cost to prompt constraints. Every instruction added competes with the others. A dense constraint list degrades generation quality even when the constraints are individually obeyed. The verifier has no effect on generation: it runs after. Adding a constraint to catch one failure mode introduces new failure modes elsewhere in the prompt. The verifier catches without interfering.
What “corrective” means
A gate stops a bad draft. A corrective verifier does something more targeted: it identifies which sentences failed and drops or repairs them, not the whole draft.
This matters for the Day 2 case. Ten sentences passed. The rescue produced a publishable article rather than a rejected one. A gate would have blocked all ten clean sentences on the strength of three bad ones; the corrective model let them survive. That is the difference between a verification step that gates and one that corrects.
Out of scope: automatic repair via re-generation. The pipeline’s correction is currently deletion, not substitution. Substitution means a second round of LLM generation with its own verification requirement. That is a later sprint.
The fourteen-day finding
Prompts teach the model the shape of a good output. Post-processors enforce the output contract deterministically. Trying to use a prompt to do the post-processor’s job is a category error. You are asking a probabilistic process to provide a guarantee it is not designed to give.
The corrective verifier is the guarantee. Over fourteen consecutive days, the sourcing layer varied, the clusters varied, the cron misfired once, the source API changed. The verifier ran on every draft that made it to generation. The prompt describing the target output did not change once.
When a sentence fails the verifier, the correct response is not to adjust the prompt. It is to check the source set and, if the source set is adequate, confirm that the correction mechanism did exactly what it was built to do.
