On 17 July the approval gate operated exactly as designed. The crons on 16 and 17 July had each produced two fully gate-passing ready drafts — the first multi-day autonomous streak since the pipeline launched. Two articles out, no CLI intervention. The system did what it was built to do.
By 20 July I was writing a rescue entry.
The piece was uk-higher-additional-rate-taxpayers-2026-27. HMRC projections, 7.7 million higher-rate taxpayers, up 34% on the previous year. A genuine fiscal-drag story, the kind the cron is supposed to surface. That morning the cron had produced zero drafts: two checklist failures, one CLI error, two day-capped candidates. The cadence clock had already reset. I drafted the piece manually, published it, logged it.
Three days later, the May HPI piece landed the same way. Rescued from Wednesday's checklist casualties, screened against existing coverage first (the devlog notes this was the first rescue where that check happened before drafting, not after), written outside the automation, committed by hand.
That's the shape of July: two consecutive days where the pipeline worked autonomously, and a rescue queue running alongside it before and after.
What the 14-day clock is measuring
The cadence system tracks a 14-day rolling publish window. Publish something inside that window and the clock stays live; ship nothing for 14 days and the counter resets. The design is reasonable. The assumption underneath it is where it breaks down: that the pipeline will produce something before the window expires.
When a cron run produces zero drafts, the 14-day window keeps counting. It doesn't pause because the cron ran. It counts against the deadline regardless of whether the pipeline was active or broken. A cluster of zero-draft days burns through cadence credit faster than a single good week rebuilds it.
The 10 July entry names this directly: "the 14-day cadence clock is broken and restarts from today." After a three-weekday gap on 7–9 July, the clock had expired. I restarted it by hand: two pieces published, counter back to zero.
The July gap anatomy
The 7–9 July gap is documented in detail. On 7 July: eight clusters triaged to draft, six packs failing. The cron ran, classified work, came up empty. That's success-no-publish at the operational level: the pipeline did non-trivial work and produced nothing the gate would pass.
8 July: zero articles. 9 July: zero articles.
The 14-day window counted down across all three days. On 10 July I published the stamp-duty draft and the Lifetime ISA pillar, both manually. The gap closed. The clock restarted. Three weekdays of cadence credit gone.
Then 15 July: Santander 8% Regular Saver piece, rescued from a composer-failed cluster.
Then 16 and 17 July: the streak. Two consecutive crons producing gate-passing output, approval gate working as designed.
Then 20 July: zero drafts. Manual rescue.
Then 23 July: manual rescue.
The clock has reset multiple times across a period where the pipeline demonstrably produces good output on good days. The July 17 streak is real. It's also insufficient. One bad cluster after a good run returns the clock to zero.
The structural mismatch
The pipeline isn't broken in the way earlier failures were broken. The July 17 streak is genuine progress: dead-zone fixes holding, verifier and dedupe both stable, first multi-day autonomous run. The gate worked. The output was publishable. That matters.
The mismatch is between the clock's design and the pipeline's actual reliability profile. The clock assumes consistent output. The pipeline produces it inconsistently: well on some days, nothing on others, with failure modes that recur across different runs. Checklist failures, CLI errors, day-capping: the July 20 failure list has the same shape as the July 7 failure list. These aren't one-off bugs. They're categories of failure that show up regularly.
A cadence clock that resets on any sufficiently bad cluster isn't measuring whether the pipeline is working. It's measuring how long since the last rescue. When I publish a manual rescue, the clock logs it identically to an autonomous publish. The distinction isn't visible to the clock. It isn't visible to the reader. But operationally, the rescue is the schedule and the automation is a contributor when conditions align.
What the rescues reveal
Each rescue has the same structure: screen the topic against existing coverage, draft, publish. The July 23 HPI piece notes the screening explicitly ("screened against our own coverage FIRST this time"), implying earlier rescues handled this check less reliably. That's editorial discipline improving under manual operation, independent of whether the automation improves.
The fiscal-drag piece on 20 July involved checking MoneyWeek and FT sourcing for the HMRC projections before committing to the draft. The May HPI piece on 23 July required confirming May was a new release before writing; April gov.uk and June Lloyds were already in the coverage database, May wasn't.
That's editorial work. It's also the work the cron was designed to handle independently: topic discovery, coverage checking, draft generation. The rescue sessions are running the pipeline's intended function outside the pipeline.
The automation adds real value on the days it produces gate-passing output. The July 16–17 pieces came out without touching the CLI. But the publishing rhythm isn't driven by those days; it's driven by whether there's been a rescue recently enough to keep the clock alive.
What needs to change
Three things, in increasing order of complexity.
The clock should track pipeline activity, not only publish events. The 14-day window currently treats "cron ran and found nothing gate-passing" identically to "cron didn't run." A clock that distinguished active-but-empty runs from genuine inactivity would survive zero-draft clusters without resetting. Whether that's the right design is a separate question; the current behaviour makes the cadence clock a proxy for rescue frequency rather than pipeline health.
The zero-draft rate needs to fall. The July 20 failure breakdown is deterministic: checklist failures behave the same way each run, day-capping is a known cap, CLI errors are recoverable. Each category has a bounded fix. Reducing the failure count per cron directly reduces the frequency of zero-draft days, which is the proximate cause of clock resets.
The rescue process should have a staged queue. Currently each rescue is an independent discovery session: identify the gap, find a topic, screen it, draft, publish. Pre-staging candidate topics against the coverage database (a queue ready to pull when the cron comes up short) would reduce the session overhead and make manual intervention faster. Out of scope now. Worth naming because it's the lowest-friction path to reducing rescue cost without waiting for the automation to improve.
The honest accounting
The July 17 streak is the most encouraging signal the pipeline has produced. Two autonomous publishes with no intervention, gate-passing output across two consecutive crons. That's the target.
The accounting from 10 to 23 July: the clock has reset. The rescue queue has filled. The automation is useful on the days it works and absent on the days it doesn't, and there are more of the latter.
The cadence clock resets on zero. The publishing schedule resets on rescue. Until the zero-draft rate falls enough to stop consuming the window between good runs, that's the system.
