Launch Claim Evidence Matrix

# Launch Claim Evidence Matrix

Verify a finite set of product-launch claims against current source pages and produce a review-ready evidence matrix before publication.

## Loadout capabilities

Use <action-tag>api:tinyfish_api:search</action-tag> to discover current first-party and authoritative third-party sources for each reviewed claim. Use <action-tag>api:tinyfish_api:fetch_urls</action-tag> to retrieve the exact pages used as evidence and to preserve page metadata with the review.

Read both current Action schemas before creating inputs. Check the TinyFish connection through Aident Vault when required and never request a raw credential. Use small, claim-specific queries and fetch only the URLs that can materially support or contradict the reviewed copy.

## Intake

Request the launch draft or a numbered list of 5 to 20 claims, the product's official domain, target audience, launch date, target geography and language, and any claims that legal or product owners have already approved. Keep the user's exact wording as the comparison source; do not silently improve it before verification.

This Skill checks factual claims before publication. It does not publish content, send outreach, change a website, create testimonials, calculate unprovided metrics, or approve legal language.

## Build the claim inventory

Split the draft into atomic claims that can be verified independently. Classify each as product capability, integration or compatibility, price or availability, performance, customer or usage, comparative, security or compliance, roadmap, or opinion. Keep non-factual slogans in the matrix as `Opinion` so reviewers know they were not evidence-checked.

For each factual claim, define what evidence would be sufficient. Prefer a current official product, documentation, pricing, release-note, status, trust, or legal page. Customer and comparative claims require evidence appropriate to their wording; a vendor-authored page cannot independently prove market leadership.

## Research and verification

1. Search the official domain with a narrow query for the exact capability, plan, integration, metric, or policy.
2. Search authoritative third-party sources only when the claim inherently needs external corroboration or when the first-party evidence conflicts.
3. Fetch every selected evidence URL. Preserve the canonical or final URL, title, observed time, visible update date when present, and a concise supporting or contradicting excerpt.
4. Check scope carefully: product edition, plan, platform, geography, language, release channel, date range, metric definition, and whether a feature is generally available, beta, or planned.
5. Never cite a search snippet as final evidence. If a page cannot be fetched or the relevant text is absent, mark the evidence gap.
6. Stop expanding research when the claim is supported, contradicted, or clearly unverified. Do not collect unrelated market research.

## Findings

Assign one status per atomic claim:

- `Supported`: the current wording is directly supported at the claimed scope.
- `Narrower Wording Needed`: evidence supports a qualified or smaller claim.
- `Contradicted`: current evidence conflicts with the claim.
- `Unverified`: sufficient current evidence was not found.
- `Time Sensitive`: supported now but likely to change before or shortly after launch.
- `Opinion`: not a testable factual claim.

For anything except `Supported` or `Opinion`, propose the smallest accurate rewrite while preserving the intended message. Do not invent a superlative, customer count, benchmark, date, certification, integration, or roadmap commitment. When sources disagree, show both and route the claim to the appropriate owner.

## Review boundary

Present the complete matrix for product, legal, or communications review. Never treat evidence collection as publication approval. Obtain separate authorization before applying rewrites to a document, sending the matrix, or publishing launch copy in any channel.

## Output

Return a dated matrix with claim ID, original wording, claim type, status, supported scope, evidence URL, observed date, excerpt, limitation, and proposed rewrite. Finish with counts by status, the highest-risk claims, time-sensitive recheck dates, and the exact owner decisions still needed.