Scope clarification

Problem Context

• Users may refer to unclear objects, pronouns, dates, audiences, repositories, workspaces, source sets, accounts, policies, regions, files, tools, or authority levels.
• An AI answer may need different evidence, tone, output structure, or safety handling depending on selected scope.
• An AI agent may be able to retrieve data, draft messages, edit records, send notifications, create tickets, delete items, or run tools across multiple possible targets.
• A hidden default may be harmless in low-risk writing tasks but unsafe for permission changes, customer actions, payments, deletes, policy advice, or public publication.
• Clarification answers should become explicit task state, not accidental prompt text that disappears after one model turn.

Selection Rules

• Choose scope clarification when the AI needs a missing boundary before producing a reliable answer, plan, retrieval query, or tool action.
• Use prompt box when the main task is composing the original AI request; use scope clarification after submission when the system detects an important missing boundary.
• Use search scope selector when users are choosing where a search query runs across corpora; use scope clarification when an AI task itself is ambiguous or risky.
• Use agent plan preview when a multi-step plan is ready to inspect; use scope clarification before plan generation when the target, source set, or authority is unclear.
• Use human approval gate when automation is paused at an armed runtime step; use scope clarification before an action is armed or when the user must narrow intent first.
• Use chat interface when the problem is the whole conversation surface; scope clarification is a focused turn or panel inside that conversation.
• Ask one or a small set of clarifying questions only when the answer materially changes result quality, risk, privacy, or action target.
• Provide recognizable options, such as current item, selected items, visible filtered records, entire workspace, last 30 days, this quarter, internal audience, customer audience, cited sources only, or all available sources.
• Let users skip or use a visible default only when the default is low-risk and honestly described.
• Do not answer, plan, retrieve, edit, send, publish, or delete at a broad scope while a consequential scope question is unresolved.

Required States

• Ambiguous request state with original prompt preserved and missing scope named.
• Ambiguous object, audience, timeframe, source set, record set, workspace, permission, output depth, and authority states.
• Clarification question state with bounded choices, custom answer option, recommended default when safe, and cancel path.
• Selected scope state that previews how the answer, plan, retrieval, or tool action will use the scope.
• Skipped clarification or visible default state for low-risk ambiguity.
• High-impact blocked state where the system refuses to proceed until scope is clarified.
• Conflicting scope state where the user request contains incompatible boundaries.
• Permission-limited scope state where some choices are unavailable with explanation.
• Clarification answered, answer resumed, plan regenerated, stale clarification, and change-scope states.
• Mobile compact clarification state with original request, missing boundary, choices, and next step visible.

Interaction Contract

• The system identifies what boundary is missing before asking the user to clarify.
• The clarification question references the original request and explains why the answer matters.
• Choosing a clarification updates structured task state such as target objects, timeframe, source set, audience, output depth, or allowed action scope.
• The original request remains visible or recoverable so users can tell what will resume after clarification.
• If a default is used, the UI names the default and lets users change it before high-impact work begins.
• High-risk actions remain blocked until required scope is chosen and permissions are rechecked.
• Clarification answers persist for the current task, plan, answer, or run and are not silently reused across unrelated tasks.
• The UI exposes stale or changed context when a previous clarification no longer applies.

Implementation Checklist

• Model the original request, ambiguity type, missing boundary, candidate scopes, selected scope, default rationale, user answer, confidence, risk level, permissions, stale triggers, and resume target separately.
• Classify ambiguity by object set, timeframe, source set, audience, account, workspace, policy region, output depth, action target, authority, and risk.
• Generate one concise clarification question with bounded choices when the product can enumerate likely scopes.
• Block broad or irreversible actions until target scope, authority, and permissions are explicit.
• Preserve the original request, conversation turn, source context, and pending plan so clarification does not become a new unrelated prompt.
• Show how the chosen scope will affect answer, retrieval, plan, tool call, or output format before continuing.
• Store clarification answers with task or run identity and expire them when the selected object, source, permission, or context changes.
• Test ambiguous pronouns, broad requests, conflicting scopes, permission-limited choices, custom answers, skip defaults, stale clarification, mobile wrapping, keyboard operation, and screen-reader status updates.

Common Generated-UI Mistakes

• Guessing broad scope without revealing the assumption.
• Asking a long questionnaire when one boundary would let the task proceed.
• Using a clarification question to rewrite the user's prompt invisibly.
• Asking for clarification after the system has already acted.
• Forgetting the user's clarification answer in the next response or plan.
• Reusing a scope answer across unrelated tasks without confirmation.
• Showing backend source names or permission IDs as clarification choices.

Critique Questions

• What specific boundary is missing from the user's request?
• Will answering, planning, retrieving, or acting before clarification materially change risk or usefulness?
• Can the product offer bounded scope choices instead of an open-ended question?
• What visible default is safe, and when must the task be blocked until the user chooses?
• Where is the user's clarification answer stored, and when does it expire?
• Would prompt box, search scope selector, agent plan preview, human approval gate, or chat interface better match the actual problem?