User Correction Incorporation for References Prompt

This prompt is for assistant teams that need to handle user corrections like 'no, I meant the other one' in multi-turn dialogue. The job-to-be-done is repairing an incorrect entity mapping in the dialogue state after a user pushes back on a previously resolved reference. The ideal user is an AI engineer or product developer building a chat assistant or copilot where the system maintains a structured belief state of entities across turns. Required context includes the full dialogue history, the current structured entity grid, the user's correction utterance, and the specific entity or reference that was challenged. Without this context, the prompt cannot determine which entity was wrong or what the user intended instead.

Do not use this prompt when the user is introducing a new entity rather than correcting a prior resolution, when the correction is about a factual claim rather than an entity reference, or when the system has no structured entity state to update. This prompt is also inappropriate for single-turn interactions or stateless assistants. In high-stakes domains such as healthcare or finance, the cascade prevention check built into this prompt is essential, but you should still route the corrected state through a human review step before it drives downstream actions. The prompt assumes the user's correction is valid and does not second-guess the user; if your product needs to verify corrections against a ground-truth source, add a verification step before calling this prompt.

Before implementing this prompt, ensure your dialogue state manager can accept a structured patch object and merge it without conflicts. The output is an updated entity mapping and a cascade prevention report, not a natural-language response to the user. Wire this prompt into your correction-handling pipeline immediately after detecting a user correction turn, and log both the input state and output patch for auditability. If the cascade prevention check flags downstream impacts, route the affected state entries for re-verification rather than silently propagating the correction.

This prompt template handles the critical moment when a user says 'no, I meant the other one' or 'not that invoice, the one from Tuesday.' It takes the user's correction, the prior dialogue context, and the current set of tracked entities, then produces an updated entity mapping that repairs the incorrect reference. The template is designed to be dropped into a multi-turn assistant pipeline where unresolved or incorrectly resolved references are the most common cause of state corruption. Copy the template below and replace each square-bracket placeholder with your application's actual values before wiring it into your conversation handler.

textCopy
You are a reference repair specialist operating inside a multi-turn assistant system. Your job is to process user corrections that indicate a previous entity reference was resolved incorrectly, and produce an updated entity mapping that fixes the error.

## INPUTS
- Current user utterance: [USER_CORRECTION_UTTERANCE]
- Prior assistant turn (the turn being corrected): [PRIOR_ASSISTANT_TURN]
- Active entity grid (JSON array of tracked entities with IDs, types, attributes, and last-mentioned turn): [ACTIVE_ENTITY_GRID]
- Dialogue history (last N turns in order): [DIALOGUE_HISTORY]

## TASK
1. Identify which entity in the prior assistant turn the user is correcting.
2. Determine the correct intended referent from the dialogue history or entity grid.
3. If the correct referent is ambiguous, flag it for clarification instead of guessing.
4. Produce an updated entity grid that repairs the incorrect mapping.
5. Run a cascade prevention check: identify any downstream state, slot values, or pending actions that were derived from the incorrect reference and flag them for re-evaluation.

## OUTPUT SCHEMA
Return valid JSON matching this schema:
{
  "correction_target": {
    "incorrect_entity_id": "string | null",
    "incorrect_mention_text": "string",
    "turn_index": "number"
  },
  "resolved_referent": {
    "entity_id": "string | null",
    "entity_type": "string | null",
    "canonical_name": "string | null",
    "grounding_evidence": "string | null",
    "confidence": "number (0.0-1.0)"
  },
  "clarification_needed": "boolean",
  "clarification_question": "string | null",
  "updated_entity_grid": [
    {
      "entity_id": "string",
      "entity_type": "string",
      "attributes": {},
      "last_mentioned_turn": "number",
      "status": "active | corrected | deprecated"
    }
  ],
  "cascade_impact": [
    {
      "affected_state_key": "string",
      "previous_value": "string | null",
      "recommended_action": "re-resolve | re-confirm | invalidate | no-action",
      "reason": "string"
    }
  ],
  "repair_summary": "string"
}

## CONSTRAINTS
- Do not guess if the correct referent is ambiguous. Set clarification_needed to true and provide a targeted clarification question.
- If the user's correction references an entity not in the dialogue history or entity grid, flag it as unresolvable rather than fabricating an entity.
- The cascade_impact array must identify every downstream slot, action, or state variable that was computed using the incorrect entity. Missing cascade entries are the primary failure mode.
- For high-risk domains (healthcare, finance, legal), if confidence is below [CONFIDENCE_THRESHOLD], require human review before applying the update.
- Preserve all entity IDs that are not affected by the correction. Do not regenerate the entire grid.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL: low | medium | high]

To adapt this template for your application, start by defining your entity grid schema. The grid should track every entity your assistant has referenced across the session, including its type, attributes, and the turn where it was last mentioned. Replace [ACTIVE_ENTITY_GRID] with your actual grid structure. For the [DIALOGUE_HISTORY] placeholder, include the last 5-10 turns as structured objects with speaker, text, and turn index. The [FEW_SHOT_EXAMPLES] placeholder is critical: provide 2-3 examples showing corrections with different ambiguity levels, including one where clarification is needed and one where cascade impact is non-trivial. Set [CONFIDENCE_THRESHOLD] based on your domain risk tolerance—0.7 for low-risk, 0.9 for high-risk. The [RISK_LEVEL] field should be set to 'high' if the assistant operates in regulated domains where incorrect entity resolution could cause harm, and 'medium' or 'low' otherwise. After adapting the template, validate the output JSON against your schema before merging the updated entity grid into your dialogue state. The cascade impact array is the most important field to review: a missing cascade entry means a downstream error will survive the correction, defeating the purpose of the repair.

This prompt operates as a state repair step within a multi-turn dialogue pipeline. It should be invoked immediately after a user correction is detected—typically by an intent classifier or a clarification-handling module—and before the corrected entity mapping is merged back into the session's dialogue state. The prompt expects the current turn's user utterance, the assistant's last response that contained the incorrect reference, and the active entity map from the session state. Its output is a patch object that replaces the incorrect entity binding and flags any downstream state fields that need re-verification.

Wire the prompt as a synchronous blocking call in your turn-processing sequence. The input assembly step must extract the last assistant turn and the current entity map from your state store. After receiving the model's JSON response, run a structural validator that checks: (1) the correction object contains a valid incorrect_entity_id that exists in the submitted entity map, (2) the resolved_entity field is populated with a non-null value or an explicit needs_clarification flag, and (3) the cascade_impact array only references field paths present in your dialogue state schema. If validation fails, log the raw response and the validator error, then fall back to a clarification prompt that asks the user to re-specify the intended referent. Do not silently merge an invalid correction.

For high-stakes domains such as healthcare or finance, insert a human review gate before the state patch is applied. Route corrections where the model's confidence is below your threshold or where the cascade_impact array contains fields marked as critical in your state schema. The review interface should show the original user correction, the assistant's prior response, the proposed entity remapping, and the list of downstream fields that will be invalidated. The reviewer approves, rejects, or adjusts the mapping. Log the reviewer's decision alongside the model's output for auditability.

Model choice matters here. Use a model with strong instruction-following and JSON mode support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature to 0 or near-zero to maximize deterministic entity resolution. If you are using a smaller or open-weight model, add a retry layer that re-prompts with the validator's error message injected into the [CONSTRAINTS] block on the first failure. Limit retries to two attempts; if both fail, escalate to the clarification or human-review path. Monitor the rate of validation failures and correction reversals (where the user corrects the same entity again within the next three turns) as your primary production health metrics.