Correction Cascade Audit Record Prompt

This prompt is for assistant product teams that need to analyze user correction episodes at scale. When a user corrects the assistant, the correction can invalidate downstream claims, state updates, and tool outputs that depended on the original error. This prompt produces a structured audit record that traces the original error, the correction itself, every downstream state change triggered by the correction, and any dependent claims that were left uncorrected. Use this prompt when you need to prove that your correction-handling logic is complete, identify gaps in cascade repair, or generate evidence for compliance reviews.

This is not a prompt for handling corrections in real time. It is an offline analysis prompt that operates on a completed conversation segment. It assumes you already have a correction episode identified and need a traceable record of what happened and what might have been missed. The prompt requires a fully serialized conversation segment containing the user correction turn, the assistant's acknowledgment, and all subsequent turns where state or claims may have been affected. Without this complete segment, the audit record will be incomplete and may produce false negatives for missed dependent claims.

Do not use this prompt for live correction handling, real-time state repair, or user-facing apology generation. Those workflows require different prompts that operate on the current turn with access to tool outputs and state mutation logic. This prompt is designed for post-hoc analysis, QA sampling, and compliance evidence generation. Before running it, ensure you have extracted the correction episode boundaries correctly—including the original error turn, the correction turn, and all turns up to the point where the cascade should have been resolved. Missing turns will produce an audit record that underreports uncorrected dependencies.

The following prompt template is designed to be pasted directly into your audit pipeline. It instructs the model to act as a conversation state auditor, analyzing a sequence of turns where a user corrected the assistant. The goal is to produce a single, structured JSON record that captures the full cascade of the correction event. This record is essential for compliance, debugging, and measuring the robustness of your assistant's state management. Before using this prompt, ensure you have the full conversation segment, the system's internal state objects from before and after the correction, and a clear definition of what constitutes a 'dependent claim' in your domain.

textCopy
You are a Conversation State Auditor. Your task is to analyze a user correction episode and produce a structured audit record.

**INPUTS**
- Conversation History: [CONVERSATION_HISTORY]
- Pre-Correction State: [PRE_CORRECTION_STATE]
- Post-Correction State: [POST_CORRECTION_STATE]
- Domain Claim Definitions: [DOMAIN_CLAIM_DEFINITIONS]

**TASK**
1. Identify the turn where the user issued a correction.
2. Identify the assistant's original claim or action that was corrected.
3. List all downstream state changes that occurred as a direct result of the correction.
4. Identify any dependent claims (as defined in [DOMAIN_CLAIM_DEFINITIONS]) that were based on the original error and were NOT updated after the correction.

**OUTPUT_SCHEMA**
Produce a single JSON object conforming to this schema:
{
  "correction_episode_id": "string, unique identifier for this episode",
  "correction_turn_index": "integer, the turn number where the user correction occurred",
  "original_error": {
    "turn_index": "integer, the turn where the error was made",
    "claim": "string, the original incorrect claim or action",
    "state_before": "object, the relevant part of the pre-correction state"
  },
  "user_correction": "string, the user's exact correction message",
  "cascade_changes": [
    {
      "state_field_path": "string, path to the changed state field",
      "value_before": "any",
      "value_after": "any",
      "change_reason": "string, explanation linking the change to the user correction"
    }
  ],
  "missed_dependent_claims": [
    {
      "claim": "string, the dependent claim that was not corrected",
      "dependency_path": "string, how this claim depends on the original error",
      "risk": "string, brief assessment of the risk posed by this uncorrected claim"
    }
  ],
  "audit_notes": "string, any additional observations about the correction cascade"
}

**CONSTRAINTS**
- Base all findings strictly on the provided [CONVERSATION_HISTORY] and state objects. Do not infer or assume information not present.
- If no dependent claims were missed, the `missed_dependent_claims` array must be empty.
- If the user correction is ambiguous, note this in `audit_notes` and flag the episode for human review.
- The `state_field_path` should use dot-notation (e.g., `booking.flight_number`).

To adapt this template, replace the square-bracket placeholders with your actual data. [CONVERSATION_HISTORY] should be a serialized list of turns with speaker roles. [PRE_CORRECTION_STATE] and [POST_CORRECTION_STATE] are snapshots of your application's state object. The most critical adaptation is [DOMAIN_CLAIM_DEFINITIONS]. This should be a concise, structured definition of what types of claims in your system are considered 'dependent' on others. For example, in a travel booking assistant, a claim about a 'return flight date' is dependent on a claim about the 'departure flight date'. Providing this domain-specific logic is what makes the audit record actionable rather than generic. After generating the record, you must run the provided eval checks to validate cascade completeness before the record is stored or reviewed.

This prompt is designed for a batch audit pipeline, not a real-time chat handler. It expects a complete conversation segment containing a user correction episode and produces a structured JSON audit record. In your harness, treat the model's output as a candidate audit artifact that must pass schema validation before it is stored. The prompt's value is in surfacing dependent claims that may have been left uncorrected—this is a detection signal, not a repair action. Do not use this prompt's output to automatically trigger state repairs in your production system. The output is an audit record; if you need automated repair, build a separate product workflow that consumes these audit records after human review.

Validation and retry logic is essential. After receiving the model response, validate the output against your expected JSON schema—check that all required fields are present, that correction_turn_number is an integer, that dependent_claims is an array, and that each claim in the cascade has a corrected boolean. If validation fails, retry once by appending the validation errors to the prompt as additional constraints (e.g., 'Your previous output failed validation with the following errors: [ERRORS]. Please correct your response to match the required schema.'). If the retry also fails, log the failure and flag the record for human review. For regulated domains, store three artifacts together as an immutable audit bundle: the raw prompt sent to the model, the raw model response, and the validated output JSON. Each audit record must carry a unique audit_id, the originating session_id, the correction_turn_number, and a UTC timestamp.

Model choice matters for this workflow. Use a model with strong structured output capabilities and a context window large enough to hold the full correction episode plus the prompt instructions. If your conversation segments are long, consider pre-filtering to include only the turns relevant to the correction cascade—the original error turn, the correction turn, and any subsequent turns where dependent claims may have been affected. Do not truncate mid-cascade. Human review is required for any audit record where the model flags uncorrected dependent claims with confidence above 0.7. These records represent potential state corruption in your assistant and should be reviewed before any downstream repair workflow is triggered. Log every audit record, including those that pass validation cleanly, so you can track correction cascade frequency and severity over time.