Capability Honesty and Uncertainty Expression Prompt

This prompt is for product teams and AI engineers who need their production assistant to express calibrated uncertainty instead of fabricating confident-sounding answers. The core job-to-be-done is to prevent hallucination by giving the model explicit, testable rules for when to say 'I don't know,' when to ask a clarifying question, and how to communicate its confidence level to the user. The ideal user is an engineering lead or AI safety engineer integrating a model into a high-stakes workflow—such as clinical documentation, legal research, or financial analysis—where a wrong answer presented as a fact is far more damaging than a refusal to answer.

You should use this prompt when the cost of a hallucination is high and the assistant operates in a domain where the model's training data is likely incomplete or outdated. It is particularly effective when paired with a retrieval-augmented generation (RAG) system, as the prompt can enforce a strict policy of only answering from provided evidence. Do not use this prompt in isolation for low-stakes, creative, or brainstorming tasks where a conversational, speculative tone is acceptable; the strict uncertainty rules will make the assistant feel overly cautious and break the user experience. This prompt is a behavioral policy layer, not a knowledge patch.

Before implementing, you must define your risk tolerance. Decide on a confidence taxonomy (e.g., 'high confidence,' 'low confidence,' 'unable to answer') and map it to specific output behaviors. The prompt template requires you to fill in concrete [CONFIDENCE_LEVELS] and [EVIDENCE_REQUIREMENTS]. The next step is to copy the prompt template and adapt these placeholders to your domain's specific failure modes. Avoid the temptation to make the prompt overly polite; direct, structural instructions about uncertainty are more reliably followed than soft, conversational requests.

The following prompt template is designed to be inserted into a system-level instruction block. It establishes a behavioral contract that requires the assistant to calibrate its confidence, refuse out-of-scope requests, and surface ambiguity before acting. The template uses square-bracket placeholders that you must replace with your domain-specific values before deployment. Every placeholder is a required integration point—leaving one unresolved will create a gap in the assistant's honesty policy.

textCopy
## Capability Honesty and Uncertainty Policy

You are an assistant with clearly defined capabilities and limitations. You must never fabricate information, guess when uncertain, or imply capabilities you do not possess.

### Core Rules
1. When you do not know something with high confidence, say so explicitly. Use phrases like "I don't have enough information to answer that confidently" or "I'm uncertain about this, but here's what I can tell you."
2. When a request falls outside your defined scope, refuse clearly and redirect. Say: "I'm not able to [RESTRICTED_ACTION]. I can help you with [ALLOWED_ALTERNATIVE] instead."
3. When a request is ambiguous, ask a clarifying question before proceeding. Do not assume the user's intent.
4. Never state a capability you cannot reliably perform. If asked "Can you [ACTION]?", answer honestly based on your actual tool access and knowledge boundaries.

### Confidence Calibration
For every substantive claim or action, internally assess your confidence level:
- **High confidence**: You have direct evidence, tool output, or source grounding. Proceed normally.
- **Medium confidence**: You are reasoning from partial information or inference. Disclose this: "Based on available information, it appears that... but I recommend verifying..."
- **Low confidence**: You lack sufficient evidence or the question exceeds your knowledge boundary. Say: "I don't have enough information to answer this reliably."

### Scope Boundaries
Your defined capabilities are:
- [CAPABILITY_LIST]

Your explicit limitations are:
- [LIMITATION_LIST]

Requests outside these boundaries must be refused with a clear explanation and, where possible, a safe redirection.

### Clarification Triggers
Ask a clarifying question when:
- The user's request is missing critical parameters: [CRITICAL_PARAMETER_LIST]
- The request could be interpreted in multiple ways
- The user's intent is unclear and guessing would risk a harmful or incorrect outcome

### Uncertainty Language Templates
Use these templates when expressing uncertainty:
- "I'm not confident about this, but here's what I can share: [PARTIAL_ANSWER]"
- "This falls outside my verified knowledge. I recommend consulting [SOURCE_OR_EXPERT]."
- "I need clarification before I can proceed: [SPECIFIC_QUESTION]"

### Prohibited Behaviors
- Do not fabricate citations, data, or capabilities.
- Do not answer with false certainty when you are guessing.
- Do not silently skip required clarification questions.
- Do not claim access to tools, data sources, or knowledge you do not have.

To adapt this template, replace each placeholder with concrete, testable values. For [CAPABILITY_LIST], enumerate only the actions the assistant can reliably perform—avoid vague language like "assist with tasks." For [LIMITATION_LIST], list specific exclusions such as "I cannot provide medical diagnoses" or "I cannot access real-time financial data." The [CRITICAL_PARAMETER_LIST] should include fields the assistant must have before acting, such as user_id, date_range, or account_type. After replacing placeholders, run the prompt through a set of adversarial test cases: ask the assistant to perform a restricted action, provide an ambiguous request missing a critical parameter, and probe for fabricated capabilities. If the assistant complies with any prohibited behavior, tighten the relevant rule or add a concrete counterexample to the policy block. For high-risk domains, pair this prompt with a human-review step before any irreversible action is taken.

This prompt is not a standalone chatbot instruction; it is a behavioral policy layer that must be integrated into your existing system prompt architecture. The template defines how the model should express uncertainty, not when it should be invoked. The application layer is responsible for detecting high-stakes or low-confidence scenarios and injecting this policy alongside the primary task instructions. In a typical RAG or tool-use pipeline, you would prepend this prompt to the final generation step, after retrieval and reasoning are complete, to govern the output's honesty and calibration.

The implementation should include a confidence gate before the final response is shown to the user. After the model generates an answer, parse the structured output for the confidence_score and uncertainty_flags fields. If the score falls below a defined threshold (e.g., confidence_score < 0.7) or if uncertainty_flags contains ['speculation', 'missing_source'], route the response to a human review queue or trigger a clarification question loop instead of displaying it directly. Use a JSON schema validator like jsonschema in Python or zod in TypeScript to enforce the output structure. If validation fails, retry the generation once with an explicit error message appended to the prompt: Your previous output did not match the required JSON schema. Please correct the format and ensure all required fields are present.

For production observability, log the confidence_score, uncertainty_flags, and the full structured output to your tracing system (e.g., LangSmith, Braintrust, or a custom logging pipeline). This data is essential for evaluating whether the model's self-assessed confidence correlates with actual correctness. Set up a periodic eval that samples logged responses, has a domain expert rate their factual accuracy, and computes a calibration curve. If the model consistently reports high confidence on incorrect answers, you have a calibration failure that requires prompt tuning or model upgrade, not just a threshold adjustment. Avoid wiring this prompt into systems where speed is the primary requirement and uncertainty is acceptable; the structured output generation and validation steps add latency that may be unacceptable for real-time chat without streaming.