Domain Expert Persona Prompt Template

This prompt is for AI engineers and product teams building specialized assistants that must operate within a bounded technical domain, such as network security, tax accounting, or clinical pharmacology. The job-to-be-done is producing a stable, testable persona specification that defines the assistant's knowledge boundaries, domain terminology, and calibrated confidence language before any user-facing interaction occurs. You need this when your assistant must sound like a domain expert without fabricating expertise outside its scope, and when downstream evaluators must be able to measure whether the assistant stays inside its knowledge boundary under real user pressure.

Use this template when the assistant's credibility depends on knowing what it does not know. The prompt forces explicit decisions about where the assistant's knowledge ends, how it expresses uncertainty, and what language it uses to decline out-of-scope questions without sounding evasive. This is not a general-purpose chatbot persona prompt. Do not use it for creative writing assistants, open-ended brainstorming tools, or assistants where tone and brand voice matter more than domain precision. It is also not a replacement for retrieval-augmented generation (RAG) or tool-augmented workflows. If the assistant needs to query live data sources, call APIs, or ground answers in retrieved evidence, this persona prompt should be paired with those capabilities, not used as a substitute.

The primary risk this prompt addresses is overconfidence in domain-adjacent topics. A medical coding assistant that confidently answers clinical treatment questions, or a tax assistant that gives legal advice, creates real liability. This template includes eval criteria for domain-appropriate uncertainty expression, so you can test whether the assistant correctly identifies boundary questions and responds with calibrated hedging rather than fluent fabrication. Before deploying, run the output through a persona consistency eval rubric and a cross-turn instruction stability test to confirm the knowledge boundary holds across long sessions and varied user phrasings.

This template produces a structured persona specification for a specialized assistant in a technical domain. It defines the assistant's identity, domain terminology, knowledge boundaries, and calibrated confidence language. The output is designed to be inserted into a system prompt or used as a behavioral contract that persists across multi-turn interactions. Use this when you need a consistent, testable expert persona rather than a generic helpful assistant.

textCopy
You are a persona design specialist. Your task is to produce a structured domain expert persona specification based on the inputs provided.

## Inputs
[DOMAIN]: The technical domain the assistant will operate in.
[USER_PROFILE]: The expected user's role, expertise level, and goals.
[ASSISTANT_PURPOSE]: What the assistant is expected to do for the user.
[KNOWLEDGE_BOUNDARIES]: Explicit limits on what the assistant should claim to know or do.
[UNCERTAINTY_CALIBRATION]: Rules for how the assistant should express confidence, uncertainty, and knowledge gaps.
[REFUSAL_POLICY]: Topics or actions the assistant must decline, and how to decline them.
[TONE_PROFILE]: Desired tone attributes such as formality, directness, and verbosity.
[OUTPUT_SCHEMA]: The expected structure of the persona specification (see below).

## Output Schema
Produce a JSON object with the following fields:
- `identity`: A concise statement of who the assistant is and its role.
- `domain_terminology`: An array of key terms and their definitions the assistant should use correctly.
- `knowledge_boundaries`: An array of explicit statements about what the assistant knows and does not know.
- `uncertainty_language`: An array of calibrated phrases for expressing high confidence, moderate confidence, low confidence, and unknown answers.
- `refusal_templates`: An array of refusal responses for disallowed topics, each with a trigger condition and a safe-decline message.
- `tone_rules`: An array of tone constraints (e.g., "never use exclamation marks", "prefer bullet points for lists").
- `behavioral_constraints`: An array of hard rules the assistant must never violate.

## Constraints
- Do not invent domain facts not present in the inputs.
- Do not claim capabilities beyond [KNOWLEDGE_BOUNDARIES].
- Every uncertainty phrase must be appropriate for a domain expert, not a generalist.
- Refusal templates must be polite, precise, and resistant to re-prompting attacks.

To adapt this template, replace each square-bracket placeholder with concrete values from your product requirements or domain research. The [OUTPUT_SCHEMA] can be extended with additional fields such as tool_permissions, escalation_paths, or citation_rules if your assistant uses tools or retrieved evidence. After generating the persona specification, validate it against the Persona Consistency Eval Rubric Prompt and run the Role-Specific Uncertainty Expression Prompt to confirm that confidence language is calibrated for your risk level. For high-stakes domains, always include human review of the generated persona before deployment.

The Domain Expert Persona Prompt Template is not a one-shot generation task; it is a specification compiler. In production, you typically call this prompt once per persona definition (or on version update) and store the resulting persona specification as a structured object in a configuration store, database, or feature flag system. The downstream assistant or agent then reads this persona specification as part of its system prompt assembly at runtime. This separation means the expensive persona-generation call happens infrequently, while the runtime system prompt injection is cheap and cacheable.

Wire the prompt into an application with a validation layer that checks the generated persona specification before it is stored. The output should be a JSON object with fields like identity, domain_expertise, knowledge_boundaries, tone_profile, uncertainty_calibration, refusal_policy, and capability_declaration. Validate that all required fields are present, that knowledge_boundaries contains explicit exclusions, and that uncertainty_calibration defines at least three confidence levels with example language for each. If validation fails, retry the generation call with the validation errors injected into the [CONSTRAINTS] placeholder. After three failed retries, escalate to a human reviewer through a review queue rather than silently storing a broken specification.

For high-stakes domains such as healthcare, legal, or finance, add a human-in-the-loop approval gate after validation passes. The generated persona specification should be surfaced in a review UI that shows the original inputs, the compiled specification, and a diff against the previous version if one exists. The reviewer should explicitly approve the knowledge_boundaries and uncertainty_calibration sections before the specification goes live. Log the reviewer identity, timestamp, and approval decision for audit trails. Never auto-deploy a domain expert persona without human sign-off when the assistant will operate in a regulated context or make claims that could be mistaken for professional advice.

On the runtime side, when the downstream assistant consumes the persona specification, implement drift detection. Compare the assistant's actual responses against the stored tone_profile and uncertainty_calibration rules using an LLM-judge eval that runs periodically on sampled conversation turns. If drift is detected above a threshold, trigger a re-evaluation of the persona specification or flag the session for review. This closes the loop between persona design and production behavior, which is where most persona implementations silently degrade.