The morning of 15 July, the cron ran. Eight clusters went through triage. The Santander cluster (8% AER Regular Saver, 5.00% bonus dropping to 3.00% at month twelve, monthly cap mechanics) passed triage and failed to compose. I pulled it manually by mid-afternoon and published santander-8-percent-regular-saver-2026. The cadence log counts that as a successful publish. The rescue log counts it as a composer failure.
Every published article in July has a rescue log entry. Except one.
A rescue log doesn’t exist as a formal document. I reconstructed it from the devlog: the “rescued from today’s cron casualties” notes, the gap analyses, the failure classes named in each commit. Reading it against the cadence log is a different view of the same month. The cadence log shows what shipped. The rescue log shows what I had to do to get it there.
The prior picture and what it missed
The earlier analysis confirmed that July’s 14-day cadence clock ran on manual rescues. This piece names what broke each time. Five articles shipped. They didn’t fail in the same way. Each is a different failure class with a different fix surface.
Five publishes, five rescue stories
10 July: stamp-duty rescue + Lifetime ISA pillar. A three-weekday gap preceded this publish. 7, 8 and 9 July produced zero articles. The 7 July cycle ran, triaged eight clusters to draft, returned no publishes. Two articles came out on 10 July via manual intervention. Failure class: silent pipeline gap. Multiple clusters processed, nothing produced, no error surfaced in the cycle output. Diagnosing a zero-output cycle means walking back through each cluster’s stage logs to see where it dropped.
15 July: Santander 8% Regular Saver. Composer-failed cluster. Triage passed; composition didn’t run to a usable output. I retrieved the piece and ran compose-and-publish by hand. Failure class: composer failure.
17 July: BoE hold mortgage piece + additional-income guide. The exception. The 16 and 17 July crons each produced two fully gate-passing ready drafts. First multi-day autonomous streak since the dead-zone fix, verifier and dedupe landed. The approval gate operated as designed: pieces queued, I approved, they published. No retrieval, no manual compose, no checklist bypass. Failure class: none. This is the target state.
20 July: fiscal-drag rescue. The morning cron produced five casualties: two checklist failures, one CLI error, two day-capped articles. I rescued the fiscal-drag piece (uk-higher-additional-rate-taxpayers-2026-27, HMRC projections of 7.7 million higher-rate taxpayers via MoneyWeek/FT) from the wreckage. Failure class: multi-cause. Three distinct failure modes in one cron cycle.
23 July: May HPI rescue. I rescued the May HPI piece (uk-house-prices-may-2026-hpi, ONS UK HPI, 2.7% annual) from the morning’s checklist casualties. Notable addition to the rescue process: coverage screening ran first. “Screened against our own coverage FIRST this time.” May was a new ONS release; April gov.uk and June Lloyds were already covered. The screen passed. The pipeline hadn’t been running this check consistently. I introduced it as a manual rescue step, not a triage gate. Failure class: checklist casualty + coverage-screening gap.
The failure taxonomy
Five publishes, six distinct failure modes:
- Silent pipeline gap: clusters triaged, nothing produced, no error surfaced
- Composer failure: cluster passed triage, composition didn’t complete
- Checklist casualty: piece failed content validation (July 20 and July 23 both)
- CLI error: tooling failure mid-run
- Day-cap: article ready, daily publish ceiling hit
- Coverage-screening gap: triage not checking against existing published articles before queueing
The 20 July rescue involved three simultaneously. Checklist casualties appear twice (July 20 and July 23), making the validation layer the most consistent failure surface in the month. The 23 July rescue introduced a coverage check as a rescue step that the triage layer should have been running from the start.
None of these are unusual for a pipeline in early operation. What’s notable is that they didn’t surface as formal failure reports. They surfaced as rescue events. A rescue event doesn’t diagnose the failure class automatically; I name it in the devlog. Without consistent naming, the same failure looks like a new problem next month.
What July 17 means in context
The 16–17 July results show the pipeline functioning correctly: fixes holding, gate operating, no retrieval required. That’s not a fluke. It’s what a working cadence pipeline looks like.
Then 20 July produced a five-casualty morning. The dead-zone fix, verifier and dedupe were still holding. 17 July didn’t break. What broke on 20 July was a combination of checklist rules, CLI reliability and day-cap configuration. Different layers, same morning.
The July 17 milestone doesn’t mean the pipeline is reliable. It means the pipeline is capable of operating correctly when the right layers are working. The taxonomy shows how many distinct layers there are.
What the taxonomy tells you about the rescue loop
My rescue loop in July covered all six failure modes across the month. Manageable at five articles a month. Stops being manageable when cadence targets increase, because the rescue load scales with volume, not with the fixes landed.
Ratio: four interventions, five publishes. Only one article published without rescue. The cadence log shows five publishes; the rescue log shows four interventions and six failure modes. Different numbers measuring different things.
Each failure class has a different fix surface:
- Silent gaps: the composition stage needs better error surfacing; a zero-output cycle should produce a logged reason, not silence
- Composer failures: investigate which cluster classes fail composition and whether the failure is catchable before the compose step
- Checklist casualties: audit which validation rules fail most and whether they’re calibrated for the current content types
- CLI errors: dependency pinning, environment consistency, retry handling
- Day-caps: cadence rule review; if the ceiling prevents otherwise-ready articles from publishing, it’s set wrong for the pipeline’s throughput
- Coverage-screening gap: the check introduced manually on 23 July needs to be a triage gate, not a per-rescue step
None of these are the same fix. The rescue loop handles all of them identically (I retrieve and publish), which makes them look like one problem. They’re six.
The useful measurement
The cadence log counts publishes. The rescue log counts interventions and names failure classes. In July, the cadence log is a lagging indicator of my effort; the rescue log is the leading indicator of what needs fixing.
Count the failure classes in the rescue log, not the publishes in the cadence log. July’s count is six. If August reduces that number by two (the checklist layer and the coverage-screening gap are the most targeted fixes), the log will show it. If August holds at six, something else is generating new failure classes as fast as the old ones are patched.
July named six. That’s the baseline.
