Multi-Format Output Repair Router Prompt

This prompt is for AI platform architects and backend engineers who operate inference pipelines that consume structured output from multiple models or endpoints. The job-to-be-done is format-agnostic repair routing: a single entry point receives a malformed payload—which could be JSON, XML, YAML, CSV, or a typed object—and must classify the format, route it to the correct repair sub-prompt, and return a unified repair result. The ideal user is someone building a production repair harness who cannot afford to maintain separate classification logic for each format and needs a single prompt that acts as the dispatcher before specialized repair begins.

Use this prompt when your pipeline accepts heterogeneous structured outputs and validation failures can occur in any format. It is appropriate when you already have format-specific repair prompts (e.g., a JSON Schema Validation Retry Prompt, an XML Malformed Structure Correction Prompt, a CSV Field Count Mismatch Repair Prompt) and need a router to avoid manual triage. The prompt requires the raw malformed output, the expected output schema or format specification, and any validator error messages as input. It returns a structured routing decision with the detected format, a pointer to the appropriate repair sub-prompt, and a pre-populated repair context.

Do not use this prompt when you only deal with a single output format—a dedicated repair prompt will be simpler and more reliable. Avoid it when the malformed output is so severely corrupted that format detection itself is unreliable; in those cases, escalate directly to a human or a partial salvage workflow. This prompt is a router, not a repairer: it classifies and dispatches, but the actual correction happens downstream. If your retry budget is exhausted or the confidence in format detection is low, the prompt should return an escalation decision rather than guessing the format. Wire the output into a harness that logs the routing decision, tracks which repair sub-prompt was invoked, and measures end-to-end repair success so you can identify format-specific failure patterns over time.

This prompt acts as the central dispatcher in a multi-format repair pipeline. Instead of guessing which repair strategy to apply, the model first inspects the failed output and any validation errors to determine the target format, then routes the payload to the appropriate repair sub-prompt. The output is a single structured envelope containing the corrected payload, the detected format, a repair confidence score, and any format-specific diagnostics that downstream systems need for logging or escalation.

codeCopy
You are a format-agnostic output repair router. Your job is to inspect a failed model output, determine its intended format, and route it to the correct repair procedure.

## INPUT
Failed Output:

[FAILED_OUTPUT]

codeCopy

Validation Errors (if available):

[VALIDATION_ERRORS]

codeCopy

Original Prompt Context (for semantic preservation):
[ORIGINAL_PROMPT_CONTEXT]

## TARGET SCHEMA (optional, if known)
[TARGET_SCHEMA]

## ROUTING RULES
1. Detect the intended format from the failed output and any error messages. Supported formats: JSON, XML, YAML, CSV, Typed Object (TypeScript/Python/Java interface).
2. If the format is ambiguous, default to the format specified in [TARGET_SCHEMA]. If still ambiguous, return a `format_undetermined` error.
3. Route to the appropriate repair sub-prompt based on detected format:
   - JSON: Fix trailing commas, unquoted keys, single quotes, bracket mismatches, and schema violations.
   - XML: Repair unclosed tags, missing root elements, namespace issues, and CDATA errors.
   - YAML: Normalize indentation, fix tab characters, correct nesting levels.
   - CSV: Realign columns, fix field count mismatches, handle quote escaping.
   - Typed Object: Rename properties, remove readonly fields, resolve union types, inject optional defaults.
4. Preserve all semantic content. Do not invent data to fill gaps unless a safe default is specified in [TARGET_SCHEMA].
5. If the output is truncated (incomplete), flag it as `truncated` and repair only the recoverable portion.

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "detected_format": "json" | "xml" | "yaml" | "csv" | "typed_object" | "format_undetermined",
  "repair_success": true | false,
  "repaired_output": "<the corrected payload as a string>",
  "repair_confidence": 0.0 to 1.0,
  "repair_actions": [
    {
      "action": "<description of what was fixed>",
      "location": "<field path, line number, or XPath>",
      "original": "<the broken fragment>",
      "repaired": "<the corrected fragment>"
    }
  ],
  "unrecoverable_fields": ["<field paths that could not be repaired>"],
  "truncated": true | false,
  "escalation_reason": "<null or reason if repair_success is false>"
}

## CONSTRAINTS
- Do not modify the semantic meaning of the original output.
- If a field value is ambiguous, prefer preserving the original over guessing.
- Flag any destructive changes in `repair_actions` with a note.
- If [RISK_LEVEL] is "high", set `repair_confidence` conservatively and escalate borderline cases.

To adapt this template, replace the square-bracket placeholders with your pipeline's actual inputs. [FAILED_OUTPUT] should receive the raw model response that failed validation. [VALIDATION_ERRORS] can be the raw error output from libraries like Ajv, Pydantic, or Xerces—the router uses these to confirm the format and identify specific fault locations. [ORIGINAL_PROMPT_CONTEXT] is critical for semantic preservation; include the user's original request and any system instructions so the repair doesn't drift from intent. If you know the target schema, provide it in [TARGET_SCHEMA] to eliminate format ambiguity. Set [RISK_LEVEL] to "high" for regulated or customer-facing workflows to force conservative confidence scoring and escalation of borderline repairs. Wire this prompt as the first stage in a repair harness, then pass the repaired_output field to your downstream parser after checking repair_success and repair_confidence against your operational thresholds.

The Multi-Format Output Repair Router is designed to sit immediately after a primary model response and its first-pass validation failure. In a production harness, you should not call this prompt directly from user-facing code. Instead, wrap it in a repair service that receives the raw model output, the expected output schema (JSON Schema, XSD, or a typed interface definition), and the original validation error. The service then calls this router prompt to classify the format, select the appropriate repair sub-prompt, and return a unified repair result. This indirection lets you swap repair strategies, add format-specific preprocessors, and log every repair attempt without changing the router prompt itself.

The harness must enforce a strict retry budget. Configure a maximum of 2-3 repair attempts per output. On each attempt, feed the router's repair_result and format_diagnostics back into the appropriate sub-prompt if the output still fails validation. Between attempts, increment a counter and check it against your threshold. If the budget is exhausted, do not retry again. Instead, invoke the Escalation Threshold Prompt to decide whether to return a partial result, request human review, or fail the request with a structured error. Log every attempt, the repair actions taken, and the final disposition for observability and debugging.

For model choice, use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are good defaults. Avoid smaller or older models that may struggle with multi-step classification and repair tasks. Set temperature to 0 or near-zero to minimize variability in repair decisions. If your pipeline uses tool calling, the router can be implemented as a tool that the primary agent calls when its output fails validation, but prefer a dedicated repair service for reliability and independent retry control.

Validation is the gate. After the router returns a corrected_payload, run it through the same schema validator that rejected the original output. If it passes, return the payload to the calling application. If it fails, check the repair_confidence score. For high-confidence repairs (≥0.9) that still fail, log the mismatch as a potential validator bug or schema ambiguity. For low-confidence repairs (<0.7), escalate immediately without consuming further retry budget. Always attach the format_diagnostics and repair_log to your observability traces so operators can audit what the router changed and why.

When wiring this into a production system, ensure the harness handles partial failures gracefully. If the router itself times out or returns malformed JSON, catch that exception, log the raw response, and fall back to the Partial Output Salvage Prompt to extract any valid fields. Never let a repair failure crash the entire inference request. Finally, set up a dashboard or alert on repair attempt counts and escalation rates—rising trends often signal schema changes, model drift, or an increase in edge-case inputs that need new few-shot examples in the repair sub-prompts.