Environment-Aware Fallback Behavior Prompt

This prompt is for reliability engineers and platform teams who need to encode a single, testable policy for how an AI assistant degrades when its dependencies fail. The core job-to-be-done is preventing silent failures, inappropriate fallback to mock data, and the exposure of internal error details to end users. The ideal user is an engineer who already has a system prompt for their assistant and is now hardening its operational behavior. They understand that a try-except block in application code is not enough; the assistant's language and disclosed reasoning must also change based on the deployment environment. Required context includes a defined list of the assistant's external dependencies (APIs, databases, model endpoints), a clear mapping of those dependencies' availability per environment (dev, staging, production), and a set of approved fallback responses for each failure mode.

You should use this prompt when your assistant's behavior must differ materially between a development environment and a production environment during a dependency failure. For example, if a vector database is unreachable in dev, the assistant should state clearly that it is using mock data for testing purposes and not to trust the results. In production, the same failure should trigger a specific retry policy (e.g., three attempts with exponential backoff), a user-facing message that avoids exposing infrastructure details ('I'm having trouble accessing my knowledge base right now'), and an escalation to a human operator with a structured error code like FALLBACK_DB_UNREACHABLE. This prompt is not a generic error message generator; it is a system-level instruction that gates the assistant's entire response strategy based on an [ENVIRONMENT] variable.

Do not use this prompt if your application can handle all fallback logic entirely in the non-AI application layer without the model needing to generate a natural language explanation. If a simple HTTP 500 error page is sufficient, this prompt adds unnecessary complexity. Similarly, avoid this prompt if you are not prepared to inject a reliable [ENVIRONMENT] tag into every request context. An incorrect or missing environment tag will cause the assistant to apply the wrong fallback policy, potentially exposing mock data in production or escalating a dev failure to a real on-call engineer. This playbook is a starting point for a critical reliability pattern; the next step is to adapt the template's placeholders to your specific dependency map and rigorously test the failure modes in a staging environment before production deployment.

This prompt template defines a structured fallback policy for an AI assistant operating in a specific deployment environment. It instructs the model on how to detect unavailable dependencies, select an appropriate degradation path, and communicate transparently with the user. The template is designed to be injected into your existing system instructions. All square-bracket placeholders must be replaced at runtime by your application's context assembly layer before the prompt reaches the model.

codeCopy
## Environment Context
You are operating in the [DEPLOYMENT_ENVIRONMENT] environment.
Current feature flags: [FEATURE_FLAG_STATE]
Available tools: [AVAILABLE_TOOL_LIST]
Available models for routing: [AVAILABLE_MODEL_LIST]

## Fallback Policy
When you detect that a required tool, model, or service is unavailable, you must follow this degradation sequence:

1.  **Detect:** Identify the specific unavailable dependency from the error or timeout.
2.  **Classify:** Determine the severity of the failure:
    - **Critical:** The user's primary request cannot be fulfilled in any capacity.
    - **Degraded:** The request can be partially fulfilled using an alternative path.
    - **Transient:** The failure appears temporary (e.g., a timeout).
3.  **Select Fallback:** Choose the first applicable action from the list below:
    - If [RETRY_ENABLED] is true and the failure is Transient, retry the call up to [MAX_RETRIES] times with exponential backoff.
    - If a less-capable alternative tool exists in [AVAILABLE_TOOL_LIST], use it and note the degraded capability.
    - If a smaller or local model exists in [AVAILABLE_MODEL_LIST], route the request there with a modified prompt: [FALLBACK_MODEL_PROMPT_TEMPLATE].
    - If [MOCK_DATA_ENABLED] is true AND the environment is NOT 'production', respond with mock data and prepend the warning: "[MOCK_DATA_WARNING]"
    - Otherwise, escalate to a human operator with a clear summary of the failure.
4.  **Disclose:** Always inform the user of the action taken. Use this disclosure template: "I encountered an issue with [FAILED_DEPENDENCY]. I am now using [FALLBACK_METHOD]. [CAPABILITY_IMPACT_STATEMENT]"

## Critical Safety Override
Regardless of the fallback policy above, if [MOCK_DATA_ENABLED] is true and the environment IS 'production', you must NEVER use mock data. You must escalate to a human operator immediately.

To adapt this template, replace the placeholders with values from your deployment context. The [FALLBACK_MODEL_PROMPT_TEMPLATE] should be a concise instruction for a smaller model, such as "Answer the user's question based on your general knowledge, but state that you cannot access real-time data." The [MOCK_DATA_WARNING] should be a clear, standardized string like "[WARNING: This response contains simulated data for testing purposes.]" Ensure that the logic for setting [MOCK_DATA_ENABLED] is airtight in your application code, as a misconfiguration here is a high-risk failure mode. After integrating this prompt, you must test it against the failure modes described in the 'Testing and Evaluation' section of this playbook.

The Environment-Aware Fallback Behavior Prompt is not a standalone artifact; it is a decision engine that must be integrated into your application's control flow. The prompt's job is to receive a structured context block containing the current [ENVIRONMENT], [FAILED_COMPONENT], [ERROR_CONTEXT], and [AVAILABLE_ALTERNATIVES], and return a structured fallback plan. Your application harness is responsible for assembling this context, calling the model, validating the output, and executing the chosen fallback action. This separation ensures the model only decides what to do, while your application enforces how and when it is done.

Wire the prompt into a dedicated FallbackOrchestrator service that is invoked by your global error handler or circuit breaker. The orchestrator should first check a local cache for a previously determined fallback for the same component and environment to avoid unnecessary model calls. If no cache hit exists, construct the prompt context by pulling the deployment environment from an environment variable (DEPLOYMENT_ENV), the failed component name from the error source, and a list of available alternatives from a service registry. Validation is critical: the model's JSON output must be parsed and validated against a strict schema that requires a fallback_action (e.g., use_cached, retry, escalate, degrade), a user_disclosure string, and a retry_policy object. If validation fails, log the raw output and fall back to a hardcoded safe default for the environment—typically escalate in production and use_mock in development.

Implement retry logic at the application level, not inside the prompt. If the model call fails or times out, retry once with an exponential backoff. On a second failure, bypass the model entirely and use the hardcoded environment-specific fallback. Log every fallback event to your observability platform with the environment, component, chosen action, and a hashed user disclosure for later audit. In production, never allow the model to select a fallback that uses mock data or bypasses authentication. Enforce this by maintaining a blocklist of forbidden actions per environment that is checked after successful validation. Before shipping, test the harness by simulating tool outages in a staging environment and verifying that the correct fallback is selected, the user disclosure is appropriate, and no production-only actions are triggered.