Verified against Claude · 2026-07-27
Compare several proposals or contracts side by side, not one summary at a time
A structured comparison prompt for several long documents at once that forces a criteria-by-criteria table with weighted and unweighted recommendations, so genuine cross-document differences surface instead of three separate summaries you have to compare yourself.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You have 4 documents below, each labeled with a name. The job is to compare them against each other on the criteria listed, not to summarize each one in isolation — a reader should be able to see how the documents differ at a glance, in one place, without cross-referencing several separate summaries themselves. COMPARISON CRITERIA, IN THE ORDER THEY MATTER MOST - Total contract value over 3 years - Termination notice period - Data residency guarantees - SLA uptime commitment - Named 24/7 support escalation path WEIGHTING Termination notice period and data residency matter most (we're EU-regulated); total cost matters least since all four bids are within 8% of each other. Use this to inform which differences actually matter in your closing recommendation, even though every criterion still gets its own row in the table below regardless of weight. DECISION CONTEXT Procurement lead needs a recommendation by Friday to bring to the CFO for sign-off — this should be decision-ready, not exploratory. OUTPUT FORMAT 1. A table: one row per criterion, one column per document. Each cell is a short factual finding grounded in that specific document, not a rating word like "good" or "poor" unless the criterion is explicitly subjective — state the actual number, term, or fact. 2. Distinguish "this document does not address the criterion at all" from "this document addresses it in a way that is weak or unfavorable." Mark the former as "Not addressed" and the latter with the actual unfavorable term stated plainly. These are different findings with different implications and must never be merged into one vague cell. 3. Below the table, a short weighted recommendation: which document comes out ahead once Termination notice period and data residency matter most (we're EU-regulated); total cost matters least since all four bids are within 8% of each other. is applied, and which comes out ahead if you ignore weighting and just count categories won — if these two answers differ, say so explicitly, since that difference is itself useful information about how much the recommendation depends on the weighting you were given. 4. Name the single biggest risk of choosing the top-ranked document anyway, even though it's the recommendation — every option has a real downside, and a recommendation with none named has not been checked hard enough. CONSTRAINTS - Every cell must be traceable to something actually stated in that document. If you are inferring rather than quoting or closely paraphrasing, mark the cell "(inferred)" and say what you based the inference on. - Do not let the order the documents happen to be listed in imply a ranking — the table itself should let a reader form their own initial impression before your recommendation in part 3 confirms or complicates it. - If two documents are functionally tied on a criterion, say so rather than manufacturing an artificial distinction just to fill the cell with something different. - If a criterion depends on a term defined differently across documents (one vendor's "uptime" excludes scheduled maintenance and another's doesn't), state the difference in definition as part of the cell itself, not just the resulting number — the number alone is not comparable if it's measuring something slightly different in each document. DOCUMENTS DOCUMENT: Vendor A Proposal [full text] DOCUMENT: Vendor B Proposal [full text]
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Given several documents and a vague 'compare these' ask, a model will often produce separate summaries back to back and leave the actual comparing to the reader, because summarizing each document independently is the lower-effort default path through the material. Fixing the output as one table with criteria as rows and documents as columns forces genuine cross-document synthesis: to fill in a single row across four columns, the model has to hold all four documents' treatment of that specific criterion in mind at once rather than processing them sequentially and never directly juxtaposing them. Distinguishing 'silent on this topic' from 'addresses it poorly' as separate findings matters in real due-diligence use because these have opposite practical implications — a contract silent on data residency might mean the term is negotiable, while one that addresses it with an explicit unfavorable term is a fixed objection — and a model given no instruction to separate them will default to treating an unaddressed topic as an implicit negative, which is not a safe inference to make on someone's behalf. Requiring both a weighted and an unweighted recommendation, and asking whether they diverge, surfaces how contingent the top pick actually is: weighting is often supplied quickly and somewhat casually, and a recommendation that would flip under slightly different weights is a materially different kind of confidence than one that holds either way — without asking for both explicitly, that sensitivity stays invisible behind a single confident-sounding answer. The instruction to state a differently-defined term as part of the cell, not just the number, targets a specific way comparison tables mislead even when every individual number is accurate — two "uptime" figures that measure different things are not actually comparable side by side, and a table that only shows the numbers invites exactly that false comparison. Requiring the biggest risk of the top-ranked choice even after recommending it counters a sycophantic recommendation bias where a model, having settled on a winner, tends to describe it in increasingly favorable terms across the rest of the response rather than continuing to hold it to scrutiny.
What you get back
A 5-row by 4-column table (one column per vendor), e.g. row "Termination notice period": Vendor A = "60 days (inferred — stated as 'standard notice period' in §9.2, not explicitly 60 days)", Vendor B = "Not addressed in this document", Vendor C = "90 days", Vendor D = "30 days", followed by: "Weighted recommendation: Vendor D — shortest notice and only vendor with a named 24/7 escalation contact. Unweighted category count also favors Vendor D, so the recommendation is not weighting-dependent."
Verified against
Claude Sonnet 4.6 · 2026-07-27
Changelog
- 2026-07-27 — Initial publish, verified against Claude Sonnet 4.6 with a 4-vendor proposal set.
Building this for real?
This is a free starting point. If you'd rather have what Scult builds built and running for your business, that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
