Fallback Behavior Translation Prompt

This playbook is for reliability engineers and AI platform teams running multi-model systems where a single fallback policy must produce consistent, predictable behavior across providers. When a model cannot complete a task, hits a capability boundary, encounters an error, or must disclose uncertainty, the fallback behavior must degrade gracefully without silent failures, hallucinated completions, or confusing user-facing messages. This prompt translates a canonical fallback policy into model-specific system instructions that respect each provider's native instruction-following patterns, uncertainty expression conventions, and error communication style.

Use this when you have a defined fallback policy and need to produce adapted instructions for each model in your routing mesh. The ideal user brings a concrete fallback policy specification that includes: error categories and their triggers, capability boundary definitions, uncertainty disclosure rules, user-facing message templates, retry guidance, and escalation paths. The prompt works best when you can articulate not just what the fallback behavior should be, but why each rule exists—this intent-level understanding helps the translation preserve behavioral equivalence even when surface-level instruction patterns differ between providers.

Do not use this prompt to invent a fallback policy from scratch; define the policy first, then translate it here. Do not use it when you need runtime fallback logic that requires real-time model health checks, dynamic routing decisions, or circuit-breaker patterns—those belong in the application layer, not the system prompt. Do not use it for single-model deployments where provider-specific adaptation is unnecessary. If your fallback policy includes legal or compliance-mandated language that cannot be paraphrased, bypass translation for those sections and inject them verbatim with explicit immutability markers. After generating adapted instructions, always validate them with cross-model behavioral equivalence tests before deployment.

This prompt template takes a source fallback policy and a target model specification, then produces adapted fallback instructions that map capability boundaries, error conditions, and uncertainty disclosure patterns to the target model's native behavior conventions. Use it when you need consistent graceful degradation across a multi-model deployment where each provider interprets error handling and capability boundaries differently.

codeCopy
SYSTEM INSTRUCTION:
You are a fallback behavior translation specialist. Your task is to adapt a source fallback policy into instructions that produce equivalent graceful degradation behavior on a target model family.

SOURCE FALLBACK POLICY:
[SOURCE_FALLBACK_POLICY]

TARGET MODEL SPECIFICATION:
- Model family: [TARGET_MODEL_FAMILY]
- Provider: [TARGET_PROVIDER]
- Known instruction sensitivities: [TARGET_MODEL_SENSITIVITIES]
- Native error expression patterns: [TARGET_ERROR_PATTERNS]

TRANSLATION CONSTRAINTS:
[CONSTRAINTS]

OUTPUT SCHEMA:
{
  "adapted_fallback_instructions": "string",
  "capability_boundary_mappings": [
    {
      "source_boundary": "string",
      "target_expression": "string",
      "adaptation_rationale": "string"
    }
  ],
  "error_condition_mappings": [
    {
      "source_error": "string",
      "target_error_expression": "string",
      "user_facing_message_template": "string"
    }
  ],
  "uncertainty_disclosure_mappings": [
    {
      "source_uncertainty_level": "string",
      "target_disclosure_pattern": "string",
      "confidence_calibration_note": "string"
    }
  ],
  "silent_failure_detection_rules": [
    {
      "failure_mode": "string",
      "detection_indicator": "string",
      "recovery_instruction": "string"
    }
  ],
  "behavioral_equivalence_notes": "string",
  "known_gaps": ["string"]
}

ADAPTATION RULES:
1. Preserve the behavioral intent of each fallback rule, not the literal wording.
2. Map capability boundaries to the target model's native refusal and limitation expression patterns.
3. Adapt error condition language to match the target model's error communication style.
4. Translate uncertainty disclosure levels to the target model's confidence expression conventions.
5. Add silent failure detection rules specific to the target model's known failure modes.
6. Document any behavioral gaps where the target model cannot fully replicate the source policy.
7. Include user-facing message templates that match the target model's tone conventions.

EXAMPLES:
[EXAMPLES]

RISK LEVEL: [RISK_LEVEL]

If RISK_LEVEL is high, require human review of all adapted instructions before deployment.

Replace each square-bracket placeholder before use. The SOURCE_FALLBACK_POLICY should contain your complete fallback behavior specification, including capability boundary rules, error handling instructions, uncertainty disclosure requirements, and any model-specific patterns you've already validated. The TARGET_MODEL_SENSITIVITIES and TARGET_ERROR_PATTERNS fields should capture what you know about how the target model interprets instructions and expresses errors—this is critical for accurate adaptation. The CONSTRAINTS field should specify any hard requirements that must survive translation, such as mandatory human escalation triggers, prohibited response patterns, or compliance language that cannot be altered.

After generating the adapted instructions, run the output through cross-model behavioral equivalence tests before deployment. Pay special attention to the silent_failure_detection_rules output—these are the patterns most likely to break when porting fallback behavior across model families, because each provider has different default behaviors for handling capability gaps. If the known_gaps array is non-empty, those gaps represent behaviors the target model cannot reliably reproduce, and you'll need compensating controls in the application layer.

The Fallback Behavior Translation Prompt is designed to be called programmatically as part of a policy migration pipeline, not as a one-off chat interaction. In production, this prompt sits between your canonical fallback policy specification and the target model's system instructions. The typical call pattern is: load the canonical fallback policy from your policy registry, load the target model's capability profile and known failure modes, populate the [SOURCE_FALLBACK_POLICY] and [TARGET_MODEL_PROFILE] placeholders, and submit the prompt to a strong instruction-following model (such as Claude 3.5 Sonnet or GPT-4o) that will produce the adapted fallback instructions. The output is a structured artifact that gets reviewed, tested, and then deployed into the target model's system prompt or behavioral policy layer.

Validation and retry logic is critical here because fallback instructions that fail silently create the worst kind of production degradation: the user sees no error and no fallback, just broken behavior. After receiving the translated fallback instructions, run them through a structural validator that checks for required sections (capability boundary declaration, error classification table, uncertainty disclosure template, silent failure detection rules). If the output fails structural validation, retry once with the validation errors appended to the [CONSTRAINTS] field. For high-risk deployments, add a semantic equivalence check using a separate LLM judge prompt that compares the translated fallback behavior against the source policy across a set of predefined failure scenarios. Log every translation attempt—source policy version, target model, timestamp, validator results, and human reviewer—to your prompt observability system. This audit trail is essential when debugging why a specific model degraded differently than expected.

Model choice matters. Use a model with strong instruction-following and structured output capabilities for the translation step itself. The target model (the one receiving the translated fallback instructions) may be weaker or have different parsing behavior, which is exactly why you're adapting the policy. Never use the target model to translate its own fallback policy—this creates a circular dependency where the model's limitations contaminate the translation. For the evaluation step, use a different model family than the translator to avoid correlated failures. Human review should be mandatory for the first translation to a new model family, for any translation where the semantic equivalence score drops below your threshold, and for fallback policies governing high-severity error conditions (data loss, security incidents, compliance failures). After the initial review, subsequent translations of the same policy to the same model family can move to spot-checking if your regression tests pass. Wire the entire pipeline into your CI/CD system so that policy changes trigger automatic re-translation and testing before deployment.