| 1 | --- |
| 2 | name: "pipeline-fallback-resilience" |
| 3 | description: "Keep multi-stage publishing workflows productive when optional AI services are unavailable." |
| 4 | domain: "quality" |
| 5 | confidence: "high" |
| 6 | source: "Fry triage of crawl-and-publish analyze failure" |
| 7 | date: "2026-06-05T15:36:19.379+00:00" |
| 8 | --- |
| 9 | |
| 10 | ## Context |
| 11 | |
| 12 | Weekly publishing should not fail entirely when an optional AI analysis provider is unavailable, unauthorized, or returns output rejected by quality gates. If crawl data is valid, the pipeline can still publish a clearly labeled data-only artifact. |
| 13 | |
| 14 | ## Patterns |
| 15 | |
| 16 | - Treat model access errors as real pipeline reliability bugs, not transient noise, when they block publication. |
| 17 | - Keep AI output on the preferred path, but add a terminal deterministic fallback that uses already-validated data. |
| 18 | - Run the same quality gate against fallback artifacts so degraded output remains structurally publishable. |
| 19 | - Record the fallback source and model explicitly, such as `source=no-ai` and `model=none`, for later metrics review. |
| 20 | |
| 21 | ## Anti-Patterns |
| 22 | |
| 23 | - Letting an external AI provider outage erase an otherwise valid weekly crawl. |
| 24 | - Bypassing quality gates for fallback output. |
| 25 | - Hiding degraded output as if it were full editorial analysis. |