Platform engineers and AI SREs use this prompt to audit whether a model router made the correct choice between retrying the same model and falling back to an alternative. The prompt ingests a production trace segment containing the original failure context, retry budget configuration, and available fallback options. It scores the decision as appropriate, suboptimal, or misconfigured, and produces a structured audit record with misclassification counts. Use this prompt when you need to validate router logic at scale, identify systematic retry-vs-fallback errors, or generate evidence for a router configuration change.
Prompt
Fallback vs Retry Decision Trace Prompt

When to Use This Prompt
Defines the offline audit workflow for validating model router retry-vs-fallback decisions using production trace segments.
This prompt is designed for offline trace analysis and post-hoc audit workflows, not for real-time routing decisions. It requires a complete trace segment that includes the original model response, error metadata, retry budget parameters (max retries, backoff strategy, timeout thresholds), and the list of available fallback models with their capability profiles. The prompt evaluates whether the router exhausted the retry budget appropriately before falling back, whether the fallback model was the correct choice given the request's requirements, and whether any misconfiguration—such as an overly aggressive retry budget or missing fallback options—caused a suboptimal outcome. Each decision receives a classification label and a structured justification that can be aggregated across traces to identify patterns.
Do not use this prompt for real-time routing decisions; it is designed for offline trace analysis and post-hoc audit workflows. It is not a replacement for router configuration validation or live monitoring. The prompt assumes you have already extracted the relevant trace segment and formatted it with the required fields. If your traces lack retry budget metadata or fallback availability context, you will need to enrich them before running this audit. For continuous monitoring of routing health, pair this prompt with the Router Health Check Prompt Template and the Fallback Frequency Trend Analysis Prompt to build a complete observability loop.
Use Case Fit
Where the Fallback vs Retry Decision Trace Prompt works and where it introduces risk.
Good Fit: Post-Incident Forensics
Use when: You have a batch of production traces from a specific time window where users reported high latency or errors. Guardrail: The prompt requires structured trace context (original error, retry count, fallback model invoked) to produce a meaningful audit. Do not run on live traffic.
Good Fit: Router Configuration Tuning
Use when: You are adjusting retry budgets or fallback thresholds and need to validate that the new logic would have prevented past misclassifications. Guardrail: Run the prompt against a golden set of historical traces before deploying the config change. Compare pre- and post-change decision scores.
Bad Fit: Real-Time Decision Making
Avoid when: You need to decide in the hot path whether to retry or fallback. This prompt is an offline audit tool, not a runtime router. Guardrail: Use this prompt to calibrate the router's deterministic rules; do not call an LLM to make the routing decision at request time.
Required Inputs
Risk: Incomplete trace data leads to unreliable audit scores. Guardrail: Ensure each trace includes the original model response, error code or timeout signal, retry count consumed, fallback model identifier, and the router's stated reason for the decision. Reject traces missing these fields.
Operational Risk: Misclassification Blind Spots
Risk: The prompt may score a decision as appropriate when the fallback model was unavailable or degraded, masking a downstream failure. Guardrail: Cross-reference the audit output with fallback model health metrics from the same time window. Flag decisions where the fallback target was unhealthy.
Operational Risk: Retry Budget Exhaustion
Risk: The prompt may classify a retry as correct when the retry budget was exhausted before a viable fallback could be reached. Guardrail: Include retry budget remaining as a required input field. Score decisions where the budget hit zero before fallback as 'retry overrun' rather than 'appropriate retry.'
Copy-Ready Prompt Template
A production-ready prompt for auditing whether a router correctly chose between retrying the same model and falling back to an alternative.
This prompt template is designed to be injected into your trace analysis pipeline. It forces a structured comparison between the retry and fallback paths by examining the failure context, retry budget, and fallback availability captured in a single production trace. The goal is not to generate a fluent explanation, but to produce a machine-readable audit record that scores the decision's appropriateness and flags misclassifications.
textYou are an AI router auditor. Analyze the provided production trace segment and determine whether the router's decision to retry the same model or fall back to an alternative was appropriate. ## INPUT [TRACE_CONTEXT] ## CONSTRAINTS - Evaluate the decision at the moment it was made, not with hindsight. - Consider the retry budget defined in [RETRY_POLICY]. - Consider the fallback availability defined in [FALLBACK_CONFIG]. - Classify the failure type from the trace: [FAILURE_TYPE_OPTIONS]. - Do not invent information not present in the trace. ## OUTPUT_SCHEMA Return a single JSON object with the following fields: { "decision": "retry" | "fallback", "decision_appropriate": true | false, "failure_type": "string", "retry_budget_remaining": number, "fallback_available": true | false, "misclassification_flag": true | false, "misclassification_reason": "string | null", "recommended_action": "string", "confidence": 0.0-1.0 } ## EVALUATION_RUBRIC - Score decision_appropriate as true if the chosen action aligns with the retry policy given the failure type and budget. - Set misclassification_flag to true if the router's action contradicts the policy or if a clearly superior alternative was available. - Set confidence low if the trace contains ambiguous or incomplete failure signals.
To adapt this prompt, replace the square-bracket placeholders with data from your observability pipeline. [TRACE_CONTEXT] should contain the raw trace segment including the original model response, error metadata, and router action. [RETRY_POLICY] should be a structured description of your retry budget rules, such as max attempts per model and backoff strategy. [FALLBACK_CONFIG] should list available fallback models and their activation conditions. [FAILURE_TYPE_OPTIONS] should be an enumerated list of failure categories your system recognizes, such as timeout, rate_limit, quality_threshold, or capability_gap. Before deploying this prompt into an automated pipeline, validate its output against a golden set of 20-30 manually labeled traces to calibrate the confidence threshold and catch schema drift. For high-stakes routing decisions where cost or user impact is significant, route low-confidence audit outputs to a human reviewer before accepting the automated classification.
Prompt Variables
Each placeholder required by the Fallback vs Retry Decision Trace Prompt, its purpose, a concrete example, and validation notes for wiring this prompt into a production trace review harness.
| Placeholder | Purpose | Example | Validation Notes |
|---|---|---|---|
[TRACE_CONTEXT] | Raw trace segment containing the original model response, error metadata, and router decision event | {"model": "claude-3-opus", "status": "timeout", "error_code": "UPSTREAM_TIMEOUT", "retry_count": 2, "fallback_available": true} | Must be valid JSON with model, status, error_code, retry_count, and fallback_available fields. Parse check required before prompt assembly. Null status triggers pre-validation rejection. |
[RETRY_BUDGET] | Maximum retries configured for the primary model before fallback is required | 3 | Must be a positive integer. Compare against retry_count in trace context. If retry_count exceeds budget, decision is automatically flagged as policy violation regardless of model reasoning. |
[FALLBACK_MODEL_CATALOG] | Available fallback models with capability profiles, cost tiers, and latency characteristics | [{"model_id": "claude-3-haiku", "capabilities": ["text-generation", "tool-use"], "cost_tier": "low", "p50_latency_ms": 400}] | Must be a JSON array with at least one entry. Each entry requires model_id, capabilities array, cost_tier, and p50_latency_ms. Missing capability fields cause false capability-gap flags in audit output. |
[ROUTING_POLICY] | Declared routing policy rules that govern retry vs fallback decisions | "Retry primary model up to 3 times for timeout errors. Fallback to haiku-tier model on 4th failure. Never retry on content-policy refusals." | Free text or structured policy object. If structured, validate against policy schema before prompt injection. Policy absence produces 'policy_unavailable' flag in decision audit and prevents adherence scoring. |
[COST_OBJECTIVE] | Configured cost optimization objective for routing decisions | "minimize_total_cost" | Must match enum: minimize_total_cost, minimize_latency, balanced, or maximize_quality. Mismatch between declared objective and trace behavior is a primary audit finding. Null allowed only if cost analysis is out of scope. |
[LATENCY_THRESHOLD_MS] | Maximum acceptable end-to-end latency in milliseconds before fallback is preferred over retry | 2000 | Must be a positive integer. Compare against cumulative latency in trace. If retry would exceed threshold and fallback was available but not used, flag as suboptimal decision. Null allowed if latency analysis is out of scope. |
[DECISION_TIMESTAMP] | UTC timestamp of the routing decision event for correlation with deployment and incident timelines | "2025-03-15T14:32:17Z" | Must parse as ISO 8601 UTC. Used for trend correlation and drift detection. Missing timestamp prevents time-window analysis and produces 'timestamp_missing' warning in audit output. |
[OUTPUT_SCHEMA] | Expected structure for the decision audit output including misclassification counts and per-decision scores | {"decision_id": "string", "appropriateness_score": "appropriate|suboptimal|inappropriate", "misclassification_type": "string|null", "evidence": ["string"]} | Must be a valid JSON Schema object. Validate that prompt output conforms to this schema before accepting audit results. Schema mismatch triggers output repair or retry. |
Implementation Harness Notes
How to wire the Fallback vs Retry Decision Trace Prompt into a trace analysis pipeline or audit workflow.
This prompt is designed to be a batch audit tool, not a real-time decision interceptor. It should be wired into an offline trace analysis pipeline that runs periodically—hourly, daily, or on-demand during incident review. The harness ingests structured trace segments from your observability store, passes them through the prompt, validates the output schema, and writes scored decisions to an audit table. A typical pipeline stage: fetch traces with fallback or retry events from the last window, filter to those where the router made a binary choice, assemble the [TRACE_CONTEXT] payload per the template, call the LLM, and store the structured result.
Validation and retry logic is critical because the output is a structured JSON audit record. Implement a schema validator that checks for required fields (decision_id, observed_choice, recommended_choice, appropriateness_score, misclassification_flag, `rational
Expected Output Contract
Fields, types, validation rules, and pass/fail conditions for the structured output produced by the Fallback vs Retry Decision Trace Prompt.
| Field or Element | Type or Format | Required | Validation Rule |
|---|---|---|---|
decision_id | string (UUID) | Must match a valid UUID v4 format. Parse check via regex. | |
trace_id | string | Must be non-empty and match the source trace identifier. Cross-reference with input. | |
decision_type | enum: retry | fallback | escalate | Must be one of the three allowed values. Schema check. | |
decision_score | number (0.0-1.0) | Must be a float between 0.0 and 1.0 inclusive. Confidence threshold: score < 0.7 triggers human review flag. | |
retry_budget_remaining | integer | Must be >= 0. If null or negative, fail validation. |
Common Failure Modes
What breaks first when auditing fallback vs. retry decisions in production traces and how to guard against it.
Incomplete Trace Context
What to watch: The trace is missing the original error code, model response, or retry budget state, making it impossible to judge whether a retry or fallback was the correct choice. Guardrail: Validate that required trace fields (error signal, attempt count, budget remaining) are present before running the decision audit. Reject incomplete traces and log them for pipeline inspection.
Misclassifying Timeouts as Model Failures
What to watch: The prompt treats a timeout as a permanent model failure and scores a fallback as correct when a retry with backoff would have succeeded. Guardrail: Include explicit timeout-vs-error differentiation in the prompt instructions. Require the audit to flag timeouts separately and check whether retry budget was exhausted before endorsing a fallback.
Ignoring Fallback Availability
What to watch: The audit scores a fallback decision as correct without verifying that the fallback model was actually available and healthy at the time of the request. Guardrail: Cross-reference the fallback activation timestamp with model health metrics. Add a check that penalizes fallback decisions when the target model was degraded or unavailable.
Overfitting to Hindsight Bias
What to watch: The prompt judges the decision based on the eventual outcome rather than the information available at decision time, penalizing reasonable retries that happened to fail. Guardrail: Structure the audit to evaluate the decision given only the pre-decision context (error type, attempt count, latency so far). Mask the final outcome during the initial scoring pass.
Conflating Retry with Identical Request
What to watch: The prompt treats every retry as an identical request, missing cases where the router correctly modified parameters (temperature, stop tokens, prompt truncation) before retrying. Guardrail: Include a parameter-diff check in the audit. Score retries that adjusted parameters higher than blind identical retries, and flag cases where parameter changes should have been tried but weren't.
Missing Cost-Latency Tradeoff Scoring
What to watch: The audit scores decisions as correct or incorrect without considering whether the chosen path (retry vs. fallback) aligned with the configured cost or latency objective. Guardrail: Require the prompt to ingest the routing objective (minimize cost, minimize latency, maximize quality) and weight the decision score accordingly. Flag decisions that optimized the wrong dimension.
Evaluation Rubric
Use this rubric to test the Fallback vs Retry Decision Trace Prompt before shipping it into your production audit pipeline. Each criterion validates a specific aspect of the output against expected behavior for a well-formed decision audit.
| Criterion | Pass Standard | Failure Signal | Test Method |
|---|---|---|---|
Decision Classification Accuracy | Every trace event is classified as retry, fallback, or escalation with a clear primary reason | Unclassified events, ambiguous labels, or missing reason fields in the output | Run against 20 labeled trace samples with known decisions; require >=90% exact match on classification label |
Retry Budget Compliance | Retry count per model does not exceed the configured [RETRY_BUDGET] and each retry is justified by a transient error signal | Retries exceeding budget without explanation or retries on deterministic failures | Parse retry_count from output; assert retry_count <= [RETRY_BUDGET] for all events; flag any retry on non-transient error codes |
Fallback Availability Validation | Fallback is only recommended when [FALLBACK_MODELS] list is non-empty and at least one alternative is available | Fallback suggested when fallback pool is empty or all alternatives are unavailable | Check output.fallback_recommended flag; assert false when [FALLBACK_MODELS] is empty or all marked unavailable in trace context |
Misclassification Count Accuracy | Output.misclassification_count matches the number of events where the router's actual decision differs from the scored appropriate decision | Count mismatch between summary and per-event audit list | Sum the misclassified boolean flags from the per-event audit array; assert equals output.misclassification_count |
Decision Justification Completeness | Each scored decision includes a justification field referencing specific trace evidence (error code, latency threshold, capability gap) | Justification fields that are empty, generic ('seems wrong'), or reference data not present in the trace | Parse justification field for each event; assert length > 20 characters and contains at least one trace field reference (e.g., error_code, latency_ms, model_capability) |
Confidence Score Calibration | Confidence scores are provided per decision and correlate with decision ambiguity (borderline cases get lower scores) | All confidence scores are 1.0 or 0.0 with no intermediate values, or scores are missing entirely | Check confidence_score range is 0.0-1.0; assert standard deviation > 0.1 across a batch of 10 mixed-difficulty traces |
Output Schema Validity | Output matches the [OUTPUT_SCHEMA] exactly with all required fields present and correctly typed | Missing required fields, wrong types, or extra fields not in schema | Validate output against [OUTPUT_SCHEMA] using JSON Schema validator; assert no validation errors |
Latency Attribution Correctness | Cumulative latency attributed to retries and fallbacks sums to within 5% of total trace latency delta | Attributed latency sum deviates >5% from total trace latency or negative latency values appear | Sum retry_latency_ms and fallback_latency_ms fields; assert abs(sum - total_latency_delta_ms) / total_latency_delta_ms <= 0.05 |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Adapt This Prompt
How to adapt
Start with the base prompt and a single trace. Remove strict schema requirements and focus on getting a readable decision classification. Use a frontier model with a simple system prompt that asks: "Was this a retry or a fallback? Was it appropriate?"
codeSystem: You are reviewing a model routing decision. Classify the decision as RETRY or FALLBACK and score appropriateness as APPROPRIATE or INAPPROPRIATE. Explain in one sentence. Trace: [TRACE_JSON]
Watch for
- Overly verbose explanations that bury the classification
- Inconsistent terminology between runs
- No structured output, making batch analysis impossible
- Model hallucinating trace details not present in the input

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us