Unresolved Reference Flagging and Escalation Prompt

This prompt is for production assistant pipelines that operate under a strict no-guess policy. Use it when your system handles multi-turn dialogue in domains where an incorrect reference resolution carries material risk: healthcare handoffs, legal intake, financial transactions, compliance workflows, or any customer-facing surface where a wrong entity match creates liability or erodes trust. The ideal user is an AI engineer or product developer who already has a working dialogue system and needs a safety net that catches ambiguous anaphora, unresolved pronouns, and implicit references before they reach downstream NLU or action handlers. You need access to the current user turn, the prior conversation history, and a defined schema for your clarification output.

Do not use this prompt when you already have a high-confidence reference resolver that handles ambiguity internally, when your application tolerates occasional incorrect resolutions (e.g., casual chat, entertainment), or when the cost of asking a clarification question exceeds the cost of a wrong guess. This prompt is also inappropriate for single-turn systems where no dialogue history exists to create ambiguity. If your domain requires the assistant to always attempt a best-guess resolution before escalating, pair this prompt with a resolver and use the binary flag as a gating condition rather than a replacement.

The prompt produces two outputs you can act on programmatically: a reference_unresolvable boolean and a structured clarification_question. Wire the boolean into your routing logic so that true triggers either a clarification turn with the user or, in high-stakes domains, a human review queue. The clarification question is designed to be shown directly to the user without modification. Before deploying, validate that your pipeline correctly handles the case where the model flags a reference as resolvable but your downstream resolver still fails—this double-fault scenario requires its own escalation path. Test against a golden set of genuinely ambiguous turns, turns with clear referents, and adversarial turns designed to trick the flagger into over-flagging or under-flagging.

This prompt template is designed to be inserted into a production assistant pipeline immediately after the user's current turn is received and before any downstream processing, tool calls, or response generation. Its job is to act as a safety gate: it examines the user's latest utterance against the provided conversation history and determines whether any reference—pronoun, implicit entity, or shorthand—cannot be resolved with high confidence. If the reference is resolvable, the prompt returns a clean pass. If not, it returns a structured flag and a clarification question, preventing the assistant from guessing and producing a confident but incorrect response. For high-stakes domains such as healthcare, finance, or legal, an additional escalation path is included to route the unresolved case for human review.

textCopy
You are a reference resolution safety gate in a production assistant pipeline. Your sole task is to analyze the user's latest turn against the provided conversation history and determine whether any entity reference is unresolvable.

## INPUT
[CONVERSATION_HISTORY]
[USER_TURN]

## CONSTRAINTS
- Do not guess. If you cannot identify the exact referent with high confidence, flag it as UNRESOLVED.
- Consider pronouns, demonstratives (this, that, these, those), definite descriptions (the invoice, the error), and implicit references (the other one).
- If the user's turn contains no references that require resolution, return RESOLVED.
- If the reference is to an entity not present in the conversation history, flag it as UNRESOLVED.
- Do not use external knowledge to resolve references. Only use the provided [CONVERSATION_HISTORY].

## OUTPUT_SCHEMA
Return a single JSON object with the following schema:
{
  "status": "RESOLVED" | "UNRESOLVED",
  "unresolved_span": string | null,  // The exact text span that could not be resolved, if any.
  "candidate_referents": string[],   // List of possible referents considered, empty if none.
  "clarification_question": string | null,  // A single, targeted question to disambiguate. Null if RESOLVED.
  "confidence": number,  // 0.0 to 1.0. Score below [CONFIDENCE_THRESHOLD] triggers UNRESOLVED.
  "escalation_required": boolean  // True if [RISK_LEVEL] is 'high' and status is UNRESOLVED.
}

## PARAMETERS
- Confidence Threshold: [CONFIDENCE_THRESHOLD] (e.g., 0.9)
- Risk Level: [RISK_LEVEL] ("low" | "medium" | "high")

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## INSTRUCTIONS
1. Parse [CONVERSATION_HISTORY] and [USER_TURN].
2. Identify all referring expressions in [USER_TURN].
3. For each referring expression, search [CONVERSATION_HISTORY] for a matching antecedent.
4. If any referring expression cannot be matched with confidence >= [CONFIDENCE_THRESHOLD], set status to UNRESOLVED.
5. Generate a clarification question that targets only the ambiguous reference without repeating the entire context.
6. If [RISK_LEVEL] is "high" and status is UNRESOLVED, set escalation_required to true.
7. Return only the JSON object. No other text.

To adapt this template, replace the square-bracket placeholders with your application's live data. [CONVERSATION_HISTORY] should contain the last N turns formatted with speaker labels and turn indices. [USER_TURN] is the raw text of the current message. Set [CONFIDENCE_THRESHOLD] based on your tolerance for false positives—0.9 is a reasonable starting point for most applications, but lower it to 0.7 for chattier domains where occasional clarification is acceptable. [RISK_LEVEL] should be pulled from your application's routing logic: set it to "high" for healthcare, legal, or financial workflows where a wrong resolution has material consequences. The [FEW_SHOT_EXAMPLES] placeholder should be populated with 2-4 examples showing both RESOLVED and UNRESOLVED cases, including at least one example where the model correctly abstains despite a plausible but incorrect candidate. After the prompt returns, validate the JSON output against the schema before allowing downstream processing to consume it. If the JSON is malformed, retry once with a repair prompt; if it fails again, treat it as an UNRESOLVED case and escalate.

This prompt is designed as a pre-processing gate in a multi-turn assistant pipeline. Before any downstream NLU, RAG retrieval, or agent action occurs, the current user turn and a compressed representation of the dialogue history are passed through this prompt. The output is a binary is_unresolvable flag and, if true, a structured clarification_question. The application must not proceed to the main processing step if the flag is true; instead, it must surface the clarification question to the user or escalate to a human reviewer. This gate prevents the most common cause of confident hallucination in production chat systems: the model guessing at an ambiguous reference rather than asking for disambiguation.

Wiring the prompt into an application requires a strict contract. The input must include the current user utterance and a structured, time-ordered summary of the last N turns (or a compressed session state). The output must be parsed as JSON with a schema validator checking for is_unresolvable (boolean) and clarification_question (string or null). If is_unresolvable is true and the clarification_question is missing or empty, treat this as a malformed output and trigger a retry with a stricter output constraint appended to the prompt. For high-stakes domains such as healthcare or finance, the application should also check a confidence field (if your variant includes one) and escalate to a human review queue if confidence is below a defined threshold, even if the flag is false. Log every decision—the raw user input, the prompt template version, the model response, and the final action taken—to build an audit trail for debugging false positives and false negatives.

Model choice and latency budget are critical here. This prompt runs on every user turn, so it must be fast. Use a smaller, cheaper model (e.g., a fast-inference variant) for this classification task, reserving larger models for the main generation step. If the application uses RAG, ensure that the dialogue history passed to this prompt does not include the full retrieved documents; only the user's words and prior assistant responses are needed to resolve conversational references. Tool use is not required for this prompt, but if your system already has a structured session state object, pass it as a JSON block in the context rather than raw text history to improve accuracy. Implement a hard timeout of 2-3 seconds for this step; if the model does not respond in time, fail open by assuming the reference is resolvable and log the timeout as a risk event for later review.

Testing and failure modes must be addressed before shipping. The most common failure is a false positive—flagging a perfectly clear reference as unresolvable—which frustrates users with unnecessary clarification questions. Mitigate this by running a golden dataset of 200+ turns with known-resolvable references through the prompt and measuring the false positive rate. The second failure mode is a false negative—allowing an ambiguous reference to pass through—which causes downstream errors. Test this with deliberately ambiguous inputs (e.g., 'send it to him' with two male contacts in context) and measure the false negative rate. If either rate exceeds 5%, adjust the prompt's threshold language or add few-shot examples of borderline cases. For regulated domains, implement a human-in-the-loop override where a reviewer can see the flagged turn, the model's proposed clarification question, and the dialogue context, then choose to approve, edit, or dismiss the question before it reaches the user.