Department Scope Detection Prompt

This prompt is designed for internal AI platform teams who need to route unstructured employee requests to the correct department queue. The job-to-be-done is deterministic classification: given a natural language request, the prompt must output a single department label and a confidence score based on function, policy, and authority boundaries. The ideal user is an infrastructure engineer or platform architect building a multi-department routing layer where misclassification creates compliance risk, wasted human review time, or broken downstream automation.

To use this prompt effectively, you must provide a defined department taxonomy with clear scope descriptions, a set of concrete examples for each department, and a policy for handling cross-department ambiguity. The prompt works best when departments have distinct functional boundaries—for example, separating IT infrastructure requests from HR benefits inquiries. It is not suitable for open-ended topic discovery, sentiment analysis, or cases where department boundaries are fluid and undefined. If your taxonomy is still evolving, start with a smaller set of well-separated departments and expand after validating classification accuracy.

Do not use this prompt when the input contains regulated personal data that should not pass through a general-purpose model, or when the cost of a single misclassification is unacceptable without human review. For high-stakes routing—such as legal holds, safety incidents, or financial approvals—this prompt should feed a confidence threshold gate that escalates low-confidence results to a human triage queue. The next step after reading this section is to review the prompt template and adapt the department taxonomy, examples, and confidence thresholds to your organization's specific routing map.

This template is designed for internal AI platform teams building routing middleware that sits between employee-facing interfaces and departmental queues. The prompt accepts unstructured text—such as a Slack message, ticket description, or email body—and maps it to a predefined department taxonomy. The core challenge it addresses is cross-department ambiguity: requests that touch multiple functions, mention overlapping responsibilities, or use language that could reasonably route to two or more departments. The template forces explicit reasoning about department boundaries before producing a classification, which makes failures auditable and retriable.

textCopy
You are a department scope classifier for an internal enterprise platform. Your job is to read an employee request and determine which department should handle it based on the department definitions, policies, and authority boundaries provided.

## DEPARTMENT DEFINITIONS
[DEPARTMENT_TAXONOMY]

## CLASSIFICATION RULES
- Assign exactly ONE primary department per request.
- If the request spans multiple departments, choose the department with primary authority over the core action or decision being requested.
- If the request is ambiguous between two departments, flag it as [AMBIGUITY_FLAG] and explain the conflict.
- If the request falls outside all defined departments, classify as "OUT_OF_SCOPE" and explain why.
- Do not invent departments. Only use labels from the provided taxonomy.

## INPUT
[EMPLOYEE_REQUEST]

## OUTPUT FORMAT
Return a valid JSON object with exactly these fields:
{
  "primary_department": "string (exact match from taxonomy)",
  "confidence": "HIGH | MEDIUM | LOW",
  "reasoning": "string (explain which signals mapped to this department and why alternatives were excluded)",
  "ambiguity_flag": "boolean",
  "ambiguity_notes": "string (if ambiguity_flag is true, explain the conflicting departments and what additional information would resolve it)",
  "out_of_scope": "boolean",
  "out_of_scope_reason": "string (if out_of_scope is true, explain why no department matches)"
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

To adapt this template, start by replacing [DEPARTMENT_TAXONOMY] with your actual department list, including each department's name, primary functions, and authority boundaries. The taxonomy should be explicit enough that a new employee could read it and correctly route requests. For [CONSTRAINTS], add any organization-specific rules such as "Legal must review any request containing contract terms" or "IT handles all software access requests regardless of which department initiated them." The [EXAMPLES] block should include at least three few-shot examples covering clear single-department cases, one cross-department ambiguity case, and one out-of-scope case. If your platform supports tool use, you can extend the output schema to include a suggested_queue_id or routing_key field that maps directly to your ticket system. For high-stakes deployments, add a [RISK_LEVEL] field to the constraints that triggers human review when confidence is LOW or ambiguity_flag is true.

The Department Scope Detection Prompt is designed to sit at the ingress layer of an internal AI platform, immediately after input ingestion and before any department-specific tools, policies, or context are applied. Its output is a structured classification decision that downstream middleware uses to route the request to the correct department queue. The implementation harness must treat this prompt as a deterministic routing component, not a conversational interface. That means the application layer is responsible for enforcing the department taxonomy, validating the output schema, handling low-confidence or ambiguous results, and ensuring that no request reaches a department-specific workflow without a verified classification label.

Wire the prompt into your application with a strict JSON schema validator that checks for the required fields: department, confidence, reasoning, and alternative_departments. If the model returns malformed JSON, missing fields, or a department outside your approved taxonomy, the harness should trigger a retry with the same input and a stronger format reminder. After two failed retries, escalate the request to a human review queue rather than guessing. For model choice, a fast instruction-tuned model like GPT-4o-mini or Claude 3.5 Haiku is usually sufficient for department classification; reserve larger models for cases where the confidence score falls below your threshold (e.g., <0.85) and the request requires deeper reasoning. Log every classification decision with the input hash, department label, confidence score, model version, and timestamp so you can audit routing accuracy over time and detect taxonomy drift.

The most common production failure mode is cross-department ambiguity, where a request legitimately spans two departments (e.g., a legal question about an HR policy). Your harness should handle this by checking the alternative_departments field and, when the primary confidence is below your threshold, routing to both queues with a cross-reference tag or escalating to a triage role. Do not silently drop the secondary department. Also implement a feedback loop: when a department owner re-routes a misclassified request, capture that correction as a labeled example for future prompt refinement or few-shot selection. Start with a human review step for all low-confidence classifications before automating fully, and only remove that step once your eval metrics show sustained routing accuracy above your target threshold across all departments.