Bias Mitigation Rule Portability Prompt

This prompt is for responsible AI teams, trust and safety engineers, and platform architects who need to ensure that bias mitigation instructions written for one model family survive translation to another. The core job-to-be-done is structural adaptation: taking a set of fairness rules, sensitive attribute handling procedures, representational harm checks, and output flagging criteria, and rewriting them so they produce equivalent behavioral outcomes on a target model with different instruction-following patterns, safety defaults, and parsing behavior. This is not a prompt for writing new bias policies from scratch. It assumes you already have a tested, approved bias mitigation specification and need to port it without silently dropping protections or introducing over-refusal that breaks the product.

Use this prompt when you are actively migrating between model providers, deploying the same AI product across multiple model backends, or upgrading to a new model version where behavioral drift in fairness-sensitive outputs is a known risk. The ideal user has access to the original bias mitigation policy, a set of golden test cases that demonstrate expected behavior, and a target model's system prompt conventions. Do not use this prompt for initial bias policy authoring, for single-model deployments where no portability is required, or for workflows where fairness requirements are undefined. The prompt requires explicit input of the source policy, target model family, and a risk level that determines the intensity of mitigation language. Without these inputs, the adaptation will be generic and untestable.

The output is a structured bias mitigation rule set that includes adapted detection criteria, sensitive attribute handling instructions, representational harm checks, and output flagging rules. It also produces a fairness consistency evaluation framework so you can test whether the ported rules hold. Before shipping, you must run the fairness consistency evals against your golden test cases, validate that protected attribute handling does not introduce new blind spots, and conduct a human review of flagged outputs to confirm that the adaptation did not introduce over-refusal or under-detection. The next step after generating the adapted rules is to integrate them into your target system prompt, run the provided eval suite, and document any behavioral differences that require product-level mitigations beyond the prompt layer.

This prompt template is the core instruction set you will send to a target model. It asks the model to act as a bias mitigation policy translator, taking a set of fairness rules written for one model family and adapting them into structurally equivalent instructions for a different target model. The template uses square-bracket placeholders for all variable components so you can swap in your source policy, target model details, and evaluation criteria without rewriting the instruction logic.

textCopy
You are a bias mitigation policy translator. Your task is to adapt a set of fairness and bias mitigation rules written for one model family into structurally equivalent instructions for a different target model. The adapted rules must preserve the original policy intent while respecting the target model's instruction format, sensitivity patterns, and behavioral conventions.

## SOURCE POLICY
[SOURCE_POLICY]

## TARGET MODEL
Model family: [TARGET_MODEL_FAMILY]
Instruction format conventions: [TARGET_MODEL_CONVENTIONS]
Known sensitivity patterns: [TARGET_MODEL_SENSITIVITY]

## ADAPTATION REQUIREMENTS
1. Preserve the original policy's intent for each rule. Do not weaken or strengthen the rule unless the target model's behavior requires calibration.
2. Map sensitive attribute handling rules to the target model's native instruction format. If the target model does not support explicit attribute lists, use behavioral descriptions instead.
3. Adapt representational harm checks to the target model's output patterns. Include concrete examples of harmful outputs the model should avoid.
4. Translate output flagging criteria into the target model's preferred conditional logic. Use the model's native constructs for thresholds, severity levels, and response templates.
5. Add calibration notes where the target model is known to over- or under-enforce certain categories.

## OUTPUT FORMAT
Return a JSON object with this schema:
{
  "adapted_policy": "The complete adapted bias mitigation instruction block",
  "rule_mappings": [
    {
      "source_rule_id": "Identifier from source policy",
      "target_rule_text": "Adapted rule text",
      "adaptation_notes": "Explanation of changes made and why",
      "risk_of_drift": "low|medium|high",
      "drift_mitigation": "How to detect and correct drift for this rule"
    }
  ],
  "calibration_warnings": [
    "Specific warnings about categories where the target model may deviate"
  ],
  "testing_priorities": [
    "Ordered list of rules that need the most rigorous cross-model testing"
  ]
}

## CONSTRAINTS
- Do not invent new bias categories not present in the source policy.
- Do not remove rules unless the target model fundamentally cannot enforce them, and explain why.
- Flag any source rule that relies on model-specific features with no direct equivalent in the target model.
- If the target model has known refusal patterns that could interfere with bias mitigation, note them in calibration_warnings.

To adapt this template, replace each square-bracket placeholder with concrete values. [SOURCE_POLICY] should contain the complete bias mitigation instruction block from your source model. [TARGET_MODEL_FAMILY] identifies the destination model. [TARGET_MODEL_CONVENTIONS] should describe how that model expects instructions to be structured—for example, whether it uses XML tags, markdown headers, or plain text directives. [TARGET_MODEL_SENSITIVITY] should capture known behavioral tendencies, such as over-refusal on demographic terms or under-sensitivity to representational harms. After running the prompt, validate the output against your fairness consistency evals before deploying the adapted policy to production.

This prompt is not a one-off fairness check. It is a policy translation engine designed to sit inside a continuous evaluation harness that runs whenever a model, system prompt, or bias mitigation rule changes. The harness should treat the prompt output as a structured artifact—a portable rule specification—that downstream validators and test suites consume. Do not paste the output directly into a production system prompt without validation. Instead, store the generated rules in a versioned policy registry, run fairness consistency evals against them, and only promote rules that pass equivalence thresholds across all target models.

The implementation loop follows a clear sequence: (1) Load the source bias mitigation rule and the target model identifier into the prompt template. (2) Call the model with response_format set to the JSON schema defined in the output contract, using a low temperature (0.0–0.2) to maximize structural reliability. (3) Validate the output against the schema immediately—reject any response missing required fields like sensitive_attribute_handling, representational_harm_checks, or output_flagging_criteria. (4) Run the generated rule through a cross-model fairness test harness that sends identical protected-class inputs to both the source and target models and measures disparity in refusal rates, stereotype reproduction, and tone degradation. (5) Log the rule version, model pair, validation results, and fairness metrics to an audit store. If disparity exceeds a predefined threshold (e.g., a 5% difference in false-negative stereotype rate), block promotion and flag for human review.

Model choice matters here. Use a model with strong instruction-following and structured output reliability for the translation step—GPT-4o, Claude 3.5 Sonnet, or equivalent. The fairness evaluation step should run against the actual target models you intend to deploy, not against the translation model. For high-stakes domains like hiring, lending, or healthcare, insert a mandatory human review gate before any translated rule reaches production. The harness should also support rollback: if a translated rule passes initial validation but later fails a production fairness audit, revert to the last known-good rule version and trigger an incident review. Avoid the temptation to auto-apply translated rules without evidence of behavioral equivalence.