Ambiguity Preflight

Ambiguity Preflight

Use this skill as a pre-analysis gate. Its job is to expose ambiguous meaning before reasoning or generation turns one interpretation into a hidden assumption.

Core question:

Could two competent people reasonably interpret this differently, and would that difference change the output?

If yes, surface and handle the ambiguity before doing the main task.

Relationship To Assumptions

Run ambiguity preflight before applying an assumptions framework.

• Ambiguity preflight asks: "What does this mean?"
• Assumption handling asks: "What are we assuming as we reason from it?"

If ambiguity is unresolved but non-blocking, state the working interpretation. If the interpretation materially affects later analysis, carry it forward as an explicit assumption.

Example:

Ambiguity: "integration" may mean API connection, data sync, embedded workflow, or custom middleware.
Working interpretation: Treat "integration" as API/data-sync work unless clarified.
Downstream assumption: [Inference: "integration" is treated as API/data-sync work based on surrounding implementation language.]

Ambiguity Gate

Begin substantive work with one of these statuses when material ambiguity may exist:

Ambiguity Status: Clear
Ambiguity Status: Proceed with flagged interpretations
Ambiguity Status: Blocked pending clarification

Use Clear only when no material ambiguity is found.

Use Proceed with flagged interpretations when ambiguity exists but the task can continue by naming reversible working interpretations.

Use Blocked pending clarification when different reasonable interpretations would materially change the output and proceeding would likely mislead the user.

If blocked, ask only the minimum clarification questions needed to unblock the work. Do not produce the main analysis or draft.

Materiality Test

Treat ambiguity as material if different interpretations could change:

• scope
• deliverables
• obligations
• ownership or accountability
• cost, effort, timeline, risk, or priority
• acceptance criteria or measurement
• legal, commercial, technical, operational, or product interpretation
• audience, tone, format, or intended use of generated output
• downstream recommendations, decisions, or conclusions

Do not flag every vague word. Focus on ambiguity that can break the answer.

Ambiguity Categories

Classify material ambiguities using the most specific applicable category.

• Undefined critical term: A central term is used without definition.
• Vague qualifier: A subjective standard is used, such as reasonable, timely, best efforts, as needed, robust, scalable, or high quality.
• Overloaded term: A term can mean several things depending on context, such as platform, integration, reporting, API, customer, launch, or support.
• Inconsistent usage: The same term appears to mean different things across sections, documents, or contexts.
• Hidden compound concept: One phrase compresses multiple requirements, such as fully functional solution, end-to-end delivery, production ready, or complete onboarding.
• Missing measurement definition: A metric or outcome is named without how, when, or by whom it is measured.
• Missing acceptance criteria: A deliverable, feature, or obligation lacks completion conditions.
• Ambiguous actor or owner: It is unclear who is responsible, who decides, who approves, or who performs the action.
• Ambiguous timeframe: Timing is unclear, relative, conditional, or dependent on an undefined trigger.
• Ambiguous scope boundary: It is unclear what is included, excluded, optional, or out of scope.
• Cross-document definition conflict: A term differs between a source document, definitions file, prior context, policy, or canonical glossary.
• Output intent ambiguity: The user request itself leaves audience, purpose, format, review lens, or success criteria unclear.

Preflight Workflow

Before the main task:

1. Identify the downstream task the user wants.
2. Scan the prompt and any source material for terms, phrases, requirements, definitions, instructions, and success criteria that could support multiple reasonable meanings.
3. Filter to material ambiguities only.
4. Classify each ambiguity.
5. Decide whether each ambiguity is blocking or non-blocking.
6. Choose the handling mode: clarify, branch, proceed with a working interpretation, or exclude from downstream conclusions.
7. Produce the ambiguity preflight result.
8. Continue only if the gate status is Clear or Proceed with flagged interpretations.

Output Format

Use this structure when material ambiguity is present:

## Ambiguity Preflight

Ambiguity Status: Proceed with flagged interpretations

## Critical Ambiguity Map

| ID | Term / Phrase | Location | Type | Possible Interpretations | Why It Matters | Handling |
|---|---|---|---|---|---|---|
| B1 | "integration" | SOW section 2.1 | Overloaded term | API connection; data sync; embedded workflow; custom middleware | Changes scope, effort, timeline, and technical design | Proceed with W1 unless clarified |

## Blocking Clarifications

- What does "integration" include: API connection only, data sync, embedded workflow, or custom middleware?

## Working Interpretations

- `W1` - Treat "integration" as API/data-sync work, not embedded workflow or custom middleware.

Omit sections that do not apply. If status is Clear, keep the preflight short.

Handling Modes

Use one of these modes for each material ambiguity:

• Clarify: Ask a targeted question before continuing.
• Branch: Show how outputs differ under two or more interpretations.
• Proceed with working interpretation: Name the interpretation and continue.
• Exclude: Do not use the ambiguous item as evidence for downstream conclusions.

Prefer Clarify when the ambiguity is high-risk and the user can likely answer quickly.

Prefer Branch when the user needs to see how interpretations change consequences.

Prefer Proceed with working interpretation when the ambiguity is non-blocking, reversible, and unlikely to invalidate the whole output.

Prefer Exclude when the ambiguous item is too unclear to support a reliable conclusion.

Contract And SOW Review

For contracts, SOWs, proposals, and policy documents, pay special attention to ambiguity affecting:

• scope
• deliverables
• payment triggers
• milestones
• dependencies
• warranties or service levels
• support obligations
• acceptance
• change control
• termination
• liability allocation

Compare defined terms against any definitions file or canonical glossary if provided. If usage is variant or conflicting, do not normalize silently. Treat the divergent usage as a separate ambiguity.

Product, Technical, And Research Inputs

For PRDs, specs, customer notes, and research synthesis, pay special attention to ambiguity affecting:

• user persona or customer segment
• problem statement
• feature scope
• technical architecture
• integration meaning
• data model or system boundary
• success metric
• prioritization rationale
• evidence strength
• repeated terminology across customers or transcripts

Do not merge customer statements into a unified signal until term meaning is semantically consistent.

Generation Tasks

For drafting, rewriting, summarizing, or content generation, check whether the user's requested output is itself ambiguous.

Common output-intent ambiguities:

• audience is unclear
• tone is unclear
• purpose is unclear
• format is unclear
• desired level of detail is unclear
• review lens is unclear, such as legal, product, technical, executive, or customer-facing

If these choices materially change the output, clarify or proceed with a named working interpretation.

Anti-Patterns

Avoid:

• Resolving ambiguity silently
• Assuming a standard meaning without support
• Choosing the most favorable interpretation by default
• Collapsing multiple meanings into one
• Producing a list of obvious vague words while missing scope-driving terms
• Deferring material ambiguity to later analysis
• Treating ambiguous customer language as validated product evidence
• Asking broad clarification questions when a narrow one would unblock the work