Produce a competitive brief on a real product category where every claim carries a source URL and a freshness date — then manually verify the top ten claims and log the results. The design guarantees some claims fail verification, and the ledger documenting those failures is the artifact that matters.
Meera is a Senior PM at a Pune B2B SaaS company selling workforce-scheduling software. Her VP wants a competitive landscape brief by Friday for an adjacent category the company might enter. Meera knows the trap from experience: AI produces a fluent, confident competitive brief in ten minutes, and roughly a fifth of its specifics — prices, feature availability, launch dates, customer counts — turn out to be stale or invented. The brief will be quoted in a decision meeting for months, long after anyone remembers it came from a chatbot, so the errors have to be caught now or believed forever. This lab makes that failure rate visible, measurable, and survivable.
Your brief must follow this claim format — no naked claims allowed:
BRIEF CLAIM FORMAT
Every factual claim line ends with: [source: URL | seen: DATE]
Example:
"Acme's Teams plan starts at $4/user/month [source: acme.example/pricing
| seen: 2026-08-05]"
Claims with no source line are OPINIONS and must be labeled (opinion).
VERIFICATION LEDGER (one row per claim you verify)
No | Claim (short) | AI's source | What the live page says
| Verdict (CONFIRMED / STALE / WRONG / UNVERIFIABLE) | Corrected claim
1 | | |
...ten rows minimum...
Summary line: X confirmed / Y stale / Z wrong / W unverifiable
Get the memory-only draft first. Tell your AI: "Without searching the web, from your training knowledge only: write a competitive brief on [category]. Cover the top 5 products: pricing, three flagship features each, target segment, and one recent notable change per product. Be specific with numbers and dates." Save this draft untouched. Specific-and-confident is exactly what you want here — you are creating the "before" specimen.
Get the web-grounded draft. Same prompt, but now with web access on, and append: "Every factual claim must end with a source URL and the date you accessed it, in the format [source: URL | seen: DATE]. If you cannot find a source, write UNSOURCED next to the claim." If your tool cannot browse, use Perplexity for this step.
Diff the two drafts. Put them side by side and mark every place they disagree — prices, feature names, plan tiers, dates. Each disagreement is a claim you now know cannot be trusted from either draft without checking. Count the disagreements and note the count; it is your first data point on how stale memory-only competitive intel is.
Choose your top ten claims to verify. Pick the ten claims that would most change a market-entry decision if wrong: entry-level and mid-tier pricing for the top three products, two flagship feature claims, one "recent change" claim, and any claim the two drafts disagreed on. Decision-relevant claims first — verifying trivia is theater. A useful filter: for each candidate claim, ask "if this is wrong, does our positioning, pricing, or build-vs-enter decision change?" If the answer is no, it does not earn one of the ten slots.
Verify each claim against the primary source. Open the vendor's own pricing or feature page — not a review site, not the AI's summary of it. For each ledger row record what the live page actually says today and give a verdict: CONFIRMED (matches), STALE (was true, changed), WRONG (never matched the source), or UNVERIFIABLE (no primary source exists). Pricing pages that hide numbers behind "Contact sales" are UNVERIFIABLE — that is a finding, not a failure. Record verdicts as you go, not from memory at the end; two hazy recollections into a ledger and you are back to unverified claims with extra steps.
Interrogate the suspicious sources. For any claim whose cited URL does not actually contain the claim — a real page cited for something it never says — mark it WRONG and note "source does not support claim" in the ledger. This is the most dangerous failure class, because the citation looks like evidence and most readers will never click it.
Rewrite the brief with the ledger applied. Correct every stale or wrong claim, keep the source-and-date format, move anything unverifiable into a clearly labeled "Unverified — treat as directional" section, and add a two-line methodology note at the top: how many claims verified, what the confirmed/stale/wrong split was.
Write the reusable freshness rule. Close with three lines in your own words: which claim types went stale fastest in your ledger, how old a "seen" date you would accept for each type before re-verifying, and what you will always verify manually no matter what the AI cites. This is your personal competitive-intel policy going forward.
A claim with a real URL attached is not a verified claim — models regularly cite pages that do not contain the fact, and that failure survives every skim-read.
A complete lab has all of the following:
[source | seen], corrections applied, unverifiables quarantined, and the methodology note on top.Competitive intel from AI is a fast first draft with a built-in staleness rate. The verification ledger — claim, source, live check, verdict — is what converts it into something you can put in front of a decision, and the failures it logs are its most valuable rows.