Comparison Table Prompt for Retrieved Evidence

This prompt is designed for a specific job-to-be-done: generating a structured, side-by-side markdown comparison table from a set of retrieved documents. The ideal user is a product team, analyst, or engineer building a RAG pipeline where a user asks to compare two or more entities—such as software frameworks, vendors, protocols, or product tiers—and the system must produce a decision-support artifact. The core requirement is that every cell in the generated table must be directly traceable to source evidence, making the output auditable and defensible. This is not a prompt for generating subjective opinions or creative comparisons; it is a tool for synthesizing documented facts into a structured format that fits into comparison UIs, dashboards, or analyst briefs.

Use this prompt when your application has successfully retrieved a set of documents that contain comparable information about the entities in question. The prompt assumes that the retrieval step has already occurred and that the provided context contains sufficient evidence to populate the requested comparison dimensions. It works best when you can supply a clear list of dimensions (e.g., 'Pricing Model', 'Security Certifications', 'API Limits') and a defined output schema. The prompt is particularly effective when paired with a validation layer that checks for missing cells, unsupported claims, and false equivalences before the table reaches the user. For high-stakes domains like vendor due diligence or compliance comparisons, you should always route the generated table through a human review step and log the source evidence for each cell.

Do not use this prompt when the retrieved evidence is insufficient to populate the requested dimensions, or when the comparison requires subjective judgment beyond what the documents support. If the source documents lack comparable data points, the model may hallucinate to fill gaps or create false equivalences. In these cases, the system should either abstain from generating the table, flag missing dimensions explicitly, or trigger additional retrieval. This prompt is also not suitable for generating real-time pricing comparisons, live inventory checks, or any data that requires API calls to external systems—it operates strictly on the provided context. For comparisons that require numerical analysis or calculations (e.g., total cost of ownership over time), pair this prompt with a tool-use step that performs the computation separately and injects the results into the context before table generation.

This template produces a markdown comparison table from retrieved documents. It forces the model to extract dimensions, populate cells with evidence-backed values, and cite sources per cell rather than per row or per answer. Use it when you need side-by-side analysis of options, products, protocols, or approaches where each claim must be traceable to a specific passage. The template includes placeholders for your retrieved context, comparison subjects, output constraints, and evaluation criteria.

codeCopy
You are a precise comparison analyst. Your task is to generate a comparison table from the provided evidence only.

## INPUTS
- Retrieved Evidence: [RETRIEVED_DOCUMENTS]
- Subjects to Compare: [COMPARISON_SUBJECTS]
- Comparison Dimensions: [DIMENSIONS]
- Output Format: [OUTPUT_FORMAT]
- Constraints: [CONSTRAINTS]

## INSTRUCTIONS
1. Extract comparison dimensions from [DIMENSIONS]. If not provided, infer the most relevant dimensions from the evidence.
2. For each subject in [COMPARISON_SUBJECTS] and each dimension, populate the cell using only information present in [RETRIEVED_DOCUMENTS].
3. For every cell, include a source citation in the format [Source: document_id, section/paragraph]. If multiple sources support a cell, cite the most specific one.
4. If evidence is missing for a cell, enter "No evidence found" and do not fabricate.
5. If evidence conflicts across sources for a cell, note the conflict: "Conflicting evidence: [summary]" with citations for both sources.
6. Do not add dimensions, subjects, or values not present in the evidence.
7. Do not summarize, recommend, or draw conclusions. Produce only the comparison table.

## OUTPUT SCHEMA
Generate a markdown table with:
- Header row: Dimension | [Subject 1] | [Subject 2] | ...
- One row per dimension
- Each cell contains: value + source citation
- After the table, add a "Coverage Notes" section listing any dimensions where evidence was missing or conflicting.

## EXAMPLE OUTPUT STRUCTURE
| Dimension | Subject A | Subject B |
|-----------|-----------|----------|
| Price | $10/user/month [Source: doc_3, para 12] | $15/user/month [Source: doc_7, para 4] |
| Uptime SLA | 99.9% [Source: doc_3, para 18] | No evidence found |

## CONSTRAINTS
- [CONSTRAINTS]
- Maximum table width: [MAX_COLUMNS] subjects
- Maximum dimensions: [MAX_DIMENSIONS]
- If evidence exceeds [MAX_TOKENS], prioritize the most recent and authoritative sources.

Adapt this template by replacing each square-bracket placeholder with your specific inputs. For [RETRIEVED_DOCUMENTS], include document IDs or chunk references so citations are traceable. For [DIMENSIONS], provide an explicit list when you need consistent comparisons across multiple runs; omit it when you want the model to discover dimensions from evidence. The [CONSTRAINTS] field should include domain-specific rules such as 'prefer GA features over beta', 'use list prices not negotiated rates', or 'flag deprecated versions'. Always test with a golden set of documents where you know the correct comparison values before deploying. If the output will feed into a UI component, add a [OUTPUT_SCHEMA] that specifies exact field names and types for programmatic consumption.

The comparison table prompt is not a standalone artifact—it is a component inside a larger RAG pipeline. Before the prompt executes, your application must retrieve and deduplicate evidence chunks, assemble them into the [CONTEXT] placeholder, and decide whether enough evidence exists to attempt a comparison. After the prompt returns a markdown table, the application must validate the output, handle failures, and route the result to the correct downstream consumer, whether that is a UI component, an API response, or a human review queue.

Wire the prompt into a structured workflow with clear pre- and post-processing steps. On the input side, implement a context gate that checks whether the retrieved evidence contains at least two distinct entities to compare and covers the requested dimensions. If the gate fails, return a controlled abstention response rather than forcing the model to fabricate a comparison. On the output side, parse the markdown table into a structured object that your application can validate. Check for: (1) dimension coverage—does the table include all requested comparison dimensions? (2) evidence alignment—does each cell contain a source citation or reference? (3) false equivalence detection—are two options presented as comparable when they operate at different abstraction levels or scopes? (4) schema compliance—does the output match the expected column structure and data types? Run these checks programmatically before the response reaches a user.

For production reliability, implement a retry-and-escalate pattern. If validation fails on dimension coverage or schema compliance, retry the prompt once with the validation errors appended to the [CONSTRAINTS] placeholder. If the second attempt also fails, escalate to a human review queue with the original context, the failed output, and the specific validation errors. Log every comparison request with the prompt version, model, retrieved context IDs, output table, validation results, and escalation decision. This trace data is essential for debugging dimension drift, evidence gaps, and model behavior changes across prompt iterations. For high-stakes domains—such as vendor selection, clinical comparisons, or compliance decisions—require human approval before the comparison table is consumed by downstream systems or shown to end users.