Review Item Stakeholder Identification Prompt for Routing

This prompt is designed for enterprise product teams and platform engineers who need to programmatically determine the correct set of human reviewers, approvers, and informed parties for a given work item before it enters a review queue. The core job-to-be-done is translating an organization's implicit routing policy—often a complex mix of role-based access, compliance requirements, and domain expertise—into a structured stakeholder map that an application can use to notify the right people. You should use this prompt when a review item's content, risk level, or regulatory context dictates a multi-party review that cannot be resolved by a single static routing rule in application code.

The ideal user is a developer or AI architect building a human-in-the-loop triage system. They have access to the review item's full content, a defined organizational chart or role taxonomy, and a set of routing policies (e.g., 'all P0 items require a VP of Engineering and a Security Lead'). The prompt requires these inputs to be assembled into a [CONTEXT] block. It is not a replacement for a policy engine; it is a reasoning layer that interprets policy against the specifics of a case. Do not use this prompt for simple, single-owner routing that can be handled by a database lookup, or in environments where the organizational structure and policy are too fluid to be documented reliably as input context.

Before integrating this prompt, ensure you have a mechanism to validate its output against a known-good authority matrix. The primary failure mode is not a malformed JSON output, but a stakeholder map that omits a required approver for a high-risk action or, conversely, over-includes individuals, causing notification fatigue. Implement an evaluation harness that checks for missing critical roles defined in your policy and flags items where the number of identified stakeholders exceeds a reasonable threshold. The next step after reading this playbook is to adapt the prompt template with your specific role taxonomy and policy language, then run it against a golden dataset of 20-30 historical review items with known correct stakeholder assignments.

This prompt template is the core instruction set for transforming a raw review item into a structured stakeholder map. It is designed to be copied directly into your prompt management system, with square-bracket placeholders that your application must populate at runtime. The template forces the model to reason about organizational roles, authority levels, and the minimum necessary distribution list, rather than simply returning a generic list of department heads.

textCopy
You are an organizational routing specialist. Your task is to analyze a review item and produce a precise stakeholder map identifying every person or role that must approve, be informed, or provide input before this item can be resolved.

## INPUT
Review Item: [REVIEW_ITEM]
Item Type: [ITEM_TYPE]
Department of Origin: [ORIGIN_DEPARTMENT]
Regulatory Context: [REGULATORY_CONTEXT]

## ORGANIZATIONAL CONTEXT
[ORG_CHART_SUMMARY]
[APPROVAL_POLICIES]

## OUTPUT SCHEMA
Return a valid JSON object with this exact structure:
{
  "item_id": "string",
  "stakeholders": [
    {
      "role_or_name": "string",
      "stakeholder_type": "required_approver | informed_party | optional_reviewer",
      "authority_level": "final_approver | conditional_approver | advisory_only",
      "approval_sequence": number,
      "rationale": "string explaining why this stakeholder is included",
      "condition": "string describing the condition for involvement, or null if unconditional"
    }
  ],
  "missing_stakeholder_risks": ["string describing any role that might be needed but wasn't identified in the org context"],
  "routing_instructions": "string summarizing the approval sequence and any parallel vs. serial routing requirements"
}

## CONSTRAINTS
1. Include only stakeholders with a direct, defensible connection to this item. Do not pad the list with generic department heads.
2. If the item type or regulatory context triggers a specific policy, cite that policy in the rationale.
3. The approval_sequence must start at 1 for the first required approver and increment. Use 0 for informed parties who do not approve.
4. If you are uncertain about a stakeholder's necessity, list them in missing_stakeholder_risks instead of the main stakeholders array.
5. Do not fabricate names. Use role titles unless a specific name is provided in the input.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template for your environment, replace the placeholders with data from your application context. [ORG_CHART_SUMMARY] should be a concise, machine-readable description of relevant reporting structures and approval authorities, not a raw directory dump. [APPROVAL_POLICIES] should encode your organization's rules, such as 'all PII-related items require Data Protection Officer approval.' The [FEW_SHOT_EXAMPLES] placeholder is critical for teaching the model the difference between a required approver and an informed party in your specific domain. Start with two examples: one low-risk item with a single approver, and one cross-functional item requiring sequenced approval. Validate the output against the schema before routing. If the missing_stakeholder_risks array is non-empty, route the item to a queue coordinator for manual review before sending notifications.

This prompt is designed to sit inside a review routing pipeline, not as a standalone chat interaction. The application should invoke it immediately after a review item is created and before it enters any team queue. The model receives the item payload, organizational context, and routing policy, and returns a structured stakeholder map. The application then uses that map to determine queue placement, notification targets, and approval sequencing. Because this prompt influences who sees what and when, treat its output as a routing suggestion that requires deterministic validation before any notification is sent.

Wire the prompt into a service function that accepts a review item object and a routing policy configuration. The function should: (1) assemble the prompt with the item's title, description, source system, risk classification, and affected resources; (2) inject the organization's role taxonomy and approval policy from a configuration store, never from the prompt itself; (3) call the model with a low temperature (0.0–0.2) and a structured output schema that enforces the stakeholders array with role, name_or_group, authority_level, rationale, and is_required fields; (4) validate the response against a known role allowlist and reject any hallucinated roles; (5) cross-check that every resource owner and policy-defined required approver appears in the output, flagging missing entries for human review; (6) log the full prompt, response, and validation result for auditability. If validation fails, retry once with an error-augmented prompt that lists the specific missing or invalid roles. If the retry also fails, route the item to a manual triage queue with the validation errors attached.

Model choice matters here. Use a model with strong instruction-following and structured output support, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that are more likely to hallucinate role names or miss required approvers. If your organization's role taxonomy is large or changes frequently, consider providing it as a compact JSON object inside the prompt rather than relying on the model's parametric knowledge. For high-stakes workflows—such as security incident review or compliance violation routing—always require a human to confirm the stakeholder map before notifications are dispatched. The application should surface the model's output alongside the validation results, highlighting any over-included reviewers (people who don't need to see this item) and any missing required approvers. This turns the prompt from a black-box router into a reviewable, auditable decision-support tool.