Clarification vs Default Value Decision Prompt Template

This prompt is for integration developers building argument-filling pipelines where a tool call has optional parameters. The job-to-be-done is deciding, at runtime, whether a missing optional parameter should be filled with a safe, pre-defined default or surfaced to the user for clarification. The ideal user is an AI engineer or backend developer wiring a model's function-calling output into an actual API or database operation. Required context includes the full function schema with parameter descriptions, a list of approved default values and their justification, and the user's original request. Without this context, the model cannot reliably distinguish between a parameter that is safely defaultable and one that masks critical user intent.

Do not use this prompt when the parameter is required. Required parameters with missing values should trigger a dedicated missing-argument detection prompt and a targeted clarification question, not a default-value decision. This prompt is also inappropriate for destructive or irreversible operations—if filling a default could trigger a write, delete, or state mutation, the decision must escalate to a human approval workflow. Finally, avoid this prompt in regulated domains where auditability of every parameter source is mandatory; instead, use a clarification prompt that records explicit user confirmation for every value. The core risk this prompt addresses is silent intent corruption: the model assumes a reasonable default, but the user meant something else, and the system proceeds without anyone noticing.

To implement this prompt effectively, pair it with a pre-execution validation harness that checks the output decision against a hardcoded allowlist of defaultable parameters. If the prompt returns a default for a parameter not on that list, reject the decision and force clarification. Log every default-value decision with the parameter name, the default used, and the model's stated reason. This creates an audit trail that product teams can review to tune the default policy over time. Start with a conservative configuration where only truly safe defaults (e.g., page_size=20, sort_order='descending') are permitted, and expand based on production data showing low user-correction rates.

The prompt below is the core decision engine for the clarification-vs-default workflow. It accepts a tool schema, extracted arguments, a user request, and a risk policy, then outputs a structured decision. Use it as the single step before argument finalization in your tool-calling pipeline. The square-bracket placeholders are designed to be filled by your application harness before the model sees the prompt.

textCopy
You are an argument-filling decision engine. Your job is to decide whether a missing optional parameter should be filled with a safe default value or surfaced to the user for clarification.

## INPUT
- User request: [USER_REQUEST]
- Tool name: [TOOL_NAME]
- Tool description: [TOOL_DESCRIPTION]
- Extracted arguments so far: [EXTRACTED_ARGUMENTS]
- Missing optional parameter name: [MISSING_PARAMETER_NAME]
- Missing optional parameter description: [MISSING_PARAMETER_DESCRIPTION]
- Available default value: [DEFAULT_VALUE]
- Risk level of this tool call: [RISK_LEVEL]
- Operational context: [OPERATIONAL_CONTEXT]

## RULES
1. If the risk level is "high" or "critical", never use a default. Always request clarification.
2. If the default value would change the outcome in a way the user might not expect, request clarification.
3. If the parameter is a unique identifier (ID, email, account number), never guess. Request clarification.
4. If the parameter is a preference or subjective choice (tone, style, priority), request clarification.
5. If the parameter is a common configuration with a widely accepted default (page size, timeout, sort order) and the risk level is "low", use the default.
6. If the operational context indicates the user is in a hurry or has explicitly requested minimal interruptions, prefer defaults for low-risk parameters.
7. If the user request contains language suggesting they expect the default behavior ("just the usual", "standard", "normal"), use the default.
8. If you are uncertain after applying these rules, request clarification.

## OUTPUT SCHEMA
Return a JSON object with exactly these fields:
{
  "decision": "use_default" | "request_clarification",
  "reasoning": "string explaining which rule drove the decision",
  "default_value_used": null | "the value that would be used",
  "clarification_question": null | "a specific, single-sentence question for the user",
  "confidence": 0.0-1.0
}

## EXAMPLES
[EXAMPLES]

## CONSTRAINTS
[CONSTRAINTS]

Adaptation notes: Replace [EXAMPLES] with 2-4 few-shot examples showing both use_default and request_clarification decisions. Each example should include the full input context and the correct output JSON. Replace [CONSTRAINTS] with any additional business rules specific to your domain, such as "never default a currency value" or "always clarify for parameters that affect billing." The [RISK_LEVEL] field should be set by your application based on the tool's side-effect classification: low for read-only operations, medium for configuration changes, high for destructive or financial operations, and critical for irreversible actions. The [OPERATIONAL_CONTEXT] field can carry metadata such as "user_in_hurry": true, "session_type": "support_chat", or "previous_clarifications_this_turn": 2 to help the model calibrate its interruption threshold.

Before deploying this prompt, validate that your harness correctly populates every placeholder. A missing [RISK_LEVEL] will cause the model to apply rules inconsistently. Test with at least three cases per risk level and verify that the output JSON parses correctly in your application. If the model returns request_clarification with an empty clarification_question, treat that as a failure and retry with a stronger constraint on question generation.

This prompt operates as a pre-execution decision gate in your tool-calling pipeline. It should be invoked after argument extraction but before the tool call is dispatched. The model receives the extracted arguments, the tool schema, and the user's original request, then outputs a structured decision: use_default with the filled value and justification, or ask_user with a clarification question. The application layer reads this decision and either mutates the arguments and proceeds, or interrupts the flow to surface the question to the user. Do not call this prompt after the tool has already executed—its value is in preventing silent assumption errors, not in post-hoc explanation.

Integration pattern: Place this prompt as a middleware step between your argument extraction prompt and your tool execution handler. The typical call sequence is: (1) Extract arguments from user input and conversation context. (2) For each optional parameter that is absent, call this prompt with the parameter name, its description, the available defaults, and the risk context. (3) Parse the JSON decision from the response. (4) If decision is use_default, inject the default into the argument payload and proceed. (5) If decision is ask_user, surface the clarification_question to the user and pause execution until a response is received. Validation: Validate the JSON output against a strict schema before acting on it. If the model returns an invalid decision value or a clarification question that is empty, retry once with a stronger constraint instruction. If the retry also fails, escalate to a human reviewer rather than guessing. Logging: Log every decision with the parameter name, the chosen action, the default value used (if any), the justification, and the model's raw response. This audit trail is essential for tuning the boundary between acceptable defaults and risky assumptions over time.

Model choice and latency: This prompt is lightweight and can run on a fast, cost-effective model (e.g., GPT-4o-mini, Claude Haiku) because the decision logic is narrow—it does not require deep reasoning or large context. However, if your tool's optional parameters carry high risk (e.g., financial amounts, medical dosages, destructive flags), route to a more capable model or add a second-pass verification step. Retries and fallbacks: If the model returns a use_default decision but the justification is empty or contradicts the risk rules you provided, treat it as a low-confidence output and escalate to ask_user. Never execute a default value without a non-empty justification. Human review integration: For high-risk domains, add a human-in-the-loop step when the model chooses use_default for parameters marked as review_required: true in your tool schema. Queue the decision for approval before the tool call proceeds. This keeps latency low for safe defaults while adding a safety net for consequential ones.

What to avoid: Do not use this prompt for required parameters—missing required arguments should always trigger a clarification or a hard stop, never a default. Do not allow the model to invent defaults that are not in your provided [DEFAULT_OPTIONS] list; if you need dynamic defaults, compute them in application code and pass them as the only available options. Do not skip logging because you trust the model's judgment; production debugging of clarification-vs-default decisions requires a complete trace of every choice the system made. Finally, test this prompt with a golden dataset of parameter-absence scenarios where you know the correct decision. Measure precision (did we ask when we should have asked?) and recall (did we catch all the cases where a default would have been wrong?). Run these evals on every prompt or model change before releasing.