Fallback Mechanism Design Review Prompt

This prompt is for engineering teams designing fallback responses when primary services are unavailable. Use it when you have a concrete fallback design—cached responses, static defaults, degraded functionality, or stale-data strategies—and need a structured review before implementation. The ideal user is a backend engineer, SRE, or architect who understands the dependency graph and can provide the primary service contract, the proposed fallback chain, and the expected user impact for each degradation tier. The prompt is not a substitute for load testing or chaos engineering; it is a design review that catches missing fallback paths, data freshness violations, and incomplete recovery triggers before they reach production.

The prompt requires several concrete inputs to be useful. You must supply the primary service description, the full fallback chain (from ideal response to last-resort static default), the data freshness requirements for each tier, and the expected trigger conditions that activate each fallback level. Without these, the review will produce generic advice instead of actionable findings. The prompt also expects you to define the acceptable staleness window for cached data and the user-facing degradation message for each fallback tier. If your team has not yet defined these, complete that design work first—this prompt reviews a design, it does not create one from scratch.

Do not use this prompt for runtime fallback decisions or live traffic routing. It is a static design review, not a real-time policy engine. It will not tell you whether a specific request should hit the cache or the primary; it will tell you whether your fallback tiers are complete, whether your staleness thresholds are coherent, and whether any fallback path silently drops data the user expects to see. After running the review, take the findings into your architecture decision record or resilience design doc. The next step is to implement the reviewed fallback chain and validate it with fault injection testing—this prompt identifies design gaps, but only production-like testing proves the fallback actually works.

This prompt template is designed to be copied directly into your AI harness, evaluation pipeline, or internal review tool. It expects you to supply the system design document, the list of primary dependencies, the current fallback plan, and the risk tolerance level. The model will produce a structured review identifying gaps in fallback coverage, stale-data risks, and missing recovery triggers. All placeholders use square brackets so you can safely replace them with your own values without conflicting with model syntax.

textCopy
You are a senior reliability engineer reviewing a fallback mechanism design for a production system. Your review must be structured, evidence-based, and focused on preventing silent failures and degraded user experience.

## INPUTS
- System Design Document: [SYSTEM_DESIGN]
- Primary Dependency List: [DEPENDENCIES]
- Current Fallback Plan: [FALLBACK_PLAN]
- Acceptable Data Freshness Window: [FRESHNESS_WINDOW]
- Risk Tolerance Level: [RISK_TOLERANCE]

## OUTPUT SCHEMA
Return a JSON object with the following fields:
{
  "fallback_chain_completeness": {
    "score": "PASS|WARN|FAIL",
    "missing_fallbacks": ["dependency_name"],
    "rationale": "string"
  },
  "data_freshness_risks": [
    {
      "dependency": "string",
      "cached_response_ttl": "string",
      "violates_freshness_window": true,
      "stale_data_impact": "string"
    }
  ],
  "degraded_functionality_gaps": [
    {
      "feature": "string",
      "current_fallback": "string",
      "user_impact": "string",
      "recommended_improvement": "string"
    }
  ],
  "recovery_trigger_audit": {
    "automatic_triggers_defined": ["string"],
    "manual_triggers_required": ["string"],
    "missing_triggers": ["string"]
  },
  "static_default_acceptability": [
    {
      "default_value": "string",
      "scenario": "string",
      "acceptable": true,
      "conditions": "string"
    }
  ],
  "overall_assessment": {
    "risk_level": "LOW|MEDIUM|HIGH|CRITICAL",
    "top_three_actions": ["string"],
    "ready_for_production": true
  }
}

## CONSTRAINTS
- Only flag a missing fallback if the dependency is in the primary dependency list and no fallback is documented.
- A data freshness violation occurs when the cached response TTL exceeds the acceptable freshness window.
- Static defaults are acceptable only if they do not mislead users into believing they are seeing live data.
- Do not invent dependencies or fallbacks not present in the inputs.
- If the fallback plan is incomplete, set ready_for_production to false and explain why.

## EVALUATION CRITERIA
- Every primary dependency must have at least one documented fallback.
- Every fallback must specify whether it returns cached data, a static default, or degraded functionality.
- Cached data fallbacks must declare their TTL and whether the TTL violates the freshness window.
- Recovery triggers must distinguish between automatic recovery and manual intervention paths.
- The overall assessment must prioritize actions by user impact, not by implementation difficulty.

To adapt this template, replace each square-bracket placeholder with your actual system context. The [SYSTEM_DESIGN] should include enough architectural detail for the model to understand which components depend on which services. The [FALLBACK_PLAN] can be a structured document, a table, or a narrative description of what happens when each dependency fails. If you are using this prompt inside an automated pipeline, wire the output schema into your validation layer so that any FAIL or CRITICAL result blocks the release. For high-risk systems, always route the model's output to a human reviewer before accepting the assessment.

This prompt is designed to be called programmatically as part of a design review pipeline, not as a one-off chat interaction. The primary integration point is a CI/CD or architecture review workflow where a design document, configuration file, or structured specification is submitted, and the model returns a structured fallback review. The harness must validate the output against the expected schema before accepting it, because a malformed review is worse than no review—it creates false confidence.

Wire the prompt into an application by first assembling the input context: the primary service definition, its dependencies, the proposed fallback mechanism (cached response, static default, degraded functionality, or stale-data allowance), and any relevant SLA or freshness requirements. Pass these as the [SERVICE_SPEC], [FALLBACK_DESIGN], and [CONSTRAINTS] placeholders. On the output side, enforce the expected JSON schema with fields like fallback_chain_completeness, data_freshness_violations, degraded_functionality_gaps, and recommendations. Use a schema validator immediately after model response. If validation fails, retry once with the validation errors injected into the [PREVIOUS_ERRORS] field of a retry prompt variant. If the second attempt also fails, log the raw output and escalate to a human reviewer. For high-risk services (payment, auth, health data), always require human approval before closing the review, regardless of validation success.

Model choice matters here. Use a model with strong structured output support and a large context window, since service specs and dependency graphs can be verbose. GPT-4o or Claude 3.5 Sonnet are appropriate defaults. Enable structured output mode if the provider supports it (e.g., OpenAI's response_format with a JSON schema). Log every review attempt—input hash, model version, output, validation result, and reviewer decision—so you can trace regressions when the prompt or model changes. The most common production failure mode is the model accepting an incomplete fallback chain as sufficient because it didn't check every downstream dependency. Mitigate this by post-processing the output: cross-reference the fallback_chain_completeness list against the dependency graph extracted from [SERVICE_SPEC] and flag any dependency without a corresponding fallback entry.