Inclusive Language Rewriting Prompt Template

This prompt is designed for content and UX teams who need to repair AI-generated or human-authored text that contains stereotyping, erasure, othering, or non-inclusive language patterns. It is not a general-purpose style guide or a toxicity classifier. Use it when you have a specific text string that needs rewriting to preserve its original intent while removing representational harms. The prompt produces a structured before/after pair with a detailed change explanation, making it auditable and suitable for embedding into content review pipelines, CI/CD checks for copy, or human-in-the-loop moderation queues. It assumes the input text has already been flagged by a detection audit or human reviewer and is now ready for repair.

The ideal user is a content operator, UX writer, or responsible AI reviewer who needs a consistent, explainable rewrite rather than a black-box transformation. The prompt requires the original flagged text, the specific harm category identified (e.g., stereotyping, erasure, othering), and any domain-specific terminology constraints. It works best when the harm is representational rather than factual—this prompt repairs how something is said, not whether it is true. For factual errors, use a fact-checking or grounding prompt instead. The output includes the rewritten text, a structured change log, and a confidence indicator, which lets downstream systems decide whether to auto-apply the fix or queue it for human approval.

Do not use this prompt as a first-pass detection tool. It is a repair tool, not an auditor. If you need to find biased language in a large corpus, pair it with a stereotype detection audit prompt or a representational harm taxonomy classifier first, then route flagged items here for rewriting. Also avoid using this prompt for legal compliance rewrites, medical disclaimers, or regulated financial language—those domains require domain-specific review workflows with human sign-off. The prompt is designed for content surfaces like product copy, help text, marketing language, onboarding flows, and internal communications where inclusive language is a product quality goal rather than a regulatory requirement.

The following prompt template is designed to be pasted directly into your prompt layer—whether that's a system prompt, a user message template, or a prompt management platform. It accepts biased or potentially exclusionary text and produces a structured rewrite that preserves the original intent while removing harmful language patterns. The template uses square-bracket placeholders for all variables, making it safe to store in configuration files, databases, or code repositories without accidental token interpolation.

textCopy
You are an inclusive language editor. Your task is to rewrite the provided text to remove stereotyping, erasure, othering, overgeneralization, and dehumanizing language while preserving the original intent, tone, and factual content.

## INPUT
[INPUT]

## CONTEXT
- Domain: [CONTEXT]
- Target audience: [AUDIENCE]
- Locale and language variety considerations: [LOCALE]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "original_text": "string (the exact input text)",
  "rewritten_text": "string (the inclusive rewrite)",
  "changes": [
    {
      "original_phrase": "string (the problematic phrase from the original)",
      "rewritten_phrase": "string (the replacement phrase)",
      "harm_category": "string (one of: stereotyping, erasure, othering, overgeneralization, dehumanization, tokenism, western_centric_framing, tone_policing, competence_attribution, none)",
      "rationale": "string (brief explanation of why the change was made)"
    }
  ],
  "preserved_elements": ["string (list of key elements intentionally kept unchanged)"],
  "confidence": "number (0.0 to 1.0 indicating confidence in the rewrite quality)",
  "flagged_for_human_review": "boolean (true if the rewrite requires human review before use)"
}

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Identify any language that stereotypes, erases, others, overgeneralizes, or dehumanizes people based on identity dimensions including race, gender, sexual orientation, disability, age, religion, socioeconomic status, or cultural background.
2. Rewrite the text to remove these patterns while preserving the original meaning, factual claims, and communicative purpose.
3. For each change, classify the harm category and provide a clear rationale.
4. If the original text contains no harmful patterns, return an empty changes array and set confidence to 1.0.
5. If you are uncertain about a potential harm, flag the output for human review rather than making an incorrect change.
6. Do not introduce new factual claims or alter the substantive content beyond language changes.
7. Preserve the original tone and formality level unless the tone itself is the source of harm.

## RISK LEVEL
[RISK_LEVEL]

To adapt this template for your environment, replace each placeholder with concrete values. For [INPUT], provide the text to be rewritten. For [CONTEXT], describe the domain (e.g., "job description for software engineering roles") and any relevant organizational style guides. For [AUDIENCE], specify who will read the output. For [LOCALE], indicate regional language expectations. For [CONSTRAINTS], add any domain-specific rules such as "do not change technical terminology" or "preserve legal disclaimers verbatim." For [EXAMPLES], provide 2-4 few-shot demonstrations showing the expected transformation pattern. For [RISK_LEVEL], set to "low" for internal drafts, "medium" for customer-facing content requiring spot-checking, or "high" for regulated communications requiring mandatory human review. The output schema is designed to be parseable by downstream validation logic—check that flagged_for_human_review is respected in your pipeline and that harm_category values match your internal taxonomy before routing outputs to production surfaces.

The inclusive language rewriting prompt is rarely a one-shot call. In production, it sits inside a content review pipeline that ingests source text, applies the rewrite, validates the output, and routes edge cases to human reviewers. The harness must handle three core concerns: preserving the original intent while changing biased language, producing a machine-readable change explanation, and preventing the model from introducing new harms during the rewrite. Wire this prompt as a gated transformation step—never as an unsupervised publish action—because rewriting can silently alter meaning, tone, or factual claims in ways that downstream editors must verify.

Build the harness with a pre-check, rewrite, validate, escalate loop. Before calling the LLM, run a lightweight classifier or keyword scan to detect whether the input contains potentially biased language; if the input is already clean, skip the rewrite to save cost and latency. After the model returns, validate the output against a strict schema: the rewritten text must not be empty, must differ from the original when bias was detected, and must preserve key entities, numbers, and quoted material. Run a second LLM judge pass using the Bias Audit Report Generation Prompt Template or a lightweight pass/fail fairness gate to catch introduced harms. Log every rewrite pair—original, rewritten, change explanation, and validation results—for audit trails and model drift monitoring. For high-stakes content (public-facing product copy, legal disclaimers, healthcare information), always route outputs to a human review queue with the before/after pair and the model's change explanation displayed side by side.

Model choice matters here. Smaller models often over-correct, stripping voice and introducing stilted language, while larger models may over-explain or refuse to rewrite ambiguous cases. Start with a mid-tier model (GPT-4o, Claude 3.5 Sonnet) and calibrate against human-reviewed examples. Set temperature low (0.0–0.2) for consistency, and implement a retry with temperature bumped to 0.4 if the first attempt produces an empty or identical rewrite. If the model refuses to rewrite, capture the refusal reason and escalate—never silently pass the original text through. For high-throughput pipelines, batch inputs but validate each output individually; a single malformed rewrite in a batch can corrupt downstream publishing workflows. Avoid wiring this prompt directly into user-facing chat without a confirmation step; users should see the suggested rewrite and approve it before it replaces their text.