Correction Cascade Prevention Prompt

This prompt is designed for multi-turn assistant systems where a single user correction can silently corrupt a chain of subsequent decisions. The core job-to-be-done is cascade analysis and re-execution planning, not correction detection. It assumes an upstream process has already identified a correction event and classified its type. The ideal user is an AI engineer or technical product manager responsible for maintaining dialogue state integrity across turns, particularly in copilots, task-oriented agents, or support bots where state derived from a corrected claim in turn N could invalidate tool calls, slot values, or generated content in turns N+1 through N+5.

Use this prompt when your system maintains a structured dialogue state or action log that evolves over a session. It is most effective when the cost of an undetected cascade is high—for example, a corrected user address invalidating a downstream shipping estimate, or a reversed factual claim undermining a subsequent analysis. The prompt requires two structured inputs: a full conversation transcript and a state log or action trace that records what the assistant derived at each turn. It produces a dependency graph and a safe re-execution order, which your application can then use to surgically repair state and re-trigger dependent actions rather than discarding the entire session.

Do not use this prompt for single-turn Q&A, stateless assistants where each response is independent, or systems that lack a machine-readable state log. If your assistant treats every user message as a fresh request with no memory of prior turns, there is no cascade to analyze. Similarly, avoid this prompt if your correction handling strategy is simply to summarize the last few turns and ask the model to 'try again'—that approach is covered by the State Rollback After Correction Prompt. This prompt is for teams that need a precise, auditable repair plan. The next step after reading this section is to review the required input schemas in the prompt template and ensure your upstream correction detection system can produce the [CORRECTION_EVENT] structure this prompt expects.

This prompt is the core engine for preventing correction cascades. It takes a structured correction event, the full conversation transcript, and a snapshot of the application's dialogue state. Its job is not to generate a user-facing response, but to produce a machine-readable plan that your application executor can use to safely undo and redo work. The output is a dependency graph and an ordered list of operations, which you should validate before executing any state mutations or re-prompting the model.

codeCopy
SYSTEM:
You are a state dependency analyzer for a multi-turn AI assistant. Your task is to prevent correction cascades. Given a user correction event, a conversation transcript, and a state log, you will identify all downstream assistant turns, tool calls, and state updates that depend on the corrected claim. You will then produce a dependency graph and a safe, topologically sorted re-execution order.

INPUT:
- Correction Event: [CORRECTION_EVENT]
- Conversation Transcript: [CONVERSATION_TRANSCRIPT]
- State Log: [STATE_LOG]

INSTRUCTIONS:
1. Identify the specific assistant claim being corrected. Locate it in the transcript.
2. Trace forward from that claim through all subsequent assistant turns, tool calls, and state updates.
3. For each subsequent item, determine if it has a direct or transitive dependency on the corrected claim. A dependency exists if the item's logic, arguments, or results would change if the claim were false.
4. Identify any circular dependencies where two or more items depend on each other, creating a loop that cannot be resolved by simple re-execution.
5. Flag any over-invalidation: items that appear related but are logically independent of the corrected claim and should not be re-executed.
6. Produce a safe re-execution order. This is a topologically sorted list of dependent items that must be re-run, excluding items with circular dependencies.

OUTPUT_SCHEMA:
{
  "corrected_claim": {
    "turn_id": "string",
    "claim_text": "string"
  },
  "dependency_graph": [
    {
      "item_id": "string",
      "item_type": "assistant_turn | tool_call | state_update",
      "description": "string",
      "depends_on": ["item_id"],
      "is_dependent": boolean
    }
  ],
  "circular_dependencies": [
    {
      "item_ids": ["string"],
      "description": "string"
    }
  ],
  "over_invalidated_items": [
    {
      "item_id": "string",
      "reason": "string"
    }
  ],
  "safe_re_execution_order": ["item_id"],
  "unresolvable_items": ["item_id"]
}

CONSTRAINTS:
- Do not re-execute items that are not dependent on the corrected claim.
- If a circular dependency is found, do not include any item in that cycle in the safe_re_execution_order. List them in circular_dependencies and unresolvable_items.
- The safe_re_execution_order must be a valid topological sort. If A depends on B, B must appear before A in the list.
- If no dependent items are found, return empty lists for dependency_graph and safe_re_execution_order.

To adapt this prompt, you must first define the schemas for [CORRECTION_EVENT], [CONVERSATION_TRANSCRIPT], and [STATE_LOG] in your application code. The [CORRECTION_EVENT] should be the structured output from a prior correction detection step, containing at minimum a turn_id and claim_text. The [STATE_LOG] should be a chronological list of state mutations with unique IDs that can be referenced in the dependency graph. Before executing the safe_re_execution_order, your harness must validate the output against the OUTPUT_SCHEMA, check for cycles in the dependency graph, and confirm that every item in the re-execution order has its dependencies satisfied. For high-stakes applications, flag any unresolvable_items for immediate human review instead of attempting an automated fallback.

The Correction Cascade Prevention Prompt is not a standalone fix; it is a state-machine guard that must be invoked immediately after a user correction is detected and before any downstream state mutation or tool re-execution occurs. In a production harness, this prompt sits between the correction detection step (see User Correction Detection Prompt Template) and the state rollback or re-execution step (see State Rollback After Correction Prompt Template). Its job is to produce a dependency graph and a safe re-execution order, not to execute the rollback itself. Wire it as a synchronous blocking call: the system must wait for the dependency analysis to complete before touching any state fields, tool calls, or response generation that could depend on the corrected claim.

The harness requires a structured input payload containing the full conversation history, the specific correction event (user turn index, corrected claim, correction type), and a snapshot of the current dialogue state including all slot values, pending actions, and tool call results that were derived after the corrected claim. The prompt returns a JSON schema with a dependency_graph (nodes and edges representing which state fields, tool calls, and assistant turns depend on the corrected claim), a safe_re_execution_order (topologically sorted list of actions to re-run), circular_dependency_flags (any cycles that require human resolution), and an over_invalidation_warning (fields flagged for rollback that are actually independent of the correction). Validate this output before acting: if circular_dependency_flags is non-empty, halt automatic rollback and escalate to a human reviewer. If over_invalidation_warning is triggered, log the discrepancy and consider a confirmation prompt before pruning those fields.

Model choice matters here. This prompt requires strong reasoning over structured relationships, so prefer models with explicit JSON mode and long-context handling (e.g., GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). Set temperature=0 to minimize variance in dependency graph generation. Implement a retry loop with a maximum of two attempts: if the first response fails JSON schema validation or produces a dependency graph that references non-existent state keys, retry with the validation error injected into the prompt as a [PREVIOUS_ERROR] field. After two failures, log the full trace and escalate to a human operator rather than risking a cascading state corruption. For latency-sensitive applications, consider caching dependency graphs for structurally similar correction patterns, but invalidate the cache whenever the dialogue state schema changes.

Observability is non-negotiable for this prompt. Log every invocation with a correlation ID that ties the correction event to the dependency graph output, the actions taken (or skipped), and the final state after rollback. Instrument three key metrics: (1) correction_cascade_depth — the number of downstream nodes affected by a single correction, (2) circular_dependency_rate — the frequency of cycles requiring human intervention, and (3) over_invalidation_rate — how often the prompt flags fields that should not have been rolled back. Set alert thresholds on circular_dependency_rate exceeding 5% of corrections and on any instance where correction_cascade_depth exceeds 20 nodes, as these indicate either brittle state design or prompt degradation. Pair this prompt with the Correction Observability Trace Prompt to produce structured trace events for your monitoring stack.

Before deploying, build a regression test suite using the Correction Regression Test Case Generation Prompt. Your test cases must cover: single-claim corrections with shallow dependencies, multi-hop corrections where one fix cascades through three or more derived state fields, corrections that touch tool call results (requiring re-execution), corrections where the user provides new evidence that invalidates prior retrieval, and edge cases where the user corrects a claim that was already superseded by a later turn. For each test case, assert that the dependency graph includes all affected nodes, excludes unaffected nodes, produces a valid topological sort, and correctly identifies any circular dependencies. Run these tests as a CI gate before any prompt update reaches production.