Fact-Checking and Evidence

Product Claim Substantiation

Verify product feature, performance, compatibility, availability, pricing, security, and comparison claims against current, scoped, reproducible evidence.

Free editable Markdown · Product marketers, legal reviewers, and editors · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Claim record

Claim ID and exact wording: [Enter]
Channel, placement, and visual context: [Enter]
Product, feature, plan, and version: [Enter]
Audience and market: [Enter]
Implied outcome: [What could a reasonable reader expect?]
Claim type: [Feature / Performance / Comparison / Price / Compatibility / Security / Other]
Qualifier and its placement: [Enter]
Consequence if unsupported: [Low / Medium / High]

Evidence and test

Evidence source or test ID: [Enter]
Owner and test date: [Name, YYYY-MM-DD]
Environment and configuration: [Enter]
Inputs, sample, and exclusions: [Enter]
Metric and calculation: [Enter]
Comparison baseline: [Enter or Not applicable]
Results with denominator: [Enter]
Reproduction steps: [Enter]
Limitations and failed cases: [Enter]
Independent confirmation: [Enter or Not required]

Scope and review checks

Approved wording: [Enter exact text]
Required attribution: [Enter or None]
Reviewers and dates: [Product, editorial, qualified review]

Evidence tests the same product version, audience, and condition as the claim.
“Best,” “fastest,” “all,” “always,” and other absolute language is justified or removed.
Comparators are current and evaluated under equivalent conditions.
Price, availability, and compatibility include necessary market or plan scope.
Security, privacy, health, and regulated implications reached qualified reviewers.
Footnotes and qualifiers are clear beside the claim.

Release and monitoring

Approved channels and locales: [List]
Published URL or asset: [Enter]
Publication version: [Enter]
Live wording verified by: [Name/date]
Evidence expiry: [Date or trigger]
Monitoring owner: [Name/team]
Change response: [Pause / Qualify / Remove / Retest]

How to use this template

Capture the exact claim and its full visual, channel, audience, and product context.
Define every scope element, implied comparison, qualifier, and reasonable reader expectation.
Gather current product evidence or run a reproducible test that matches the promise.
Obtain product, editorial, and qualified legal, security, or privacy review as applicable.
Approve a controlled version, monitor changes, and expire or recheck the claim on trigger.

Freeze the wording before selecting evidence

Small words can change the burden of a product claim. “Can export,” “exports faster,” “fastest,” “secure,” “works with,” and “available everywhere” make different promises. Copy the exact sentence, headline, label, visual implication, footnote, and call to action. Define product version, plan, market, device, configuration, user type, comparison baseline, and time period. Consider the net impression created by the surrounding page, not only one literal sentence. A qualifier hidden far away may not repair a prominent absolute claim. Record what a reasonable reader could expect before deciding whether current evidence supports it.

Match the test to the promised outcome

Use current product specifications for basic behavior and a reproducible method for performance or comparison claims. Record environment, sample, inputs, metrics, success criteria, exclusions, date, and responsible tester. Test typical and boundary conditions relevant to the intended audience rather than selecting only favorable examples. Vendor data may support the vendor's own behavior but should be attributed and independently reviewed when the claim compares competitors. For compatibility, distinguish officially supported, technically possible, beta, and untested. For security or privacy language, route the claim to qualified owners and avoid turning a control or certification into a guarantee of safety.

Control versions and expiry

Evidence can become obsolete when pricing, plans, infrastructure, interfaces, competitor products, or market availability changes. Give every approved claim an owner, source record, approval date, permitted channels, and expiry or trigger. Ensure translated claims preserve scope and link to equivalent terms or product behavior in that locale. At release, verify that the exact approved wording appears and that footnotes are readable where the claim is encountered. If monitoring finds a product change or failed reproduction, pause, qualify, or remove the claim while it is reinvestigated rather than leaving known ambiguity live.

See the fields in context

Fictional example: batch export comparison

ClipGarden and all tests and products named here are invented; the figures are not real performance evidence.

Draft claim: “ClipGarden exports twice as fast as every competitor.”
Imaginary test: Five files, one device, and one unnamed competitor were tested once.
Gap: The method cannot support “twice,” “every,” typical performance, or other environments.
Decision: Remove the comparison and publish only a verified feature statement about supported batch export.
Trigger: Recheck after any fictional export-engine or plan change.

Frequently asked questions

Is a product specification enough evidence?

It may establish current documented behavior. Performance, superiority, typical results, or comparative claims usually require stronger and more specific evidence.

Can a footnote fix an overbroad headline?

Not reliably. The prominent claim and its net impression should be accurate; qualifiers must be clear and close enough to be understood.

How often should competitor comparisons be retested?

Set a short, explicit trigger based on competitor and product release cycles. Comparisons can become outdated faster than stable feature descriptions.

What if a claim is true only for some users?

State the relevant plan, configuration, market, input, or condition in the claim where readers need it. Do not imply universal results.