Bias Incident Report Triage and Escalation Prompt

This prompt is designed for responsible AI and trust-and-safety teams who need to classify, prioritize, and route incoming bias incident reports at scale. The core job-to-be-done is to transform a free-text incident description into a structured triage record that preserves critical context—harm category, severity, affected group, and evidence quality—while determining the correct escalation path. The ideal user is an MLOps engineer, safety platform builder, or product operations lead integrating this prompt into an automated incident intake pipeline. You should use this prompt when your organization receives a high volume of fairness-related reports and needs consistent, auditable routing decisions that prevent both under-escalation (missing real harm) and over-escalation (flooding human review queues with noise).

Do not use this prompt as a standalone fairness auditor or to make final policy determinations. It is a triage tool, not a replacement for human judgment in high-severity cases. The prompt requires several concrete inputs to function reliably: a raw incident report ([INCIDENT_REPORT]), your organization's defined harm taxonomy ([HARM_CATEGORIES]), severity definitions with escalation thresholds ([SEVERITY_SCALE]), and a routing map that links category-severity pairs to specific review teams ([ROUTING_TABLE]). Without these structured inputs, the model will improvise classifications and routing decisions, producing inconsistent and un-auditable results. You must also provide clear [CONSTRAINTS] that define when the prompt should abstain entirely—for example, when the report contains insufficient information to classify or when it describes potential illegal activity requiring immediate legal review rather than standard triage.

Before deploying this prompt, ensure you have instrumented your pipeline to capture the model's confidence scores and classification rationale. High-risk fairness decisions demand traceability: every triage output should be logged with the prompt version, input report, model response, and final routing destination. If your use case involves legally protected characteristics or regulated jurisdictions, add a mandatory human review step for all severity levels above a defined threshold. The next section provides the copy-ready prompt template you can adapt to your organization's specific taxonomy and escalation paths.

This section provides the core prompt template for triaging bias incident reports. It is designed to be copied directly into your prompt management system, test harness, or orchestration layer. The template uses square-bracket placeholders for all dynamic inputs, allowing you to inject incident reports, policy definitions, severity taxonomies, and routing rules at runtime. Before using this template, ensure you have defined your harm categories, severity levels, affected group taxonomies, and review team routing logic—the prompt assumes these exist as structured inputs.

textCopy
You are a bias incident triage classifier for a responsible AI operations team. Your task is to analyze a reported incident, classify it according to the provided taxonomy, assess severity, identify affected groups, and determine the appropriate review team and escalation path.

## INPUT
Incident Report:
[INCIDENT_REPORT]

Reporter Context:
[REPORTER_CONTEXT]

## TAXONOMY
Harm Categories:
[HARM_CATEGORIES]

Severity Levels:
[SEVERITY_LEVELS]

Affected Group Taxonomy:
[AFFECTED_GROUP_TAXONOMY]

## ROUTING RULES
Review Teams and Escalation Paths:
[ROUTING_RULES]

## CONSTRAINTS
- Do not minimize or dismiss the reporter's experience.
- Do not assume intent; classify based on described impact and observable patterns.
- If the report lacks sufficient detail for confident classification, note what information is missing rather than guessing.
- Preserve all original context from the incident report in your output summary.
- Flag any report that suggests ongoing harm or imminent risk for immediate escalation regardless of other classifications.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "incident_id": "string or null if not provided",
  "classification": {
    "primary_harm_category": "string from HARM_CATEGORIES",
    "secondary_harm_categories": ["string"],
    "severity_level": "string from SEVERITY_LEVELS",
    "affected_groups": ["string from AFFECTED_GROUP_TAXONOMY"],
    "confidence_score": 0.0-1.0
  },
  "routing": {
    "primary_review_team": "string from ROUTING_RULES",
    "escalation_path": "standard | priority | immediate",
    "requires_legal_review": true/false,
    "requires_executive_review": true/false
  },
  "summary": {
    "incident_description": "concise factual summary preserving key details",
    "reported_impact": "what harm or potential harm was described",
    "missing_information": ["list of missing details needed for full assessment"]
  },
  "remediation_tracking": {
    "existing_remediation_id": "string or null",
    "suggested_remediation_type": "string or null",
    "follow_up_required": true/false
  },
  "urgency_flags": {
    "ongoing_harm_indicated": true/false,
    "imminent_risk_indicated": true/false,
    "repeat_incident_pattern": true/false
  }
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## INSTRUCTIONS
1. Read the incident report and reporter context carefully.
2. Classify the incident using only the provided taxonomies.
3. Assign a confidence score reflecting how certain you are in the classification given available information.
4. Determine routing based on severity, affected groups, and routing rules.
5. Set urgency flags based on explicit indicators in the report.
6. Return only the JSON object. Do not include explanatory text outside the JSON.

To adapt this template for your organization, replace each square-bracket placeholder with your actual taxonomies, routing rules, and few-shot examples. The harm categories should reflect your fairness policy definitions—common categories include stereotyping, denigration, erasure, exclusion, underrepresentation, and allocative harm. Severity levels typically range from low-severity microaggressions to high-severity systemic exclusion or safety risks. Routing rules should map severity and harm category combinations to specific review teams, such as trust-and-safety, legal, product equity, or executive review. The few-shot examples are critical for calibration: include at least one example per severity level and one example with insufficient information to demonstrate appropriate confidence scoring.

When integrating this prompt into a production system, always validate the output JSON against the schema before routing. A common failure mode is the model inventing harm categories or severity levels not present in your taxonomy—add a post-processing validator that rejects outputs containing out-of-schema values and triggers a retry or human review. For high-severity classifications, require human confirmation before the routing decision executes. The remediation tracking fields assume integration with an incident management system; if you do not have one, remove those fields or replace them with a link to your manual tracking process.

This prompt is designed to be the first stage in a multi-step incident management pipeline. It should be deployed behind an API endpoint that accepts a structured incident report and returns a classification payload. The application layer is responsible for enforcing the output schema, validating severity and category values against an allowed enum, and routing the incident to the correct downstream queue. Do not expose the raw model output directly to end users or reporters; the triage result is an internal operational artifact.

Implement a strict validation layer immediately after the model response. Check that harm_category matches your internal taxonomy, severity_score is an integer within the defined range, and affected_groups is a non-empty array. If validation fails, retry the prompt once with the validation error message injected into the [CONSTRAINTS] block. After a second failure, log the raw output and route the incident to a manual triage queue. For high-severity incidents (e.g., severity >= 4), bypass normal routing and trigger an immediate alert to the on-call trust-and-safety engineer via your incident management tool (PagerDuty, Opsgenie).

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, and set temperature=0 to maximize classification consistency. If your organization requires data locality, a fine-tuned open-weight model can work but requires a larger eval suite to catch drift in category boundaries. Log every triage decision—including the raw report, the model's classification, the validator result, and the routing destination—to an append-only audit table. This log is essential for bias review, false-positive analysis, and regulatory demonstration of consistent incident handling. The next step after triage is to pass the validated output to your case management system and, for remediations, attach the remediation_tracking_id to an existing tracking record.