08:22 BST, 2 July. Triage ran. 150 clusters ranked; mortgage led at a calculator score of 20. Candidates fetched. Then: zero drafts.
Not a failure. The cron exited clean and produced nothing.
The run was Day 4 of a 14-day publishing sprint. The cron was supposed to be the engine. By Day 4, the operator was carrying the sprint, and the cron was producing either duplicates or nothing. The difference between those two states was invisible in the pipeline output.
That is the diagnostic problem. A cron that errors has a location: a stack trace, an exit code, a log line that names the offender. A cron that exits clean and produces nothing has a gap. The gap sits somewhere between “150 clusters ranked” and “publish run.” Standard pipeline output does not tell you where.
What the triage count actually tells you
150 clusters is a count. It confirms the ground-attrition step had material to rank. Mortgage scoring 20 confirms the ranking logic ran and ordered by calculator relevance. Candidates fetched means the scoring threshold was crossed by at least one cluster.
None of that explains why zero drafts emerged.
The verifier in place checks output quality: did the draft pass the sentence-level claim tests, did it have enough grounded sentences. That is the right check to run on a draft that exists. It cannot run on a draft that was never written.
The missing check is at the transition point, between “candidates fetched” and “drafter invoked.” If that transition produces zero invocations, you need to know why. Which threshold the candidates failed. Which rule applied at which stage.
The five-day context
The 2 July zero is not isolated. Day 3/14 (1 July) produced one draft: the same mortgage rate-spike cluster published the day before, built on the same BBC, Zoopla, Moneyfacts, and Bank of England ground, the same US-Iran framing, the same regional figures. The output verifier passed it. The redundancy was only apparent once you checked the already-published corpus.
Day 2/14 (30 June) produced one mostly-complete draft with 10 of 13 sentences passing the verifier. Slug: mortgage-abandoned-about-above. Ugly, from a title-mangling step still mid-fix. Not a bad run on its own terms; the title problem was known.
By Day 4/14 (2 July), the cron was firing on schedule and producing nothing. 150 clusters in, zero out. From the outside, the run was indistinguishable from a run where there were simply no viable candidates. The standard output did not say whether de-duplication consumed the field, or whether no candidates cleared the scoring threshold, or whether something else ate them before the drafter was invoked. It said: zero.
The articles that shipped across Days 3 to 6 came from operator publishes. Day 4/14: CGT annual exemption and Dividend Allowance, published manually. Day 5/14: ISA allowance and student loan repayment thresholds — 754 words, 15 hand-curated claim blocks across three gov.uk pages, published before the morning cron fired, drafted in the overnight session. Day 6/14: UK House Price Index April 2026 and Pension Annual Allowance, with the gov.uk Search API sourcing live in a cron cycle for the first time, after the AppleEvent -1712 lockup from earlier that morning was fixed and the cycle re-kicked at 08:35.
The operator was filling the gap. 15 hand-curated claim blocks on ISA allowance is high-quality output. It is also work that cannot scale at sprint pace. When the operator publishes and the cron produces zero, the sprint appears to be on track. The engine failure is invisible in the aggregate count.
What legibility would look like
Improving on the earlier finding that verification without correction is just expensive triage: the correction needed here is not a harder verifier on draft output. It is a verifier at the transition layer, before the drafter is invoked.
A corrective verifier at that layer emits a chain: how many candidates cleared the scoring threshold, how many survived de-duplication against the already-published corpus, how many survived filtering against today’s queued drafts, how many drafter invocations that produced. Each step in the chain names one transition. The gap is always in one of those transitions.
Without the chain, the cron tells you “150 clusters, zero drafts” and you reach for the manual publish. The rule that ate every candidate is invisible. It eats the next run identically, and the sprint continues on operator effort while the underlying constraint goes unfixed.
With the chain, you see where the count collapsed. If de-duplication consumed the field, you expand the candidate pool or adjust the suppression window. If the scoring threshold is the constraint, the current news cycle is thin and you know to wait or widen the ground query. Different failures, different interventions. The corrective verifier is what makes those failures distinct.
Verifier versus corrective verifier
A verifier checks output. It tells you whether the thing produced is correct.
A corrective verifier checks transitions. It tells you where in the chain the count dropped, and which rule caused the drop.
The pipeline has verifiers. The 10-of-13 check, the claim-block grounding check, the sentence-level pass rate: output verifiers, doing their job. The 1 July draft that duplicated the previous day’s mortgage cluster passed them. The problem was not that the draft was wrong. The problem was that the draft was redundant, and the de-duplication check did not prevent the drafter from being invoked on consumed ground.
The output verifier ran on what was there. A corrective verifier would run on what was not there, and say why.
That is the gap the 2 July run made visible: 150 in, zero out, no chain between them. The pipeline produced the right count at triage, and the right count at publish. What it did not produce was the count at every step in between.
Scope
De-duplication threshold tuning is a separate sprint. This is the diagnostic layer only.
The ISA allowance, CGT, PSA, HPI, and pension articles shipped across Days 3 to 6 demonstrate the pipeline can produce grounded content at quality. They do not demonstrate the cron can produce it consistently without operator intervention. The gap between those two claims is what the corrective verifier is built to close.
