User Role-Based Intent Detection Prompt for Query Rewriting

This prompt is designed for enterprise RAG system architects and platform engineers who serve multiple user personas from a single knowledge base. The core job-to-be-done is role-aware query rewriting: taking a surface-level user question and a known user role (such as 'support engineer', 'product manager', or 'compliance officer') and producing a rewritten retrieval query that is scoped to the permissions, terminology, and information needs of that specific role. Without this step, a question like 'What is the status of project Alpha?' retrieves the same generic documents for every user, ignoring the fact that a support engineer needs open incident records while an executive needs a milestone summary.

You should use this prompt when your retrieval system has a defined set of user roles, each with distinct access scopes or information priorities, and when the same natural-language query should produce materially different retrieval results depending on who is asking. The prompt requires two inputs at minimum: the raw [USER_QUERY] and a structured [USER_ROLE_CONTEXT] object containing the role name, a brief description of that role's responsibilities, and any explicit permission boundaries or document scopes. Optionally, you can provide a [ROLE_TAXONOMY] listing all valid roles to prevent hallucinated role interpretations. Do not use this prompt when your knowledge base is public and unsegmented, when all users share identical access permissions, or when the query itself already contains explicit role-specific jargon that makes rewriting unnecessary. It is also inappropriate for anonymous or unauthenticated user sessions where no role context exists.

Before wiring this into production, define your evaluation harness. The primary success criterion is role-appropriate retrieval divergence: given the same surface question and two different roles, the rewritten queries must retrieve measurably different document sets that align with each role's scope. A secondary criterion is permission boundary preservation: the rewritten query must never expand retrieval scope beyond what the role is authorized to see. Common failure modes include role hallucination when the provided role context is vague, over-narrowing the query so it misses relevant cross-functional documents, and producing rewritten queries that leak permission-scope hints into the query string itself rather than keeping those as separate filter metadata. Always pair this prompt with a downstream metadata filter enforcement layer; the prompt suggests scope, but the retrieval system must enforce it.

This prompt template is the core instruction set for a system that rewrites a user's query based on their organizational role. The goal is to take the same surface-level question—such as 'What's the status of Project Alpha?'—and produce different retrieval queries for an engineer, a product manager, and a finance lead. The template uses square-bracket placeholders for all dynamic inputs, making it ready to be wired into an application's prompt assembly pipeline. Before copying, ensure you have defined your role taxonomy, the knowledge base's permission model, and the expected output schema.

textCopy
You are a query rewriting agent for an enterprise knowledge base. Your task is to detect the underlying intent of a user's question based on their role and rewrite the query to retrieve role-appropriate content.

## INPUT
User Role: [USER_ROLE]
User Query: [USER_QUERY]

## ROLE-INTENT MAPPING
Use the following role definitions to infer intent:
[ROLE_DEFINITIONS]

## OUTPUT SCHEMA
Return a valid JSON object with the following fields:
{
  "detected_intent": "string",
  "role_aware_query": "string",
  "permission_scope_hints": ["string"],
  "reasoning": "string"
}

## CONSTRAINTS
- The `role_aware_query` must be a rewritten string optimized for a vector or keyword search over the knowledge base.
- The `permission_scope_hints` must be a list of access control tags (e.g., document labels, team names) that a search engine can use to filter results.
- Do not answer the user's question. Only output the rewritten query and metadata.
- If the role is unknown or not in the provided mapping, set `detected_intent` to "general_inquiry" and do not apply role-specific scoping.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

To adapt this template for your system, start by populating the [ROLE_DEFINITIONS] placeholder with a structured mapping of roles to their typical intents and information needs. For example, an 'Engineer' role might map to intents like 'debugging', 'implementation_detail', or 'system_status', while a 'Sales' role maps to 'deal_status', 'customer_history', or 'competitive_positioning'. The [FEW_SHOT_EXAMPLES] placeholder is critical for consistent behavior; provide at least three examples that show the same query being rewritten for different roles. The [USER_QUERY] and [USER_ROLE] placeholders should be injected by your application at runtime. If your knowledge base uses a specific taxonomy for access control, ensure the permission_scope_hints output aligns with those exact tags to enable automated filtering in your retrieval pipeline. For high-stakes deployments, add a [RISK_LEVEL] constraint that forces the model to flag queries that might cross permission boundaries, triggering a human review step before retrieval.

This prompt is not a standalone chatbot. It is a pre-retrieval transformer that must sit between the user input and your retrieval system. The application layer is responsible for injecting the correct [USER_ROLE] and [PERMISSION_SCOPE] from your identity provider or session context before calling the model. The prompt output—a rewritten query and permission-scope hints—should be passed directly to your retrieval backend as filter constraints, not displayed to the user. Treat the permission_scope_hints field as structured metadata that your vector database or search engine uses to enforce document-level access control at query time.

Validation and retry logic: Parse the model output as JSON and validate that the rewritten_query field is a non-empty string and that permission_scope_hints is an array of strings matching your known access control labels. If the model returns malformed JSON, retry once with a stricter output constraint appended to the prompt. If the intent_shift_summary is empty but the query was rewritten, accept the output but log a warning. Do not proceed to retrieval if rewritten_query is missing or identical to the raw user input without any role adaptation—this indicates the model failed to apply role context and should trigger a fallback to the original query with a default broad-scope filter.

Model choice and latency budget: This prompt works best with models that have strong instruction-following and JSON output discipline, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Expect 200-500ms latency for this pre-retrieval step. If your retrieval pipeline has a strict sub-100ms budget, consider caching rewritten queries by (raw_query, user_role) pairs for frequently asked questions from the same role. For high-throughput systems, batch role-identical queries where possible, but never batch across different roles—the whole point is role-specific rewriting.

Logging and observability: Log the raw user query, injected role, rewritten query, intent shift summary, and permission scope hints as a single trace span. This is critical for debugging retrieval failures: if a user says 'I can't find the policy,' you need to know whether the role was correctly detected, whether the query was rewritten appropriately, and whether the permission scope hints excluded the right documents. Attach the intent detection confidence to your retrieval metrics so you can correlate intent misclassification with answer quality degradation.

Human review gates: For enterprise deployments where role misclassification could expose sensitive documents, add a confidence threshold check. If the model's intent shift summary contains hedging language like 'possibly' or 'unclear,' or if the permission scope hints include a catch-all wildcard, route the query to a human reviewer or apply the most restrictive scope as a safe default. Never use the permission scope hints as the sole access control mechanism—your retrieval backend must still enforce document-level ACLs independently. The prompt's scope hints are an optimization to reduce retrieval noise, not a security boundary.