Judge Instruction Rewriting Prompt After Misalignment Detection

This prompt is a surgical repair tool for evaluation engineers and MLOps teams who have already detected that an LLM judge is scoring outputs differently from human raters. It is not a starting point for designing a new judge, nor is it a general-purpose prompt improvement tool. You should reach for this prompt only when you have specific, diagnosed misalignment evidence in hand: a set of test cases where the judge's score diverged from the human reference score, a clear articulation of the misalignment pattern (e.g., 'judge overpenalizes short responses on the completeness dimension'), and the current judge instructions that produced the bad scores. Without these three inputs, the prompt cannot produce a targeted fix and risks introducing new failure modes.

The ideal user is an evaluation pipeline owner who has already run a calibration exercise, identified systematic scoring gaps, and needs to rewrite judge instructions without breaking correct behavior on cases the judge already handles well. For example, if your judge consistently scores factual answers as 4/5 when human raters give 5/5 because the judge misinterprets cautious language as uncertainty, this prompt will produce revised instructions that clarify the distinction between appropriate hedging and actual uncertainty. It will also generate a before/after comparison table and a regression risk assessment so you can review the proposed changes before deploying them. Do not use this prompt when you lack specific misalignment examples, when the judge has never been calibrated against human ratings, or when you are building a judge from scratch—those scenarios require the calibration set construction and initial judge design prompts elsewhere in this pillar.

Before running this prompt, assemble your evidence package: the misaligned test cases with both judge scores and human reference scores, a written diagnosis of the pattern you believe is causing the gap, and the exact judge instructions currently in production. The prompt will produce revised instructions that target only the diagnosed pattern while preserving the judge's existing behavior on aligned cases. After receiving the output, review the regression risk assessment carefully—any instruction change can shift scores on previously stable cases. Run the revised instructions against your full calibration set and compare score distributions before promoting to production. If the misalignment pattern is severe or spans multiple dimensions, consider running the root cause analysis prompt first to ensure you are treating the cause, not a symptom.

This prompt template is designed to be pasted directly into your LLM interface. It takes the original judge instructions, a set of test cases where the judge's scoring drifted from human ratings, and a description of the misalignment pattern, and produces revised instructions that target the specific failure modes. The output includes a before-and-after comparison, a regression risk assessment, and the test cases that previously triggered the misalignment so you can immediately validate the fix.

codeCopy
You are an evaluation engineer fixing an LLM judge that has drifted from human scoring standards.

## ORIGINAL JUDGE INSTRUCTIONS
[ORIGINAL_INSTRUCTIONS]

## MISALIGNMENT DATA
[MISALIGNMENT_DESCRIPTION]

## FAILING TEST CASES
These are examples where the judge's scores diverged from human raters. Each case includes the input, the judge's score and reasoning, and the human reference score and reasoning.

[TEST_CASES]

## CONSTRAINTS
- Preserve the original evaluation dimensions and scoring scale unless the misalignment requires structural changes.
- Do not overfit to the failing test cases; the revised instructions must generalize.
- Add explicit guidance that addresses the root cause of the misalignment pattern.
- If the misalignment stems from rubric ambiguity, add clarifying examples and boundary definitions.
- If the misalignment stems from judge severity or leniency, add calibration anchors.

## OUTPUT SCHEMA
Return a JSON object with these fields:
{
  "revised_instructions": "The complete revised judge prompt, ready to deploy.",
  "changes_summary": [
    {
      "change": "Description of what was changed.",
      "rationale": "Why this change addresses the misalignment.",
      "affected_test_cases": ["test_case_id_1", "test_case_id_2"]
    }
  ],
  "regression_risk_assessment": {
    "risk_level": "low | medium | high",
    "risk_description": "What could break with the new instructions.",
    "mitigation_steps": ["Step 1", "Step 2"]
  },
  "validation_plan": {
    "immediate_checks": ["Check 1", "Check 2"],
    "backtest_on_failing_cases": true,
    "backtest_on_held_out_cases": true,
    "recommended_sample_size": 100
  }
}

## INSTRUCTIONS
1. Analyze the misalignment pattern across the failing test cases.
2. Identify the root cause: rubric ambiguity, severity drift, context misinterpretation, or other.
3. Rewrite the judge instructions to correct the root cause while preserving the original evaluation intent.
4. Produce the output in the exact JSON schema specified.

To adapt this template, replace [ORIGINAL_INSTRUCTIONS] with the full text of the judge prompt that is producing misaligned scores. For [MISALIGNMENT_DESCRIPTION], provide a clear summary of the drift pattern—for example, "Judge is scoring factual accuracy 0.5–1.0 points lower than human raters on technical answers longer than 500 words." The [TEST_CASES] placeholder should contain a structured list of at least 5–10 examples, each with a unique ID, the input that was scored, the judge's score and reasoning, and the human reference score and reasoning. More test cases produce better root cause analysis.

Before deploying the revised instructions, run the validation plan produced by this prompt. Backtest on the failing cases to confirm the fix, then backtest on a held-out set of previously passing cases to check for regressions. If the regression risk is medium or high, run a larger backtest before shipping. For high-risk evaluation pipelines where judge scores gate production deployments, always require human review of the revised instructions and the backtest results before cutting over.

This prompt is not a one-shot fix. It is a repair step inside a larger calibration pipeline. The typical trigger is a drift alert from your monitoring system: an LLM judge's scores have diverged from a human-annotated gold set or from peer judges beyond an acceptable threshold. The misalignment detection step produces a structured report identifying specific scoring dimensions, example clusters, and failure patterns. That report becomes the primary input to this rewriting prompt. The output is a revised judge instruction set that must pass regression tests, human review, and a staged rollout before replacing the production judge. Do not auto-apply rewritten instructions without gates.

Build the harness as a versioned artifact pipeline. Store each judge instruction set with a semantic version (e.g., judge-v2.3.1), the calibration window it was trained against, and the misalignment report that triggered the rewrite. The rewriting step should produce a diff against the previous version, not just a new prompt. Run the candidate instructions through a regression suite containing: (a) the original calibration set to verify baseline performance is preserved, (b) the specific test cases that triggered the misalignment to confirm improvement, and (c) a held-out adversarial set probing known failure modes. Log per-dimension scores, agreement coefficients, and confidence intervals. If any dimension regresses by more than a configured tolerance (e.g., 0.05 drop in Cohen's kappa), block promotion and flag for human review.

Validation must include both automated checks and human sign-off. Automated checks: schema conformance (the output must contain a complete judge prompt with scoring rubric, examples, and edge-case guidance), keyword safety (no accidental instruction leakage like 'ignore previous instructions'), and format stability (the prompt structure must match the expected template so downstream parsing doesn't break). Human review: an evaluation engineer must inspect the diff, verify that the rewritten instructions address the reported misalignment without introducing new biases, and approve the change. For high-stakes domains like healthcare or legal evaluation, require a second reviewer and document the approval in an audit log. Never deploy a rewritten judge without a rollback plan—keep the previous version hot and monitor score distributions for 48 hours post-deployment.

Model choice matters for this workflow. The rewriting prompt benefits from strong instruction-following and reasoning capabilities. Use a frontier model (e.g., GPT-4, Claude 3.5 Sonnet) for the rewrite step itself, even if your production judge runs on a smaller model. The rewrite requires understanding nuanced scoring failures and producing precise, unambiguous instructions. Run the candidate instructions through your actual production judge model during regression testing—a prompt that works perfectly on a frontier model may produce different behavior on the lighter model you deploy. If the production judge model cannot reliably execute the rewritten instructions, you may need to simplify the rubric or accept a performance ceiling.

Wire observability into every step. Log the misalignment report, the candidate rewritten prompt, regression test results, human review decisions, and deployment timestamps. This audit trail is essential for debugging future drift events and demonstrating evaluation governance to compliance teams. Set up automated alerts if a newly deployed judge's score distribution shifts significantly from the baseline (e.g., mean score change > 0.3 on a 1-5 scale, or pass rate change > 10%). These alerts catch deployment issues that regression tests missed. Finally, schedule periodic recalibration—even a well-aligned judge drifts as your product, user behavior, and content distribution evolve. Run the full detect-rewrite-validate-deploy cycle on a regular cadence (monthly for stable domains, weekly for fast-moving products) rather than waiting for a crisis.