Source Diversity Enforcement Prompt for Evidence Selection

This prompt is for RAG pipeline builders and search engineers who need to prevent their question-answering systems from becoming echo chambers. The core job-to-be-done is to transform a flat list of retrieved passages into a diverse evidence set that enforces minimum source count, domain variety, and perspective coverage before any answer synthesis occurs. The ideal user is an AI engineer or technical decision maker who has already observed over-reliance on a single document or author in their production RAG system and needs a programmatic, testable intervention. Required context includes the original user query, the full retrieval set with source metadata (author, domain, publication date), and a defined diversity policy specifying minimum sources, required domains, or perspective categories.

Do not use this prompt when your retrieval pool is inherently homogeneous—for example, a single textbook, a sole-author codebase, or a corpus where all documents share the same perspective by design. The diversity enforcement will either fail to find sufficient variety or will fabricate distinctions where none exist. This prompt is also inappropriate for latency-sensitive real-time applications where the additional reasoning step adds unacceptable delay; in those cases, push diversity constraints into the retrieval stage itself via hybrid search or multi-index queries. Finally, avoid this prompt when the user's question demands a single authoritative answer from a canonical source, such as 'What is the current SLA for service X?'—diversity enforcement would dilute the correct answer with irrelevant or less-authoritative alternatives.

Before implementing this prompt, define your diversity dimensions explicitly. Common dimensions include source domain (e.g., academic, industry, government), author or publisher, publication date range, and perspective or conclusion. Write these into a policy document that the prompt can reference as [DIVERSITY_POLICY]. Without this, the model will invent its own diversity criteria, which may not match your product requirements. After deployment, monitor two failure modes closely: false diversity, where the model selects passages that appear different but convey identical information, and forced diversity, where it includes low-quality or irrelevant passages just to meet a quota. Both require eval loops comparing selected evidence sets against human-curated diverse sets for the same queries.

This prompt template is designed to be dropped into a RAG pipeline after retrieval and before answer synthesis. It instructs the model to select a diverse evidence set from the provided candidate passages, enforcing explicit constraints on source count, domain representation, and viewpoint coverage. The goal is to prevent echo-chamber answers where a single source or perspective dominates the final response. Use this template when your knowledge base contains documents from multiple authors, time periods, or organizational units, and when over-reliance on one source would degrade answer quality or introduce bias.

textCopy
You are an evidence selection specialist. Your task is to select a diverse set of passages from the provided candidates that will support a well-rounded, multi-perspective answer to the user's question.

## INPUT
User Question: [USER_QUESTION]
Candidate Passages: [CANDIDATE_PASSAGES]

## SELECTION CONSTRAINTS
1. **Minimum Source Count**: Select passages from at least [MIN_SOURCES] distinct sources. A source is defined by its [SOURCE_IDENTIFIER_FIELD] (e.g., author, organization, document ID).
2. **Domain Variety**: If the candidate set spans multiple domains, select at least one passage from [MIN_DOMAINS] different domains. Domains are indicated by the [DOMAIN_FIELD] field.
3. **Perspective Coverage**: Identify the primary perspectives or viewpoints present in the candidate set. Select passages that represent at least [MIN_PERSPECTIVES] distinct perspectives. If fewer perspectives exist, note the limitation.
4. **Relevance Threshold**: Only select passages with a relevance score above [RELEVANCE_THRESHOLD]. Exclude all others.
5. **Token Budget**: The total selected passages must not exceed [MAX_TOKENS] tokens.

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "selected_passages": [
    {
      "passage_id": "string",
      "source": "string",
      "domain": "string",
      "perspective": "string",
      "relevance_score": number,
      "token_count": number,
      "selection_rationale": "string"
    }
  ],
  "diversity_summary": {
    "total_sources": number,
    "total_domains": number,
    "total_perspectives": number,
    "total_tokens": number
  },
  "excluded_passages": [
    {
      "passage_id": "string",
      "exclusion_reason": "string"
    }
  ],
  "underrepresented_viewpoints": ["string"],
  "diversity_score": number
}

## DIVERSITY SCORE CALCULATION
Calculate a diversity_score from 0.0 to 1.0 using:
- Source spread: (unique_sources_selected / total_unique_sources_available) * 0.3
- Domain spread: (unique_domains_selected / total_unique_domains_available) * 0.3
- Perspective spread: (unique_perspectives_selected / total_unique_perspectives_available) * 0.4

## RULES
- If constraints cannot be met, select the best possible set and flag violations in underrepresented_viewpoints.
- Do not fabricate sources, domains, or perspectives not present in the candidate passages.
- Prioritize passages that add unique information over those that repeat already-selected content.

Adaptation notes: Replace the square-bracket placeholders with values from your retrieval pipeline. The [SOURCE_IDENTIFIER_FIELD] and [DOMAIN_FIELD] should match the metadata schema of your vector database or search index. If your passages lack domain or perspective metadata, remove those constraints or replace them with proxy signals (e.g., publication date ranges, author affiliations). The diversity score formula can be adjusted to weight source spread, domain spread, and perspective spread differently based on your use case. For high-stakes domains, add a [RISK_LEVEL] field and require human review when the diversity score falls below a threshold. Always validate the JSON output against your expected schema before passing selected passages to the synthesis step.

The Source Diversity Enforcement Prompt is designed to sit between your retrieval step and your answer synthesis step. It accepts a set of candidate passages and a user query, then outputs a curated subset that meets explicit diversity constraints. In a production harness, this prompt is not a one-shot call—it is a structured component with a strict JSON output contract, schema validation, and a retry loop for malformed responses. The harness must enforce the minimum source count, domain variety, and perspective coverage rules defined in the prompt, and it must log every selection decision for downstream auditability.

To wire this into an application, wrap the prompt in a function that accepts retrieved_passages, user_query, min_sources, required_domains, and diversity_constraints as inputs. The function should call the model with response_format set to a JSON schema that matches the expected output: an array of selected passages, each with a source_id, domain, perspective_label, and selection_rationale. After receiving the response, validate the JSON structure, check that the number of selected sources meets or exceeds min_sources, verify that required_domains are represented, and confirm that perspective labels are not all identical. If validation fails, retry up to two times with the validation error message appended to the prompt as feedback. If the third attempt still fails, log the failure, fall back to a diversity-agnostic top-k selection, and raise an alert for manual review. This pattern prevents a single malformed output from breaking the entire RAG pipeline.

For high-stakes domains such as legal research or clinical evidence review, add a human-in-the-loop step after diversity enforcement but before answer synthesis. Present the curated evidence set to a reviewer with the selection rationales and any flagged underrepresented viewpoints. The reviewer can approve, reject, or add missing sources before the answer is generated. For observability, log every diversity enforcement call with the input passage count, the selected passage count, domain distribution, perspective distribution, validation pass/fail status, retry count, and model used. This trace data is essential for detecting drift in model behavior, identifying when diversity constraints are too strict for the available evidence, and tuning the prompt over time. Avoid using this prompt when the retrieval set is already small—if fewer than min_sources passages are retrieved, skip diversity enforcement and flag the evidence gap directly.