Pairwise Comparison Prompt for Tone and Style

This prompt is designed for content and UX teams who need a consistent, structured method for comparing two AI-generated text outputs and determining which one better aligns with a specific brand voice, tone of voice, or style guide. The core job-to-be-done is not content generation, but content evaluation. It is ideal for champion-challenger testing, where a new prompt or model version is pitted against the current production version, and for content QA pipelines where subjective qualities like 'warmth,' 'formality,' or 'audience appropriateness' must be judged against a documented standard. The primary user is an evaluation engineer, content strategist, or product manager who has a defined tone specification and needs a preference verdict with a clear, auditable justification, not just a gut feeling.

You should use this prompt when you already have two candidate outputs and a documented tone reference, such as a brand voice chart, a style guide, or a set of tone attributes. It is particularly effective when the difference between the two outputs is subtle and a simple checklist would miss the nuance. For example, you might use it to decide if an email draft from a new model sounds 'conversational yet professional' compared to the current template, or if a product description matches the 'bold and energetic' pillar of your brand. The prompt's value is in enforcing a structured comparison across multiple dimensions of tone, preventing the evaluator from fixating on a single, superficial difference. It is a critical component of an automated evaluation harness, where its structured JSON output can be logged, analyzed, and used to trigger a deployment gate.

Do not use this prompt when you need to generate content, evaluate factual accuracy, or judge outputs against a strict, objective schema. This prompt is for subjective, stylistic judgment. If you need to verify if a summary contains all key facts from a source document, use a groundedness or faithfulness evaluation prompt instead. If you need to check if a JSON output has the correct fields and types, use a format compliance validator. Furthermore, this prompt is not a replacement for human review in high-stakes brand campaigns. It should be used to scale and standardize the review process, flagging clear misalignments and surfacing close calls for a final human decision. The output is a preference signal with a rationale, which is most powerful when fed into a broader system that tracks inter-rater reliability and calibrates the LLM judge against periodic human spot checks.

This prompt template is the core of the pairwise comparison workflow for tone and style evaluation. It is designed to be copied directly into your evaluation harness, with square-bracket placeholders replaced by real data at runtime. The prompt instructs the model to act as an impartial judge, comparing two outputs against a provided style guide and target audience profile. It forces a preference decision with a structured justification, avoiding non-committal 'both are good' responses that provide no signal for model selection or content routing.

textCopy
You are an impartial style judge. Your task is to compare two AI-generated outputs and decide which one better matches the provided tone and style guidelines. You must choose one output as the winner. Do not declare a tie.

## STYLE GUIDE
[STYLE_GUIDE]

## TARGET AUDIENCE
[AUDIENCE_DESCRIPTION]

## OUTPUT A
[OUTPUT_A]

## OUTPUT B
[OUTPUT_B]

## EVALUATION CRITERIA
Evaluate both outputs on the following dimensions, weighted by importance:
1. Tone Match (40%): How well does the output's tone align with the style guide? Consider formality, warmth, authority, and emotional register.
2. Audience Suitability (30%): Is the language, complexity, and framing appropriate for the target audience?
3. Stylistic Consistency (20%): Does the output maintain a consistent voice throughout, or does it drift between styles?
4. Guideline Adherence (10%): Does the output follow any explicit stylistic rules, forbidden terms, or structural conventions in the style guide?

## OUTPUT FORMAT
Return a valid JSON object with exactly this structure:
{
  "winner": "A" | "B",
  "confidence": 0.0-1.0,
  "justification": "A concise paragraph explaining the decision, referencing specific evidence from both outputs and the style guide.",
  "dimension_scores": {
    "tone_match": {"A": 1-5, "B": 1-5},
    "audience_suitability": {"A": 1-5, "B": 1-5},
    "stylistic_consistency": {"A": 1-5, "B": 1-5},
    "guideline_adherence": {"A": 1-5, "B": 1-5}
  },
  "key_differentiator": "The single most decisive factor that determined the winner."
}

## CONSTRAINTS
- You must choose A or B as the winner. No ties.
- Base your decision only on the style guide and audience description provided.
- Do not evaluate factual accuracy, completeness, or helpfulness unless those are explicitly part of the style guide.
- If both outputs are equally poor, still choose the less poor one and note the low quality in your justification.
- Return only the JSON object. No preamble, no markdown fences.

To adapt this template, replace each placeholder with real data before sending it to the model. The [STYLE_GUIDE] should contain your organization's tone and voice documentation—include specific rules, forbidden terms, example phrases, and tonal descriptors. The [AUDIENCE_DESCRIPTION] should define the intended reader, including their expertise level, expectations, and context. [OUTPUT_A] and [OUTPUT_B] are the two texts being compared. In your harness, randomize the order of A and B for each evaluation to mitigate position bias, and log the original order so you can detect systematic preference for the first or second position. For high-stakes evaluations where style consistency is brand-critical, route low-confidence verdicts (confidence below 0.7) to a human reviewer for calibration.

The pairwise comparison prompt for tone and style is designed to be called programmatically within an evaluation pipeline, not as a one-off chat interaction. The harness must manage input assembly, position randomization, response parsing, and validation before the preference verdict is trusted. Each comparison request should include both outputs, the style guide or tone reference, the target audience description, and any explicit constraints. The harness is responsible for ensuring these inputs are complete and well-formed before the prompt is sent to the model, because missing context produces unreliable preference labels that undermine downstream decisions.

Position bias is the most common failure mode in pairwise comparison. The harness must randomize the order of Output A and Output B in every call, track which position each output occupied, and remap the model's preference back to the original output identities after parsing. Implement a swap flag in your request object and store the mapping alongside the response. For high-stakes comparisons, run each pair twice with swapped positions and require agreement before accepting the verdict. If the model prefers different outputs depending on position, flag the comparison as unreliable and escalate for human review. Log the position mapping, swap flag, and agreement status in your evaluation database for auditability.

Response parsing must handle structured JSON extraction from the model output. Define a strict schema for the preference verdict: preferred_output (enum: 'A', 'B', 'tie'), confidence (float 0-1), primary_reason (string), tone_alignment_notes (object with fields for each output), and style_guide_violations (array of violation objects). Use a JSON validator after extraction to reject malformed responses and trigger a retry with the same inputs. Set a maximum of two retries before logging the failure and routing to a human review queue. For production systems, consider using structured output modes (JSON mode, tool calling with a typed response schema) rather than relying on free-text parsing to reduce extraction errors.

Model choice matters for tone evaluation. Use a capable judge model that demonstrates strong instruction-following and stylistic reasoning—frontier models from major providers are appropriate here. Avoid using small or quantized models as judges for tone comparison because they often miss subtle stylistic distinctions and produce inconsistent preference labels. If cost is a concern, batch comparisons during off-peak hours and cache style guide embeddings rather than downgrading the judge model. Log the judge model version alongside every verdict so that judge drift can be detected when models are updated. Run a calibration set of known human-preferred pairs through the judge weekly to monitor score stability.

Human review gates are essential when the confidence score falls below a configurable threshold (start at 0.7 and tune based on your tolerance for automated decisions), when the model returns a tie, or when position-swapped runs disagree. Route these cases to a review interface that displays both outputs side by side with the style guide, hides the model's preliminary verdict to avoid anchoring bias, and captures the human reviewer's preference and rationale. Use these human labels to measure judge accuracy over time and to identify style guide sections that produce ambiguous comparisons. Never ship tone-based routing or model selection decisions based solely on unverified pairwise comparison output without a human-in-the-loop checkpoint for edge cases.