Hallucination Disclosure Policy Injection Prompt

This prompt is for AI product teams who need to embed a structured uncertainty communication policy directly into their system instructions. The core job-to-be-done is to force the model to disclose its confidence level, source availability, and capability boundaries whenever it generates a response that could be mistaken for a verified fact. The ideal user is an AI engineer or product manager who already has a working assistant and needs to add a transparent, testable disclosure layer without breaking the primary task. You need a clear definition of what constitutes a 'factual claim' in your domain, a set of confidence thresholds (e.g., 'high confidence,' 'low confidence,' 'speculative'), and a list of the model's known capability boundaries before you start.

Do not use this prompt if your application is purely creative (e.g., story generation), if the model's output is never presented as factual to an end-user, or if you cannot define what 'grounded' means in your context. This prompt is also insufficient as a standalone safety mechanism for high-stakes regulated domains like clinical diagnosis or legal advice; in those cases, it must be paired with mandatory human review, source-grounding via RAG, and a separate refusal policy. The disclosure policy works best when it is one layer in a defense-in-depth strategy, not the only guardrail.

Before implementing, map out the specific triggers for disclosure. A good policy distinguishes between 'I know this because I retrieved it,' 'I'm synthesizing from general knowledge,' and 'I'm speculating.' Your prompt must define these states clearly and provide the model with exact phrasing for each. The next step is to integrate this prompt into your system instructions and run it against your eval suite, specifically checking for over-disclosure (which erodes user trust) and under-disclosure (which creates liability).

This prompt template is designed to be injected into the system-level instructions of an AI assistant. Its primary job is to enforce a consistent, non-negotiable policy for disclosing uncertainty. Instead of relying on the model's default behavior, which can range from overconfidence to excessive hedging, this policy creates explicit triggers for disclosure language. The goal is to prevent the erosion of user trust that occurs when an AI fabricates details or presents speculation as fact. Adapt the placeholders to match your specific risk tolerance, product voice, and the types of tasks your assistant performs.

markdownCopy
# HALLUCINATION DISCLOSURE POLICY
You are an AI assistant operating under a strict Hallucination Disclosure Policy. Your primary directive is to provide accurate information. When accuracy cannot be guaranteed, your secondary directive is to communicate uncertainty clearly and immediately, before delivering the uncertain content.

## 1. CONFIDENCE-BASED DISCLOSURE TRIGGERS
Before generating any factual claim, perform an internal confidence assessment based on your training data and provided context.
- **Low Confidence:** If you are speculating, guessing, or the information is outside your verifiable knowledge cutoff, you MUST prepend the claim with: `[SPECULATION: I am not certain about the following, but here is a possible answer...]`
- **Medium Confidence:** If the information is plausible but you cannot verify it against a specific, provided source, you MUST prepend the claim with: `[LOW CONFIDENCE: I believe this is correct, but I cannot verify it right now...]`
- **High Confidence:** If the information is a well-established fact within your training data, you may state it directly without a disclosure tag.

## 2. SOURCE-GROUNDING DISCLOSURE
Your behavior must change based on the presence or absence of provided context.
- **No Context Provided:** If the user's question requires factual recall without any provided documents, you MUST add the following to the end of your response: `[SOURCE: This information is based on my internal knowledge base and was not verified against external documents.]`
- **Context Provided:** If you are answering from [CONTEXT], you must cite the specific source. If the [CONTEXT] does not contain the answer, you MUST state: `[NO ANSWER: The provided documents do not contain the information needed to answer this question.]` Do not guess.

## 3. CAPABILITY BOUNDARY DISCLOSURE
Acknowledge the inherent limitations of your architecture.
- **Future Events:** When asked about predictions or future events, you MUST state: `[LIMITATION: I cannot predict the future. The following is a projection based on current trends...]`
- **Personal Opinion:** When asked for subjective opinions, you MUST state: `[LIMITATION: As an AI, I do not have personal opinions. The following is a synthesis of common viewpoints...]`

## 4. OUTPUT FORMAT
Apply these rules without exception. The disclosure tags are part of the final output visible to the user. Do not hide them. Do not paraphrase them.

To adapt this template, start by replacing the bracketed disclosure tags with language that matches your product's tone of voice. A financial compliance application might use formal, structured warnings, while a creative brainstorming tool might use more casual, conversational hedges. Next, define the [CONTEXT] variable clearly in your application harness—this should be dynamically populated with the output of your retrieval-augmented generation (RAG) pipeline or left empty. The most critical adaptation is calibrating the confidence triggers. You should run a batch of known queries against the prompt and adjust the definitions of 'Low,' 'Medium,' and 'High' confidence until the model's self-assessment aligns with your factual accuracy metrics. Do not deploy this prompt without first testing it against a golden dataset to ensure it doesn't cause the model to over-refuse or undermine its own correct answers with excessive hedging.

Integrating a hallucination disclosure policy into a production system requires more than pasting the prompt into a system message. The policy must be enforced at the application layer through a combination of pre-processing, post-processing validation, and structured logging. The core implementation pattern involves injecting the disclosure policy into the system prompt, then wrapping the model's response in a validation harness that checks for required disclosure markers, confidence signals, and source grounding statements before the output reaches the user. This harness should be treated as a critical safety control, not optional formatting.

The recommended architecture uses a pre-response validation step that scans the raw model output for disclosure compliance. Implement a lightweight classifier or regex-based checker that verifies: (1) explicit uncertainty language is present when the model references unverified claims, (2) confidence qualifiers like 'Based on the provided sources...' or 'I don't have enough information to confirm...' appear when source grounding is absent, and (3) capability boundary statements are included when the user asks about real-time data, personal opinions, or future predictions. If the output fails validation, trigger a retry loop that appends the violation details to the model's next request as a correction instruction. Limit retries to a maximum of 2 attempts before escalating to a human review queue. For high-risk domains such as healthcare or legal, bypass retries entirely and route directly to human approval with the violation flagged. Model choice matters here: instruction-following models like claude-3-5-sonnet or gpt-4o handle structured disclosure rules more reliably than smaller open-weight models, which may require more aggressive post-processing.

Logging and observability are non-negotiable. Every disclosure check—pass or fail—must be logged with the session ID, the raw model output, the validation result, and the final output shown to the user. This audit trail serves two purposes: it enables trust and safety teams to review disclosure failures in aggregate, and it provides evidence for compliance reviews if a user later claims the system presented uncertain information as fact. Wire these logs into your existing observability stack (e.g., Datadog, Grafana, or custom trace storage) and set up alerts for disclosure failure rates exceeding 5% of total requests. A sudden spike often indicates a prompt regression, a model version change, or an adversarial input pattern that needs investigation. Avoid the temptation to silently strip uncertainty language to make outputs sound more confident—this undermines the entire purpose of the policy and creates liability.