Fallback Template Selector Prompt Template

This prompt is infrastructure for your prompt assembly pipeline, not a prompt for end users. Its job is to act as a meta-prompt: given a set of candidate fallback templates, a failure reason from the primary prompt (e.g., validation error, token budget exceeded, unsupported input type), and the original user input, it selects the most appropriate fallback and assembles it. Use this when your application has multiple prompt variants for different quality tiers, budget levels, or capability profiles, and you need a programmatic way to degrade gracefully without returning a hard error to the user.

Concrete scenarios where this pattern applies: (1) You have a primary prompt that requires a large context window and a cheaper fallback prompt that uses a compressed summary. When the primary prompt's assembled context exceeds the model's token limit, the selector picks the compressed fallback. (2) You have a structured output prompt that failed schema validation three times. Instead of retrying the same prompt, the selector picks a simpler output schema fallback that trades detail for reliability. (3) You have a tool-use prompt that requires a specific function, but the model doesn't support function calling. The selector picks a text-only fallback that describes the action instead. Do not use this pattern when you have only one prompt variant, when a simple retry loop is sufficient, or when the fallback behavior is static and doesn't require selection logic. A static fallback can be hardcoded in your application without the overhead of an additional model call.

Before implementing this selector, ensure you have defined clear trigger conditions for each fallback path and have evals that measure the quality gap between primary and fallback outputs. The selector itself adds latency and cost, so measure whether the improvement in degraded output quality justifies the additional inference step. If your fallback logic can be expressed as a simple rule (e.g., 'if token budget exceeded, use compressed template'), skip the selector and implement the rule in application code. Reserve this prompt for cases where the fallback choice depends on nuanced properties of the failure and input that a model can assess better than a rules engine.

This template acts as a meta-prompt: it receives a failed primary prompt, the reason for failure, and a library of available fallback strategies, then produces a replacement prompt ready for inference. Use it inside your prompt assembly harness as a recovery step before escalating to a human operator or returning an error to the user. The template is designed to be wrapped in your own validation, logging, and retry logic.

textCopy
You are a fallback prompt assembler for a production AI system. Your job is to produce a replacement prompt when the primary prompt template cannot be used.

INPUTS:
- Failed primary prompt template: [FAILED_PROMPT_TEMPLATE]
- Failure reason: [FAILURE_REASON]
- Available fallback strategies (ordered by preference): [FALLBACK_STRATEGIES]
- Original user request: [USER_REQUEST]
- Output schema required: [OUTPUT_SCHEMA]
- Risk level of this request: [RISK_LEVEL]
- Token budget remaining: [TOKEN_BUDGET]

INSTRUCTIONS:
1. Read the failure reason and determine which fallback strategy from the list is most appropriate.
2. Assemble a complete, self-contained prompt that:
   - Preserves the original user intent from [USER_REQUEST].
   - Produces output conforming to [OUTPUT_SCHEMA].
   - Fits within [TOKEN_BUDGET] tokens.
   - Respects the risk level [RISK_LEVEL] by adjusting instruction strictness and refusal sensitivity.
3. If no fallback strategy can safely handle the request at the given risk level, produce a safe refusal prompt instead.
4. Return ONLY the assembled prompt text. Do not include explanations, commentary, or metadata.

CONSTRAINTS:
- Never include unresolved placeholders in the assembled prompt.
- For RISK_LEVEL = 'high', include explicit human-review and source-grounding instructions.
- For RISK_LEVEL = 'critical', produce a refusal prompt that explains the escalation path.
- The assembled prompt must be ready for immediate inference with no further substitution.

Adapt this template by replacing the square-bracket placeholders with values from your prompt assembly pipeline. The [FALLBACK_STRATEGIES] input should be an ordered list of strategy descriptions—for example, 'remove few-shot examples and rely on instructions only,' 'switch to a smaller model with simplified instructions,' or 'return a safe canned response.' Wire this template into your error-handling path so it fires after preflight validation detects a failure. Always log the assembled fallback prompt alongside the trace ID for post-hoc debugging, and consider adding a human approval gate when the risk level is high or critical.

The Fallback Template Selector is not a standalone prompt; it is a control-plane component that sits between your primary prompt assembly logic and the model inference call. When the primary template fails preflight validation—missing variables, token budget overflow, schema mismatch, or instruction contradiction—the selector receives the failure signal, the original input, and a catalog of available fallback templates. Its job is to choose the least-degraded alternative and return a template identifier plus any required parameter remapping. This decision must be fast, deterministic enough to debug, and auditable so operators can trace why a fallback was triggered in production.

Wire the selector into your prompt assembly pipeline as a gated step. Before inference, run your primary assembly and validation checks. If validation passes, proceed directly to inference. If validation fails, construct a structured context object containing: the original [USER_INPUT], the [FAILURE_REASON] (e.g., token_overflow, missing_variable, schema_conflict), the [PRIMARY_TEMPLATE_ID], and a [FALLBACK_CATALOG] array of available templates with their constraints and capabilities. Pass this context into the Fallback Template Selector prompt. Parse the output strictly—expect a JSON object with selected_template_id, parameter_mapping (a map from primary variable names to fallback variable names), and degradation_notes. Validate that the selected template actually exists in your catalog and that all required fallback variables are resolvable before proceeding to assembly and inference. Log the full decision path: primary failure, selector input, selector output, and final template used.

Implement retry and escalation boundaries around the selector itself. If the selector returns an invalid template ID, a template that also fails validation, or malformed JSON, do not loop indefinitely. After one retry with a simplified catalog, escalate to a static safe-fallback template—a minimal prompt that either asks the user to rephrase or returns a controlled degradation message. For high-risk domains, inject a human review step when the fallback path is activated, especially if the degradation notes indicate that key constraints (safety policies, PII handling, output schema) are weakened in the fallback template. Monitor fallback activation rates, selector accuracy, and degradation severity in production. A rising fallback rate signals that your primary templates need redesign, not that the selector is working well.