Domain-Specific Rubric Adaptation Prompt Template

Use this prompt when you have a working general-purpose evaluation rubric that must be adapted for a high-stakes domain like legal, medical, or financial contexts. The primary job is to produce a domain-adapted rubric that maps general quality dimensions to domain-specific terminology, injects regulatory or professional constraints, and defines failure modes unique to that domain. The ideal user is an evaluation lead or AI engineer who already has a functional rubric and needs to make it safe and precise for a specialized audience without starting from scratch.

This prompt is not a starting point for building a rubric from zero. If you do not have a base rubric with defined dimensions and scoring levels, start with the LLM Judge Rubric Design Prompt Template first. Do not use this prompt for low-risk domains where general terminology is sufficient, or when the domain expert who will review the output is unavailable. The adapted rubric requires alignment with a human domain expert before it goes into production; the prompt produces a draft for expert review, not a final artifact. It is also unsuitable for real-time scoring pipelines where latency constraints prevent the additional reasoning steps required for domain-specific checks.

Before running this prompt, gather three inputs: a complete base rubric with dimensions, levels, and anchors; a domain context document specifying terminology, constraints, and regulatory requirements; and at least three examples of domain-specific outputs that illustrate common failure modes. The prompt will produce a rubric with terminology mappings, injected constraints, and new failure-mode descriptions. After generation, schedule a review session with a domain expert to validate the mappings and failure modes. Do not deploy the adapted rubric until that alignment check is complete and you have run a calibration pass against at least 20 human-judged examples from the target domain.

The following prompt template is designed to take a general-purpose evaluation rubric and adapt it for a specific high-stakes domain such as legal, medical, or financial contexts. It instructs the model to map generic quality dimensions to domain-specific terminology, inject relevant regulatory or professional constraints, and identify failure modes that a general rubric would miss. Use this template when you have a working rubric that needs to be hardened for a specialized production environment, not when you are designing a rubric from scratch.

textCopy
You are an expert in [DOMAIN] quality assurance and evaluation design. Your task is to adapt a general evaluation rubric so it is fit for use in [DOMAIN] contexts.

## INPUT

### General Rubric
[RUBRIC_TEXT_OR_JSON]

### Domain Context
- Domain: [DOMAIN]
- Regulatory or professional standards to consider: [STANDARDS]
- Typical output types being evaluated: [OUTPUT_TYPES]
- Risk level of incorrect evaluation: [RISK_LEVEL]

## TASK

1. **Terminology Mapping**: For each dimension and level in the general rubric, map the language to [DOMAIN]-appropriate terminology. Replace generic terms with domain-specific equivalents.
2. **Constraint Injection**: Add evaluation criteria that reflect [STANDARDS] and domain-specific requirements. Flag where the original rubric is silent on a critical domain concern.
3. **Failure Mode Expansion**: Identify at least [N] failure modes specific to [DOMAIN] that the general rubric would miss. For each, describe the failure, its severity, and how the adapted rubric should catch it.
4. **Scoring Calibration Notes**: Note any adjustments needed to the scoring scale so that scores remain calibrated against domain expectations. Flag where a "good" score in the general rubric might be unacceptable in [DOMAIN].

## OUTPUT SCHEMA

Return a JSON object with the following structure:
{
  "domain": "string",
  "adapted_rubric": {
    "dimensions": [
      {
        "original_name": "string",
        "adapted_name": "string",
        "levels": [
          {
            "score": number,
            "original_description": "string",
            "adapted_description": "string",
            "domain_anchors": ["string"]
          }
        ],
        "domain_constraints_added": ["string"]
      }
    ],
    "new_dimensions": [
      {
        "name": "string",
        "rationale": "string",
        "levels": [
          {
            "score": number,
            "description": "string",
            "domain_anchors": ["string"]
          }
        ]
      }
    ]
  },
  "domain_failure_modes": [
    {
      "name": "string",
      "description": "string",
      "severity": "critical|high|medium|low",
      "detection_in_adapted_rubric": "string",
      "missed_by_general_rubric": true
    }
  ],
  "calibration_notes": {
    "score_adjustments": "string",
    "threshold_changes": "string",
    "requires_domain_expert_review": true
  },
  "alignment_check_questions": ["string"]
}

## CONSTRAINTS
- Do not remove dimensions from the original rubric unless they are actively harmful in [DOMAIN]. If removal is necessary, explain why in calibration_notes.
- Every adapted level description must include at least one domain-specific anchor example.
- Failure modes must be concrete and observable, not hypothetical.
- If [RISK_LEVEL] is high or critical, flag which adapted rubric dimensions require mandatory human review before scores are accepted.
- Preserve the original scoring scale range. If rescaling is needed, document the mapping explicitly.

To adapt this template for your workflow, start by populating the domain-specific placeholders. The [STANDARDS] field should reference actual regulatory frameworks, professional guidelines, or internal policies—not vague aspirations. For high-risk domains, set [RISK_LEVEL] to "high" or "critical" to trigger the mandatory human-review flagging behavior. The [N] failure modes count should be proportional to the rubric's complexity; start with 3-5 for a simple rubric and increase for multi-dimensional evaluation systems. After running the prompt, treat the alignment_check_questions output as a checklist for a domain expert review session—do not deploy the adapted rubric until those questions are resolved.

This prompt is not a one-shot generator—it is a structured adaptation engine that should be embedded in a workflow with human domain experts in the loop. The output is a draft rubric that requires validation before it becomes the scoring contract for your LLM judge. Wire this prompt into your rubric management system as a draft generation step, not a final publish step. The harness must enforce that no adapted rubric enters production without explicit human sign-off, because domain-specific terminology mapping errors and missing constraint injection are the most common failure modes.

Integration pattern: Call the prompt with the base rubric, domain context, and terminology glossary as inputs. Parse the output into a structured rubric object with dimensions, levels, anchors, and domain-specific failure modes. Run automated validation checks: (1) all dimensions from the base rubric are present or explicitly deprecated with rationale, (2) every scoring level has at least one domain-specific anchor example, (3) terminology mappings reference the provided glossary, and (4) domain-specific failure modes are concrete and testable. Flag any rubric that fails these checks for human review before proceeding. Model choice: Use a model with strong instruction-following and structured output capabilities. For high-stakes domains like legal or medical, prefer models that support strict JSON mode and low-temperature decoding to reduce creative drift in rubric language.

Expert review queue: Route the validated draft rubric to a domain expert review interface. The review UI should display side-by-side: the original base rubric, the adapted rubric, and a diff highlighting terminology changes, new constraints, and added failure modes. Experts should approve, reject, or modify each dimension independently. Track approval status per dimension and require 100% approval before the rubric is activated. Versioning: Store adapted rubrics with explicit version links to the base rubric version and domain context version they were generated from. When the base rubric or domain glossary changes, trigger a re-adaptation and re-review cycle. Logging: Log the prompt version, model version, input hashes, and reviewer identity for every adapted rubric. This audit trail is essential for regulated domains where rubric provenance must be demonstrable.

Retry and repair: If validation checks fail, do not blindly retry the same prompt. Instead, construct a targeted repair prompt that includes the specific validation failures and asks the model to fix only those issues while preserving the rest of the rubric. Limit repair attempts to two iterations before escalating to a human rubric designer. Testing before production: Before using the adapted rubric for live evaluation, run it against a golden set of 20-50 domain-specific examples with known human scores. Compare LLM judge scores using the adapted rubric against human reference scores. If inter-rater reliability drops below your threshold compared to the base rubric's performance on general examples, flag the adaptation for expert re-review. This calibration step catches terminology mismatches that validation checks alone will miss.