Bias Drift Eval Failure Investigation Prompt

This prompt is designed for responsible AI engineers and data scientists who have detected a statistically significant regression in a fairness or bias metric within their production eval harness. The job-to-be-done is not to define fairness, but to perform a structured differential diagnosis. The prompt takes two labeled datasets—a baseline period and a current period where the eval began failing—and forces a trace-level comparison to identify which input patterns, sensitive attribute co-occurrences, or model behaviors shifted. It is built for teams that already have bias evals running in CI/CD or production monitoring and need to close the loop from 'a metric dropped' to 'this specific input cluster is now producing biased outputs because of a retrievable root cause.'

The ideal user has access to structured eval logs that link individual predictions to their input features, sensitive attribute metadata, and model outputs. You should not use this prompt if you lack a labeled baseline for comparison, if the bias metric is undefined or purely anecdotal, or if you are trying to define a fairness policy from scratch. This prompt assumes the eval rubric is stable and the regression is measurable. It is not a substitute for a bias audit framework, nor does it replace legal review. The output is a technical diagnostic report, not a compliance certification. If the investigation involves regulated decisions (e.g., lending, hiring, healthcare), the findings must be reviewed by a human domain expert before any product or policy change.

Before using this prompt, ensure you have prepared two structured datasets with consistent schemas, a clear definition of the sensitive attribute(s) under review, and the specific eval metric that regressed. The prompt works best when you can provide trace-level context—such as retrieval snippets, tool-call logs, or model reasoning—alongside the input-output pairs. If you only have aggregate metric dashboards without row-level trace data, this prompt will not be effective. Start by isolating the failing eval dimension, then feed the prompt the relevant slices. The output will guide your next engineering action, whether that is a prompt update, a retrieval pipeline fix, or a routing logic change.

This template is designed to be copied directly into your investigation workflow. It forces a structured, differential analysis by comparing a set of production traces from a baseline period against a current period where a fairness eval metric has regressed. The prompt instructs the model to act as a responsible AI auditor, identifying shifts in input patterns, model behavior, and trace-level causes without speculating beyond the provided evidence. All placeholders are in square brackets and must be replaced with data from your observability platform before execution.

textCopy
You are a responsible AI auditor investigating a regression in a fairness evaluation metric. Your task is to perform a differential analysis comparing bias-sensitive model outputs from two time periods to identify the root cause of the drift.

## INPUT DATA

### BASELINE PERIOD (Before Regression)
- Date Range: [BASELINE_START_DATE] to [BASELINE_END_DATE]
- Eval Metric Value: [BASELINE_EVAL_SCORE]
- Sample Traces: [BASELINE_TRACE_LIST]

### CURRENT PERIOD (Regression Detected)
- Date Range: [CURRENT_START_DATE] to [CURRENT_END_DATE]
- Eval Metric Value: [CURRENT_EVAL_SCORE]
- Sample Traces: [CURRENT_TRACE_LIST]

### FAIRNESS DIMENSION UNDER REVIEW
- Protected Attribute or Sensitive Context: [FAIRNESS_DIMENSION]
- Eval Rubric Definition: [EVAL_RUBRIC_DESCRIPTION]

## ANALYSIS CONSTRAINTS
- Base all findings strictly on the provided trace data. Do not invent or assume external factors.
- For each finding, cite the specific trace ID and step where the evidence was observed.
- Distinguish between correlation and causation. Use language like "is associated with" or "co-occurs with" when causation is not clear from the trace.
- If the provided data is insufficient to reach a conclusion, state what additional data is needed.

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "investigation_summary": "A 2-3 sentence summary of the most likely root cause.",
  "metric_drift": {
    "baseline_value": [BASELINE_EVAL_SCORE],
    "current_value": [CURRENT_EVAL_SCORE],
    "absolute_change": "Calculated numeric change.",
    "severity": "LOW | MEDIUM | HIGH | CRITICAL"
  },
  "shifted_input_patterns": [
    {
      "pattern_description": "Description of the shifted input pattern.",
      "baseline_frequency": "Observed frequency in baseline traces.",
      "current_frequency": "Observed frequency in current traces.",
      "trace_evidence": ["TRACE_ID_1", "TRACE_ID_2"],
      "impact_on_fairness": "Explanation of how this shift impacts the fairness metric."
    }
  ],
  "shifted_model_behaviors": [
    {
      "behavior_description": "Description of the changed model behavior.",
      "baseline_behavior": "How the model behaved in the baseline period.",
      "current_behavior": "How the model behaves in the current period.",
      "trace_evidence": ["TRACE_ID_3", "TRACE_ID_4"],
      "likely_cause": "HYPOTHESIS: A trace-level hypothesis for the behavior change."
    }
  ],
  "root_cause_hypothesis": {
    "primary_hypothesis": "The most likely root cause based on trace evidence.",
    "confidence": "HIGH | MEDIUM | LOW",
    "supporting_evidence": ["TRACE_ID_5"],
    "alternative_hypotheses": ["Another possible cause with less supporting evidence."],
    "recommended_remediation": "A concrete, actionable step to address the root cause."
  },
  "data_sufficiency": {
    "is_sufficient": true or false,
    "missing_data_requests": ["List of additional data needed if insufficient."]
  }
}

To adapt this template, replace the trace list placeholders with structured trace summaries from your observability tool. Each trace summary should include the user input, the final model output, and key intermediate steps like retrieval results or tool calls. For high-stakes fairness investigations, the output of this prompt should be reviewed by a human before any remediation is applied. Consider running this analysis with multiple LLM judges to calibrate confidence scores and reduce single-model bias in the diagnosis itself.

This prompt is designed to operate as a diagnostic step within an automated eval failure triage pipeline, not as a standalone chat interaction. When a fairness-related eval metric (e.g., demographic parity difference, equalized odds ratio, or a custom bias rubric score) breaches a predefined threshold, the system should trigger this investigation workflow. The harness must assemble the required inputs—current-period eval results, baseline-period eval results, a sample of production traces from both periods, and the fairness rubric definition—before invoking the model. Because the output includes a root-cause classification and a recommended action, the harness must treat this as a decision-support artifact that requires human review before any prompt rollback, model routing change, or training data modification is executed.

Input assembly is the most critical pre-invocation step. The harness must query your observability store (e.g., LangSmith, Arize, Weights & Biases, or a custom trace database) to retrieve: (1) the aggregated fairness metric values for the current and baseline time windows, including sample sizes and confidence intervals; (2) a stratified sample of 20–50 production traces from each period, ensuring representation across the sensitive attribute categories under review; (3) the exact eval rubric or fairness definition used by the scoring system; and (4) any relevant prompt version identifiers, model version metadata, and retrieval configuration snapshots from both periods. These inputs populate the [CURRENT_EVAL_RESULTS], [BASELINE_EVAL_RESULTS], [TRACE_SAMPLES], [FAIRNESS_RUBRIC], and [SYSTEM_METADATA] placeholders. Model choice matters: use a model with strong reasoning capabilities (e.g., Claude 3.5 Sonnet, GPT-4o) because the task requires multi-step differential analysis across structured data and unstructured trace logs. Do not use a lightweight model for this workflow—false negatives in root-cause classification can delay remediation of real fairness regressions.

Validation and retry logic must be layered. After the model returns its analysis, the harness should validate the output structure against the expected schema: a root_cause_category field matching one of the predefined enum values, a confidence_score between 0 and 1, a non-empty evidence_summary array with trace-level citations, and a recommended_action field. If validation fails, retry once with the same inputs and an explicit instruction to conform to the output schema. If the second attempt also fails, escalate to a human reviewer with the raw model output and validation errors attached. Logging is essential for auditability: store the full prompt, model response, validation result, and reviewer decision in your observability platform, tagged with the eval failure incident ID. This creates an evidence trail for governance reviews and enables trend analysis across multiple bias drift incidents over time.

Human review is mandatory before acting on the model's recommendation. The harness should route the validated output to a review queue (e.g., a Jira ticket, a Slack notification with a structured summary, or a dedicated review dashboard). The reviewer must confirm or override the root-cause classification and approve, modify, or reject the recommended action. Automated remediation—such as rolling back a prompt version or blocking a model update—should never be triggered solely by this prompt's output. The review step is especially important because bias drift can originate from subtle input distribution shifts that the model may misattribute, and incorrect remediation can inadvertently mask real fairness issues. After human sign-off, the harness should update the incident status, log the reviewer's decision, and trigger any approved downstream workflows (e.g., prompt rollback, retrieval index refresh, or training data audit).

What to avoid: Do not run this prompt on every eval failure indiscriminately. Reserve it for cases where the fairness metric change exceeds a meaningful threshold (e.g., a 5-percentage-point shift in demographic parity or a statistically significant drop in equalized odds). Running it on noise will generate false positives that erode trust in the workflow. Do not skip the trace sampling step—aggregate metrics alone are insufficient for root-cause analysis. And do not treat the model's confidence_score as a probability in the statistical sense; it is a heuristic signal that should be calibrated against human reviewer agreement over time. If your team observes systematic overconfidence or underconfidence, adjust the prompt's instructions or add calibration examples to the [EXAMPLES] placeholder.