XML Parser Error Recovery Prompt Template

This prompt is for integration engineers and backend developers who receive malformed XML from external systems—upstream partners, legacy services, or user-submitted documents—and need a structured, actionable error report instead of a raw parser exception. The job-to-be-done is not just to identify that an error occurred, but to produce a machine-readable diagnostic with line numbers, recovery suggestions, and a best-effort repaired XML document that can be fed into a downstream validation or retry pipeline. The ideal user is someone who owns an ingestion pipeline and needs to decide programmatically whether to auto-repair, quarantine, or reject a payload based on the severity and type of malformation.

Use this prompt when you have already attempted a strict XML parse and caught a failure, and you now need the model to act as a structured recovery assistant. It is appropriate for common malformation patterns such as unclosed tags, mismatched case in element names, missing namespace declarations, illegal characters, incorrect nesting, or duplicate attributes. It is not appropriate for binary data corruption, encoding-level byte errors, or schema-level semantic violations where the XML is well-formed but logically invalid against an XSD. In those cases, a separate schema validation prompt or a binary repair tool is the correct next step. Do not use this prompt as a replacement for a streaming XML parser or for real-time, high-throughput ingestion where latency and cost make a model call impractical.

Before invoking this prompt, ensure you have captured the raw malformed XML string, the parser error message, and the line and column numbers if available. The prompt template expects these as inputs and uses them to ground the recovery attempt. The output is a structured report, not a conversational explanation, so wire this into an application harness that can parse the JSON response and route the repaired XML to a schema validator. If the repair confidence is low or the malformation involves security-relevant structures like XML signatures or encryption, escalate for human review rather than auto-accepting the repaired document. The next section provides the copy-ready template you can adapt into your error-recovery pipeline.

This prompt template is designed to be dropped into your integration pipeline whenever an upstream system delivers XML that fails standard parsing. It instructs the model to act as a strict XML diagnostician, producing a structured error report and a best-effort repaired document. The template uses square-bracket placeholders for all dynamic inputs, allowing you to inject the raw payload, known schema references, and risk tolerance before each call.

textCopy
You are an XML error recovery specialist. Your task is to analyze a malformed XML document, produce a structured diagnostic report, and generate a best-effort repaired version.

## INPUT
[RAW_XML_PAYLOAD]

## CONTEXT
- Known Schema or DTD: [SCHEMA_REFERENCE or "None provided"]
- Expected Root Element: [ROOT_ELEMENT_NAME or "Unknown"]
- Downstream Parser: [PARSER_NAME_AND_VERSION, e.g., "lxml 4.9.3"]
- Risk Level: [RISK_LEVEL: "conservative" | "moderate" | "aggressive"]
  - conservative: Only fix unambiguous, well-defined errors. Flag all others for human review.
  - moderate: Apply common heuristics for missing quotes, unescaped entities, and mismatched tags.
  - aggressive: Attempt to reconstruct the document structure even with severe corruption. Mark all changes.

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "parse_success": boolean,
  "error_report": {
    "total_errors": integer,
    "errors": [
      {
        "line": integer or null,
        "column": integer or null,
        "error_code": string,
        "severity": "fatal" | "error" | "warning",
        "description": string,
        "raw_snippet": string
      }
    ]
  },
  "recovery_applied": boolean,
  "repaired_xml": string or null,
  "changes_summary": [
    {
      "change_type": "tag_fix" | "quote_fix" | "entity_escape" | "encoding_fix" | "structural_reconstruction" | "other",
      "location_hint": string,
      "original": string,
      "replacement": string,
      "confidence": "high" | "medium" | "low"
    }
  ],
  "human_review_required": boolean,
  "review_reasons": [string]
}

## CONSTRAINTS
- Do not invent content to fill gaps. If a section is irrecoverable, omit it and flag it.
- Preserve all namespace declarations and prefixes exactly as found, unless they are the source of the error.
- If [RISK_LEVEL] is "conservative" and any error has severity "fatal", set "recovery_applied" to false and "repaired_xml" to null.
- Always set "human_review_required" to true if any change has "confidence" of "low".
- If [SCHEMA_REFERENCE] is provided, validate the repaired XML against it and report any remaining schema violations in the error_report.
- Do not wrap the JSON output in markdown code fences.

To adapt this template for your environment, replace the placeholders with your actual runtime values. The [RISK_LEVEL] parameter is the most critical tuning knob: start with "conservative" in production and only move to "moderate" or "aggressive" after reviewing failure patterns over several weeks. If you have an XSD or DTD, always provide it in [SCHEMA_REFERENCE]—this enables the model to catch structural errors that basic well-formedness checks miss. For high-stakes integrations (payments, healthcare, identity), always require human review when "human_review_required" is true, and log the full changes_summary for audit trails.

This prompt is designed to be the core of a repair microservice or a step in an ETL pipeline. It receives malformed XML, a raw parser error, and a target schema, and returns a structured error report alongside a best-effort repaired document. The harness must treat the model as a fallible repair agent, not an oracle. The primary integration point is an API endpoint or a queue consumer that catches XMLSyntaxError or SAXParseException from a standard parser like lxml or javax.xml.parsers, captures the exact error message and line number, and forwards them to the model with the original raw string. The model's output must be validated before the repaired XML is allowed to proceed downstream.

Wiring the pipeline: The application should first attempt a strict parse. On failure, capture the exception object's lineno, offset, and msg fields. Construct the prompt with [MALFORMED_XML] set to the original byte string, [PARSER_ERROR] set to the full exception text, and [TARGET_SCHEMA] set to the expected XSD or a prose description of required elements. The model's JSON output must be parsed and validated: check that repair_report.error_line matches the captured lineno, that repaired_xml is not identical to the input, and that repaired_xml parses successfully with the same strict parser. If the repaired document fails to parse, the harness should retry once by feeding the new parser error back into the prompt as [PARSER_ERROR] with a note that this is a second attempt. If the second attempt also fails, the harness must log the full failure context and route the document to a human review queue rather than silently dropping it.

Model choice and tool use: This task requires strong code and structured data reasoning. Use a model with a large context window and strong JSON mode support, such as gpt-4o or claude-3.5-sonnet. Do not provide the model with a code execution tool for this task; the repair must be a direct text transformation. The harness should, however, use a deterministic post-processing tool to canonicalize the repaired XML (e.g., xmllint --format) before comparing it to the original. For high-throughput pipelines, implement a local cache keyed on a hash of [MALFORMED_XML] + [PARSER_ERROR] to avoid re-prompting for identical failures. Log every repair attempt with the input hash, model version, retry count, and final parse success/failure for observability.

Validation and evals before production: Build a golden test set of 20-30 real-world malformed XML examples: unclosed tags, illegal characters, mismatched case, missing namespaces, and encoding issues. For each, store the expected minimum repair (the document must parse and contain all original text content). Run the harness against this set and measure repair success rate (strict parse passes) and content preservation rate (all original text nodes present in the repaired document). Set a gate: if repair success rate drops below 85% after a prompt or model change, block the release. Additionally, run the prompt against well-formed XML to ensure it does not "repair" valid documents. The harness must reject any repaired document that introduces new elements not present in the original malformed input, as this indicates hallucination.

What to avoid: Do not use the repaired XML for security-critical operations like SAML assertion processing or XML signature verification without human review. The model can fix structure but cannot guarantee semantic integrity. Never expose the raw malformed XML to end users without sanitization, as it may contain injection payloads. Finally, do not wire this prompt directly into a synchronous user-facing flow; the retry loop and model latency make it unsuitable for real-time interactions. It belongs in asynchronous document ingestion pipelines where a 2-5 second repair delay is acceptable.