Truncated String Escape Repair Prompt Template

This prompt template is designed for platform engineers and API gateway operators who need to repair string literals that were severed mid-escape-sequence during model generation. The core job is to take a truncated string—where a backslash, quote, or Unicode escape was cut off by a token limit or streaming interruption—and normalize it into a valid, parseable string literal without corrupting the surrounding content. This is not a general string sanitizer; it is a targeted repair tool for the specific failure mode where a model's output was interrupted inside an escape boundary.

The ideal user has a partial model output that failed downstream JSON parsing, string interpolation, or serialization because of a broken escape sequence like "value (missing closing quote), \u00 (truncated Unicode), or \\n\ (dangling backslash). You must provide the raw truncated string as [INPUT] and, critically, the expected string delimiter context as [CONTEXT]—for example, whether the string was double-quoted, single-quoted, or backtick-delimited. Without this delimiter context, the model cannot reliably distinguish between a truncated escape and a legitimate trailing backslash. The prompt assumes the surrounding payload structure is otherwise intact; if the entire output is corrupted, use a broader structural repair prompt instead.

Do not use this prompt when the truncation point is unknown or when the string content is semantically ambiguous. If the broken string contains user-generated content, PII, or security-sensitive data, ensure redaction happens before this repair step. This prompt is not a validator—it repairs escape sequences to produce a parseable string, but it does not guarantee the semantic correctness of the repaired content. Always follow repair with a parse test and, for high-risk pipelines, a human review gate before the output enters production systems or user-facing surfaces.

This template is designed to be dropped directly into your repair pipeline when a model output contains a string that was severed mid-escape sequence. The prompt instructs the model to act as a deterministic string normalizer, repairing common breakages like unclosed quotes, dangling backslashes, and incomplete Unicode escapes without altering the surrounding content or inventing new data. Use this as the core instruction block in a post-generation validation loop.

textCopy
You are a precise string escape repair function. Your only job is to normalize a truncated string literal into a valid, parseable string.

[INPUT_STRING]

[CONTEXT]
- The input string was truncated during generation. It may contain broken escape sequences, unclosed quotes, or dangling backslashes.
- The original encoding is [ENCODING].
- The expected string delimiter is [DELIMITER].

[CONSTRAINTS]
1. Repair the string so that it is a valid literal in the target language [TARGET_LANGUAGE].
2. Do not change any character that is already valid.
3. If a backslash is the final character, remove it.
4. If an incomplete Unicode escape (e.g., \u00) is found, remove the incomplete sequence.
5. If the string is missing a closing delimiter, append it.
6. Do not add, infer, or hallucinate any content beyond the repair.
7. If the string is already valid, return it unchanged.

[OUTPUT_SCHEMA]
Return a JSON object with the following structure:
{
  "repaired_string": "the normalized string literal",
  "repair_actions": ["list of specific actions taken, e.g., 'removed trailing backslash', 'appended closing quote'"],
  "is_valid": true
}

[EXAMPLES]
Input: "broken string with backslash\
Output: {"repaired_string": "broken string with backslash", "repair_actions": ["removed trailing backslash"], "is_valid": true}

Input: "unescaped quote in "middle"
Output: {"repaired_string": "unescaped quote in \"middle\"", "repair_actions": ["escaped internal double quotes"], "is_valid": true}

Input: "valid string"
Output: {"repaired_string": "valid string", "repair_actions": [], "is_valid": true}

To adapt this template, replace the square-bracket placeholders with your specific runtime values. [TARGET_LANGUAGE] should be set to the programming language whose string literal rules you are targeting (e.g., Python, JavaScript, JSON), as escape rules differ. [ENCODING] is typically UTF-8. [DELIMITER] is usually a double quote. The [INPUT_STRING] should be injected as a raw string literal, not pre-escaped, so the model sees the exact broken sequence. For high-risk pipelines where the repaired string feeds into code execution or security-sensitive contexts, always validate the is_valid flag and log the repair_actions for auditability before accepting the output.

This prompt is designed as a post-generation repair step, not a primary generation interface. It should be invoked by an application harness immediately after a model output fails a string-literal or escape-sequence validation check. The harness must extract the exact substring containing the broken escape sequence, pass it as [TRUNCATED_STRING], and provide the expected [STRING_CONTEXT] (e.g., JSON, CSV, YAML, or raw code) so the repair model understands the quoting and escaping rules that apply. Do not send the entire payload; sending only the damaged segment reduces token cost and prevents the model from altering unrelated valid content.

Wire the prompt into a retry loop with a strict validator. After receiving the repaired string, the harness must run a language-appropriate parser (e.g., json.loads for JSON, Python's ast.literal_eval for Python strings, or a CSV parser with QUOTE_MINIMAL settings) to confirm the output is parseable. If parsing fails, retry up to two more times with the same prompt, appending the parser's error message to [CONSTRAINTS] as additional guidance. After three failures, log the original truncated string, all repair attempts, and the final failure reason, then escalate to a dead-letter queue for human review. For high-throughput pipelines, use a fast, cost-optimized model like GPT-4o-mini or Claude Haiku for the repair step, reserving larger models only for cases where the fast model fails twice.

Implement structured logging that captures the repair_id, original_truncated_string, repaired_string, parser_success (boolean), retry_count, and model_used for every invocation. This log becomes your eval dataset for measuring repair accuracy over time. For critical systems where a malformed string could cause data corruption or injection vulnerabilities, add a human-approval gate for any repair that modifies more than 20% of the original truncated string's character length, as this may indicate the model hallucinated content rather than repairing escapes. Avoid using this prompt on strings that contain executable code or SQL; those require sandboxed validation and should never be repaired and executed without human review.