Instruction Ambiguity Detection and Resolution Prompt

Use this prompt when a system prompt, policy document, or set of behavioral instructions produces inconsistent outputs across repeated runs. The job-to-be-done is proactive ambiguity detection before a prompt ships to production. The ideal user is a prompt engineer or AI platform team member who owns system instruction quality and needs to prevent silent policy violations caused by vague language, contradictory directives, or underspecified constraints. You should have a complete block of instructions ready for review, and you should be prepared to act on the structured ambiguity report this prompt produces.

This playbook is not for runtime conflict resolution between user requests and system policies. If you need to arbitrate a live conflict where a user's request contradicts a system rule, use the sibling playbook on User Override vs System Policy Conflict Resolution. This prompt is a pre-deployment audit tool, not a real-time arbitration engine. It is designed to be run during prompt development, QA, and release gating, before instructions are exposed to real users. Do not use it to resolve conflicts that emerge during inference; those require a different decision architecture with escalation paths and human review.

The prompt takes a block of instructions as input and returns a structured ambiguity report with severity classifications, clarification questions, and disambiguated rewrites. It also includes a harness for measuring behavioral variance so you can quantify how much ambiguity actually impacts output consistency. After running this audit, you should have a clear list of instructions that need rewriting, a set of clarification questions to resolve with policy authors, and a baseline variance measurement to compare against after you make changes. The next step is to iterate on the flagged instructions and re-run the audit until ambiguity scores drop below your release threshold.

This prompt template is designed to be run multiple times (recommended: 5–10 runs) against the same instruction block to measure behavioral variance. It forces the model to act as an auditor, identifying vague terms, conflicting directives, and missing constraints that cause inconsistent behavior in production. The output is a structured report, not a conversational reply, making it suitable for automated evaluation pipelines.

textCopy
You are an instruction auditor. Your task is to analyze the provided system instructions for ambiguity, vagueness, and internal conflict that could cause inconsistent model behavior.

## INPUT
[INSTRUCTIONS]

## TASK
1. Identify every phrase, term, or directive that is ambiguous, undefined, or open to multiple interpretations.
2. Identify every pair or set of instructions that conflict with each other, either directly or by implication.
3. For each finding, assign a severity: CRITICAL (will cause safety or policy violations), HIGH (will cause inconsistent task execution), MEDIUM (may cause confusion in edge cases), LOW (stylistic or minor).
4. For each finding, generate a specific clarification question that a policy author must answer.
5. For each finding, propose a disambiguated rewrite that resolves the ambiguity or conflict while preserving the original intent as closely as possible.

## OUTPUT_SCHEMA
Return a single JSON object with this exact structure:
{
  "findings": [
    {
      "id": "string",
      "type": "AMBIGUITY | CONFLICT",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "location": "string (quote the ambiguous or conflicting text)",
      "description": "string (explain why this is ambiguous or conflicting)",
      "clarification_question": "string (what must be decided to resolve this)",
      "proposed_rewrite": "string (the disambiguated version)"
    }
  ],
  "summary": {
    "total_findings": number,
    "critical_count": number,
    "high_count": number,
    "medium_count": number,
    "low_count": number
  }
}

## CONSTRAINTS
- Do not invent instructions that are not present in the input.
- Do not flag intentional flexibility as ambiguity unless it creates a real conflict.
- If no findings exist, return an empty findings array and a summary with all zero counts.
- Every finding must include a clarification question and a proposed rewrite.
- The proposed rewrite must be a drop-in replacement for the ambiguous text, not a complete redesign of the system prompt.

Adaptation notes: Replace [INSTRUCTIONS] with the full system prompt or instruction block under review. For large prompts, consider splitting into sections and running the audit per section. The output schema is designed for direct ingestion into a test harness that compares findings across runs—if the same instruction block produces different findings on different runs, the instructions themselves are likely ambiguous. For high-risk domains (healthcare, legal, finance), route all CRITICAL and HIGH findings to a human reviewer before accepting proposed rewrites.

This prompt is designed to operate as a pre-deployment gate in a prompt engineering workflow, not as a real-time inference component. Wire it into a CI/CD pipeline or a manual review step that runs before system prompts are promoted to production. The harness must capture the raw prompt under test, invoke the ambiguity detection prompt, parse the structured ambiguity report, and route findings to the appropriate action queue: clarification requests go to the prompt author, disambiguated rewrites go to a versioned prompt registry, and high-severity conflicts trigger a release block. Because the prompt itself is a meta-evaluation tool, treat its output as advisory—human review is required before accepting any disambiguated rewrite, especially for prompts governing safety policies, compliance boundaries, or tool authorization rules.

The implementation loop follows a validate-detect-measure pattern. First, validate that the input prompt is parseable and contains at least one instruction block; reject empty or malformed inputs before calling the model. Second, invoke the ambiguity detection prompt with a structured output schema (JSON with fields for ambiguity_id, severity, conflicting_instructions, clarification_question, and disambiguated_rewrite). Use response_format with a strict JSON schema on OpenAI or equivalent constrained generation on other providers to prevent free-text drift. Third, run a behavioral variance measurement: for each detected ambiguity, generate N completions (N ≥ 5) using the original prompt with a fixed input set, then compare outputs for consistency. High variance across completions confirms the ambiguity is real and not a false positive. Log variance scores alongside each ambiguity for prioritization. Retry logic should be minimal here—if the model fails to produce valid JSON after two attempts, flag the prompt as unevaluable and escalate for manual review rather than looping indefinitely.

Model choice matters. Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller or older models that may hallucinate conflicts or miss subtle precedence ambiguities. For cost-sensitive pipelines, batch multiple prompts into a single evaluation run, but keep each prompt's ambiguity report isolated to avoid cross-contamination. Store all outputs—raw ambiguity reports, variance scores, human review decisions, and final rewrites—in a versioned prompt registry with audit trails. When a disambiguated rewrite is accepted, generate regression test cases that verify the new prompt behaves consistently under the conditions that previously triggered variance. Finally, set a severity threshold: ambiguities classified as critical or high should block deployment until resolved and re-tested; medium findings can ship with a review ticket; low findings can be logged for the next maintenance cycle. This gating prevents ambiguous instructions from reaching users while keeping the development loop fast for low-risk changes.