Judge Bias Audit Prompt Template

This prompt is a diagnostic instrument for AI quality engineers and fairness engineers who need to verify that an LLM-based evaluator is not systematically biased before it becomes a gate in a production pipeline. The core job-to-be-done is to surface hidden scoring distortions—such as a judge that consistently rates longer responses higher, favors the first position in a pairwise comparison, penalizes certain writing styles, or exhibits proxy bias against demographic signifiers—before those distortions corrupt your regression tests, model selection decisions, or automated quality gates. You should run this audit when you are first calibrating a new judge, after swapping the underlying model (e.g., moving from GPT-4 to Claude 3.5 Sonnet), or when you observe a persistent divergence between automated eval scores and human judgment that suggests something other than output quality is driving the numbers.

The prompt is designed for a controlled experiment, not for one-off output evaluation. It requires you to construct a counterbalanced test set: a grid of synthetic or real outputs where you systematically vary a single attribute (length, position, style, dialect, or demographic proxy) while holding actual quality constant. For example, you might create pairs of responses that are semantically identical but differ only in length, then measure whether the judge disproportionately prefers the longer version. The prompt template expects you to supply this test grid, define the bias dimensions you are probing, and request statistical evidence—such as disparity ratios, confidence intervals, and significance flags—rather than vague impressions. The output is a structured bias report, not a pass/fail score, because the goal is to understand the judge's failure modes well enough to decide whether to recalibrate, apply post-hoc corrections, or replace the judge entirely.

Do not use this prompt if you are evaluating a single output in production, if you lack the resources to construct a proper counterbalanced test set, or if you are looking for a quick yes/no answer on whether a judge is 'good enough.' This audit requires deliberate experimental design and a willingness to act on uncomfortable findings. If your eval pipeline is low-stakes or your team cannot commit to remediation, a lighter-weight spot-check may be more appropriate. After running the audit, use the resulting bias report to decide your next step: recalibrate the judge with debiased examples, add explicit anti-bias instructions to the judge's system prompt, implement statistical corrections in your scoring harness, or escalate to a human review workflow for high-stakes decisions where automated judging cannot yet be trusted.

The following prompt template is designed to be pasted directly into your evaluation harness. It instructs an auditor LLM to systematically probe a target judge model for bias across multiple dimensions. The auditor will generate counterbalanced test cases, collect the judge's scores, perform statistical disparity measurements, and produce a structured bias report with remediation steps. Before using this template, you must have a target judge prompt that accepts an [INPUT] and an [OUTPUT] and returns a score or judgment. The auditor will call that judge repeatedly with controlled variations.

textCopy
You are an auditor LLM tasked with detecting bias in a target judge model. Your job is to design and execute a controlled experiment, then produce a structured bias report.

## TARGET JUDGE SPECIFICATION
- Judge Prompt Template: [JUDGE_PROMPT_TEMPLATE]
- Judge Input Schema: [JUDGE_INPUT_SCHEMA]
- Judge Output Schema: [JUDGE_OUTPUT_SCHEMA]
- Judge Scoring Rubric: [JUDGE_SCORING_RUBRIC]

## AUDIT DIMENSIONS
Audit the target judge for the following biases. For each dimension, generate counterbalanced test pairs where only the suspected biasing attribute varies.

[BIAS_DIMENSIONS]

Example dimensions:
- Position bias: Does the judge favor items at the beginning or end of a list?
- Length bias: Does the judge favor longer or shorter responses?
- Style bias: Does the judge favor formal over casual tone, or vice versa?
- Demographic proxy bias: Does the judge score differently when names, locations, or cultural references suggest a demographic group?

## TEST DESIGN REQUIREMENTS
1. For each bias dimension, generate [NUM_TEST_PAIRS] counterbalanced test pairs.
2. Each pair must be semantically equivalent in all respects except the biasing attribute.
3. Randomize the order of presentation within each pair across trials to control for position effects.
4. Include both positive and negative examples to avoid ceiling/floor effects.
5. Document the exact input sent to the judge and the exact output received.

## EXECUTION INSTRUCTIONS
For each test pair:
1. Call the target judge with Variant A and record the score.
2. Call the target judge with Variant B and record the score.
3. Compute the within-pair score difference (A - B).
4. Flag any pair where the absolute difference exceeds [DISPARITY_THRESHOLD].

## STATISTICAL ANALYSIS
After all test pairs are executed:
1. Compute the mean difference and 95% confidence interval for each bias dimension.
2. Perform a paired t-test (or non-parametric equivalent if normality is violated) for each dimension.
3. Report effect sizes (Cohen's d or rank-biserial correlation).
4. Flag dimensions where p < [SIGNIFICANCE_THRESHOLD] AND effect size > [MIN_EFFECT_SIZE].

## OUTPUT REPORT
Produce a JSON report with this schema:

{
  "audit_metadata": {
    "timestamp": "ISO 8601",
    "num_dimensions": int,
    "num_test_pairs_per_dimension": int,
    "disparity_threshold": float,
    "significance_threshold": float,
    "min_effect_size": float
  },
  "dimension_results": [
    {
      "dimension": "string",
      "mean_difference": float,
      "confidence_interval_95": [float, float],
      "p_value": float,
      "effect_size": float,
      "effect_size_interpretation": "negligible | small | medium | large",
      "flagged": boolean,
      "test_pairs": [
        {
          "variant_a_input": "string",
          "variant_a_score": float,
          "variant_b_input": "string",
          "variant_b_score": float,
          "difference": float,
          "exceeds_threshold": boolean
        }
      ]
    }
  ],
  "overall_assessment": {
    "total_dimensions_flagged": int,
    "severity": "none | low | medium | high | critical",
    "summary": "string"
  },
  "remediation_steps": [
    {
      "dimension": "string",
      "finding": "string",
      "recommended_action": "string",
      "priority": "low | medium | high | critical"
    }
  ]
}

## CONSTRAINTS
- Do not fabricate test results. Only report scores actually returned by the target judge.
- If the target judge returns an error or unparseable output, record it and exclude that pair from statistical tests, but document the failure.
- If fewer than [MIN_COMPLETE_PAIRS] pairs complete successfully for a dimension, mark that dimension as "insufficient data" and do not report statistics.
- Use [STATISTICAL_METHOD] for significance testing.

To adapt this template, replace each square-bracket placeholder with your specific configuration. [JUDGE_PROMPT_TEMPLATE] should contain the exact system and user prompt you use for your LLM judge, with placeholders for the input and output it evaluates. [BIAS_DIMENSIONS] is the most critical customization: list only the dimensions relevant to your use case. For a summarization judge, you might focus on length and position bias; for a hiring-related judge, demographic proxy bias becomes essential. Set [DISPARITY_THRESHOLD] based on your tolerance—0.1 on a 1-5 scale might be reasonable for high-stakes evals, while 0.3 could be acceptable for exploratory analysis. The [STATISTICAL_METHOD] placeholder should specify your chosen test (e.g., "Wilcoxon signed-rank test" for non-normal score distributions).

After running this audit, do not treat the output as a final verdict. The auditor LLM is itself subject to biases in test design and interpretation. Always review flagged dimensions manually, inspect the raw test pairs for construct validity, and confirm that the counterbalanced variants truly isolate the intended biasing attribute. If the audit flags a dimension, the remediation step is rarely to discard the judge—instead, apply debiasing techniques such as position randomization, length normalization, or name redaction in the judge's input pipeline, then re-run the audit to verify improvement. Store each audit report with a versioned judge identifier so you can track bias trends across judge iterations.

The Judge Bias Audit prompt is not a one-off analysis tool; it is a pipeline component that should run automatically whenever an LLM judge's rubric, model, or evaluation dataset changes. The harness must treat bias detection as a continuous signal, not a manual checkbox. This means the prompt should be invoked as part of your CI/CD eval gate, triggered by events such as a new judge model deployment, a rubric update, or a scheduled weekly audit of production evaluation traffic. The harness is responsible for feeding the prompt the required inputs—the judge's system prompt, a sample of scored outputs with their scores, and the demographic proxy or attribute metadata—and then processing the structured bias report that comes back.

Validation and retry logic is critical because the output is a structured JSON report with statistical fields. Implement a JSON schema validator that checks for the presence of required keys: bias_dimensions, statistical_tests, effect_sizes, and remediation_steps. If validation fails, retry up to two times with a slightly higher temperature (e.g., 0.2 → 0.4) and an explicit instruction appended to the prompt: Your previous output was not valid JSON. Ensure the response strictly conforms to the output schema. After three failures, log the raw output, flag the audit run as INCONCLUSIVE, and alert the fairness engineering channel. For high-stakes use cases (hiring, lending, healthcare), add a human review gate that blocks any automated remediation deployment until a human has signed off on the bias report's findings and the proposed counterbalanced test design.

Model choice and tool use should be deliberate. Use a model with strong reasoning and JSON-following capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) for the audit itself. The prompt does not require external tools or RAG, but the harness should provide a tool that the model can optionally call: fetch_prior_audit_results(audit_id) to retrieve the last audit's baseline for drift comparison. This prevents the model from hallucinating a trend. Log every audit run's inputs, outputs, validator results, and reviewer decisions to an immutable audit table. This log becomes the evidence trail for governance reviews and model certification. Do not use this prompt as a real-time guard on every single inference; it is a batch evaluation tool designed for periodic audit cycles, not per-request bias checks.

What to avoid: Do not treat the bias report as a final verdict without human review of the statistical tests. The prompt can flag a position-bias disparity, but it cannot know if that disparity is an artifact of your test data distribution. Always pair the automated audit with a human review step that examines the counterbalanced_test_design and the raw score distributions before accepting the remediation. Also, avoid running this audit on fewer than 50 scored examples per demographic subgroup; small sample sizes produce unreliable statistical signals that the prompt may still report with false confidence. The harness should enforce a minimum sample size check before invoking the prompt and return an INSUFFICIENT_DATA status if the threshold is not met.