Expertise Level Declaration Prompt Template

This prompt is for AI product teams and engineers who need to calibrate how an assistant declares its own expertise level, knowledge boundaries, and confidence. The job-to-be-done is producing a reusable system instruction block that prevents overconfidence, reduces hallucination risk, and aligns the assistant's self-presentation with its actual capabilities. The ideal user is a platform engineer, AI safety engineer, or product manager responsible for assistant behavior in production, especially in domains where users may over-trust the system or where capability honesty is a compliance requirement. Required context includes the assistant's actual scope of training data, tool access, and known limitations. Without this context, the prompt will produce generic disclaimers that fail under real user pressure.

Do not use this prompt when you need a full persona definition, a refusal policy, or a role-boundary system. This template focuses narrowly on expertise declaration and confidence calibration. It is not a substitute for behavioral policy authoring, guardrail injection, or domain-boundary enforcement. Use it alongside those playbooks when you need to layer expertise honesty into an existing system prompt. The prompt is most effective when the assistant has a well-defined scope—such as a vertical assistant in healthcare, finance, or legal—where overstatement of capability carries real risk. For general-purpose assistants, pair this with a capability declaration template to avoid vague 'I can help with anything' language that erodes user trust.

Before deploying, validate the output against adversarial probes that attempt to extract inflated expertise claims, and run multi-turn tests to confirm the declaration holds across conversation drift. The next step after generating the expertise declaration is to wire it into your system prompt architecture with clear priority relative to other instructions, then test it under production-like conditions. Avoid treating this as a one-time copy-paste exercise; expertise boundaries shift as models update, tools change, and product scope evolves, so version this block and re-evaluate it at each release gate.

This template produces a self-contained system prompt block that calibrates how an assistant presents its knowledge. It forces explicit expertise scoping, honest capability disclosure, and concrete rules for expressing uncertainty. Use it when you need the assistant to avoid sounding like a generic oracle and instead communicate a specific, bounded competence level that users can trust. The template is designed to be dropped into a larger system prompt or used as a standalone instruction block for a focused agent.

textCopy
You are an AI assistant with the following expertise profile:

## Expertise Scope
[EXPERTISE_DOMAINS]

## Knowledge Boundaries
- You have deep, reliable knowledge in: [STRONG_AREAS]
- You have working familiarity with: [FAMILIAR_AREAS]
- You have limited or no reliable knowledge in: [WEAK_AREAS]
- Your knowledge is current as of: [KNOWLEDGE_CUTOFF]

## Confidence Calibration Rules
1. When you are highly confident (you can cite specific sources, standards, or established practice), state your answer directly and indicate your confidence level.
2. When you are moderately confident (you understand the domain but the specific question has nuance or ambiguity), provide your best answer but explicitly note the uncertainty and its source.
3. When you have low confidence (the question falls outside your strong areas or involves speculation), say "I'm not confident in my answer here" and explain what you would need to know to answer better.
4. Never fabricate citations, statistics, case law, medical facts, or regulatory details. If you don't have the specific information, say so.

## Overconfidence Prevention
- Do not use absolute language ("always," "never," "guaranteed") unless the statement is a mathematical or logical certainty.
- Do not claim expertise in [WEAK_AREAS]. If asked, redirect to appropriate sources or escalate to a human.
- When asked for predictions, forecasts, or opinions, clearly label them as such and state the assumptions they depend on.
- If a user challenges your answer, acknowledge the challenge, re-examine your reasoning, and correct errors without defensiveness.

## Uncertainty Expression Templates
- "Based on [SOURCE/DOMAIN], my understanding is..."
- "I'm reasonably confident that..., but [SPECIFIC_CAVEAT]."
- "This falls outside my strong areas. What I can tell you is [BOUNDED_ANSWER], but you should verify with [RECOMMENDED_SOURCE]."
- "I don't have enough information to answer that reliably. Here's what I'd need to know: [GAPS]."

## Escalation Threshold
If a request requires expertise in [WEAK_AREAS] or involves [HIGH_RISK_DOMAINS], respond with: "This requires expertise beyond my configured knowledge boundaries. I recommend consulting [ESCALATION_PATH]."

To adapt this template, replace each square-bracket placeholder with concrete content specific to your assistant's domain. [EXPERTISE_DOMAINS] should be a short paragraph or bullet list describing the assistant's overall expertise scope. [STRONG_AREAS], [FAMILIAR_AREAS], and [WEAK_AREAS] should be explicit lists of topics, not vague categories. [HIGH_RISK_DOMAINS] should name areas where incorrect answers carry real harm—legal advice, medical diagnosis, financial recommendations, safety-critical engineering. [ESCALATION_PATH] should point to a real resource: a human team, a verified knowledge base, or a documented process. The uncertainty expression templates are starting points; customize them to match your assistant's voice and the expectations of your users. Test the adapted prompt against questions in each confidence tier to verify the assistant follows the calibration rules rather than defaulting to fluent overconfidence.

The Expertise Level Declaration prompt is not a one-shot generation task; it is a system-level instruction component that must be injected into every user-facing turn. The implementation harness should treat the generated expertise-scoping language as a prepended system message or a dynamic system prompt prefix that is assembled at runtime before the main conversation context. This means the application layer is responsible for calling the declaration prompt once per session (or per user context change), caching the result, and injecting it into the primary assistant prompt. Do not call this prompt on every user message—expertise declarations should remain stable for the duration of a session unless the user's role, the assistant's configured capability tier, or the domain context changes.

Validation and retry logic is critical because an overconfident or underconfident expertise declaration will poison every subsequent interaction. After generating the declaration, run a structured validation pass that checks for: (1) presence of explicit capability boundaries, (2) absence of absolute certainty claims unless the knowledge domain is fully deterministic, (3) inclusion of uncertainty language for probabilistic or incomplete knowledge areas, and (4) alignment with the configured [EXPERTISE_TIER] and [DOMAIN_SCOPE] inputs. If validation fails, retry with the failure reason appended to the prompt context. Implement a maximum of three retries before falling back to a hardcoded safe declaration and logging the failure for review. For high-stakes domains such as healthcare, legal, or finance, route all generated declarations through a human review queue before they are deployed to production sessions.

Model choice and tool integration should favor models with strong instruction-following behavior for this prompt. The expertise declaration is a meta-instruction that shapes all downstream behavior, so prefer models that resist role-drift and maintain system prompt fidelity across long contexts. If your application uses retrieval-augmented generation (RAG), ensure the expertise declaration explicitly scopes the assistant's knowledge to the retrieved sources—do not let the model claim expertise beyond what the retrieval pipeline can ground. Wire the declaration into your observability pipeline by logging the generated declaration alongside session IDs, so that expertise-claim failures can be traced back to the specific declaration version that was active. When updating expertise tiers or domain scopes, version the declarations and run regression tests against a golden set of user queries to confirm that expertise claims remain calibrated and do not silently drift toward overconfidence or excessive refusal.