Output Format Contract Violation Escalation Prompt

This prompt is designed for API and integration engineers who depend on structured output contracts from language models. Its primary job is to act as a programmatic gate: when a model's response fails to conform to a predefined schema, this prompt generates a machine-readable violation record instead of allowing malformed data to propagate downstream. Use it when your application logic, database insert, or next pipeline stage will break on unexpected fields, missing required keys, or incorrect data types. The ideal user is building a production system where schema adherence is a hard requirement, not a preference.

The prompt requires a specific set of inputs to function correctly. You must provide the raw model output string to be validated ([RAW_OUTPUT]), the exact expected schema definition ([EXPECTED_SCHEMA]) in a standard format like JSON Schema, and a unique identifier for the request context ([REQUEST_ID]). The output is a strict JSON object containing a violation_detected boolean, a severity classification (e.g., BLOCKING, WARNING), and a detailed violations array where each entry pinpoints the exact field path, the reason for failure, and the offending value excerpt. This structured output is designed to be ingested by an error-handling middleware, a dead-letter queue, or a monitoring system, not read by an end-user.

Do not use this prompt for casual output inspection or as a general-purpose quality check. It is not a substitute for a deterministic JSON Schema validator like ajv in your application code; rather, it is a complementary tool for cases where the model's output is too malformed for a standard validator to parse, or when you need a natural language explanation of the failure alongside the structured error. Avoid using it for high-throughput, low-latency paths where the added model inference time is unacceptable. The next step after generating this violation record is to feed it into a retry or repair workflow, or to escalate it to a human review queue if the contract is critical and automatic repair is unsafe.

This prompt template is designed to be inserted into a post-generation validation pipeline. It receives the raw model output and the expected schema contract, then produces a machine-readable violation record when the output breaks format expectations. The template uses square-bracket placeholders that must be populated by the calling application before inference. Use this prompt when you need structured escalation records for schema violations rather than simple pass/fail flags.

textCopy
You are an output format contract validator. Your job is to compare a model-generated output against an expected schema contract and produce a structured violation record when the output breaks format expectations.

## INPUT

**Expected Schema Contract:**
[EXPECTED_SCHEMA]

**Model Output to Validate:**
[MODEL_OUTPUT]

**Schema Contract Type:** [CONTRACT_TYPE]  // e.g., JSON Schema, Pydantic model, TypeScript interface, XML Schema, regex pattern

**Validation Context:** [VALIDATION_CONTEXT]  // e.g., "API response generation", "data extraction pipeline", "structured logging"

## INSTRUCTIONS

1. Parse the expected schema contract to understand required fields, types, constraints, enums, and structure.
2. Attempt to parse the model output according to the contract type.
3. If the output is valid, respond with `{"valid": true, "violations": []}`.
4. If the output violates the contract, produce a violation record with field-level error details.

## OUTPUT SCHEMA

Return a JSON object with this structure:
{
  "valid": boolean,
  "violations": [
    {
      "field_path": string,          // JSONPath or XPath to the violating field
      "expected_type": string,       // Expected type or constraint
      "actual_value": string,        // Truncated actual value (max 200 chars)
      "violation_type": string,      // One of: MISSING_REQUIRED, WRONG_TYPE, INVALID_ENUM, PATTERN_MISMATCH, EXTRA_FIELD, STRUCTURE_ERROR, CONSTRAINT_VIOLATION, UNPARSABLE
      "severity": string,            // One of: BLOCKING, WARNING
      "message": string,             // Human-readable error description
      "remediation_hint": string     // Suggested fix or repair strategy
    }
  ],
  "summary": {
    "total_violations": number,
    "blocking_count": number,
    "warning_count": number,
    "first_violation_at": string    // Field path of first violation
  },
  "repair_viability": string,       // One of: AUTO_REPAIRABLE, MANUAL_REPAIR_REQUIRED, UNRECOVERABLE
  "escalation_recommended": boolean // True if severity is BLOCKING or repair is UNRECOVERABLE
}

## CONSTRAINTS

- Do not hallucinate violations. Only report actual contract breaches.
- Truncate actual_value fields to 200 characters maximum.
- If the output is completely unparsable (not valid JSON, XML, etc.), set violation_type to UNPARSABLE and field_path to "$root".
- For MISSING_REQUIRED fields, set actual_value to null.
- Severity is BLOCKING if the violation prevents downstream consumption. Use WARNING for deprecations or non-critical format issues.
- Set escalation_recommended to true when any violation is BLOCKING or repair_viability is UNRECOVERABLE.

## EXAMPLES

[EXAMPLES]

## RISK LEVEL

[RISK_LEVEL]  // e.g., "HIGH - downstream systems depend on strict schema compliance"

Adaptation guidance: Replace [EXPECTED_SCHEMA] with the actual schema definition in the format your system uses (JSON Schema, Pydantic model, TypeScript interface, or a plain-text field specification). The [EXAMPLES] placeholder should contain 2-3 few-shot examples showing both valid outputs and violation records with field-level detail. Set [RISK_LEVEL] to calibrate the model's sensitivity—higher risk levels should produce more detailed violation records with stronger escalation signals. For production use, always run the output of this prompt through a JSON schema validator before consuming it in downstream systems. If the violation record itself is malformed, fall back to a generic escalation with the raw model output attached.

This prompt is designed to sit inside a post-generation validation pipeline, not as a standalone chat interaction. After your application receives a structured output from a model—JSON, XML, or a typed object—run your schema validator first. If validation fails, capture the raw output, the expected schema, and the specific validation errors. Feed these three artifacts into this prompt to produce a structured violation record. The prompt's job is to normalize the failure into a machine-readable escalation payload that your review queue or monitoring system can consume without manual reformatting.

Wire the prompt into an application harness that handles the full lifecycle: 1. Schema Validation Gate—Use a deterministic validator (e.g., jsonschema in Python, zod in TypeScript, or Pydantic) to check the model's output against your expected contract. Do not rely on the model to self-detect format errors. 2. Violation Record Generation—On validation failure, call this prompt with [RAW_OUTPUT], [EXPECTED_SCHEMA], and [VALIDATION_ERRORS]. Set [SEVERITY_THRESHOLD] to CRITICAL if the output is consumed by downstream systems without human review, or HIGH if a fallback path exists. 3. Retry Logic—Before escalating, attempt a single retry by feeding the validation errors back to the original generation model with a repair prompt. If the retry also fails validation, proceed to escalation. Do not retry more than once for format violations; repeated failures indicate a prompt design or model capability issue, not a transient error. 4. Review Queue Routing—Map the severity field from the prompt's output to your ticket system: CRITICAL → P1 incident, HIGH → review queue with 15-minute SLA, MEDIUM → logged for weekly prompt improvement cycle. 5. Logging and Observability—Log the full violation record (including violation_id, field_errors, and schema_version) to your prompt observability store. Tag traces with format_contract_violation for dashboard aggregation.

For model choice, use a fast, instruction-following model (e.g., GPT-4o-mini, Claude 3.5 Haiku) for this escalation prompt. The task is structured classification and normalization, not complex reasoning. Set temperature=0 to maximize output consistency. If your application runs in a regulated environment, add a human review step before the violation record is written to any permanent audit log—the prompt's requires_human_review boolean should gate this. Avoid wiring this prompt directly into customer-facing error messages; the violation record is an internal diagnostic artifact. Instead, map the output to a user-safe fallback message while the escalation payload routes to your on-call or review team.