Verify seller claims yourself; the table is not proof

The quality bar for this project is not whether the output feels polished in a chat window. Review it in the conditions faced by a student who needs to verify seller claims before spending money. Check completeness, fidelity to the supplied facts, accessibility, and whether the result helps the next person take the intended action. Use a simple score: pass, revise, or cannot judge yet.

manufacturer specifications, an independent battery test, a software compatibility page, and the buyer's budget are the evidence set. Compare the output directly against them. A claim that seems likely but cannot be checked is an unknown, not a pass. Record one reason for every revision; that note will reveal whether the problem was missing context, an unclear request, or a constraint the tool cannot meet.

Write a short record before you move on. For a college buyer comparing three laptops under price, battery, weight, and required-software constraints, state the claim or choice under review, then name the evidence that supports it: manufacturer specifications, an independent battery test, a software compatibility page, and the buyer's budget. Next, name what the evidence does not establish. This last line prevents a narrow test from becoming a broad promise. If another team member opened your record next month, they should be able to reproduce the review without trusting your memory.

Now make the trade-off visible. A student who needs to verify seller claims before spending money may value speed, clarity, cost, control, or reassurance differently. Explain which of those mattered in the current version and why. Do not let a model choose the trade-off simply because it can produce a confident answer. The responsible owner decides whether the upside justifies the remaining uncertainty.

Finally, connect the decision to a next action. If the current evidence is enough, identify the smallest safe step forward. If it is not, request a specific source, approval, or test. The stop condition remains concrete: a deciding cell lacks a source, a specification conflicts across sources, or software compatibility has not been checked. A documented pause is a successful outcome when it keeps a weak result from becoming a consequential one.