---
name: verify-achievements-are-evidenced-not-just-claimed
description: "Check the proof behind each claim. Keep real stories and remove claims the facts cannot support."
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify achievements are evidenced, not just claimed

People should be able to check the claims on your site. This guide helps you match each claim to real proof. Start with what the page says, then find the source that backs it up.

**The path:** Exact claim → Primary proof → Honest public wording → Checked result.

**Use this when:** A site or page set needs its achievements, results, praise and relationship language reviewed.

## Inputs
- The scoped pages, including home/about, bios, logo walls, results and testimonials.
- The actual proof inventory: primary features, dated result records, named quotes, certificates and source media with appropriate use rights.
- The page role and site voice, plus supported edit scope and the responsible content owner.
- An internal claim-to-source table; private evidence and review labels remain in that record.

## First-run prompt

> Review the supplied pages and primary proof. Map exact claims to evidence, preserve source-supported first-person scenes where appropriate, and narrow unsupported relationship or result wording. Complete authorized edits; retain HOLD and internal records without publishing verification theater or invented praise.

## Steps
1. Read the full scoped copy and list each achievement or result claim with its exact sentence and location. Include numerical results, dates, awards, credentials, logos, client/partner wording and implied endorsements.
2. Inspect the primary evidence for each claim. A press link must identify the subject and actual feature; a metric must have its period, denominator and source. An undated screenshot or logo by itself may not support the stated result.
3. On a personal-brand site, tell the supported moment in the owner’s real voice: what happened, why it mattered and a relevant human detail, with a compact source link. Do not invent a memory to satisfy style. Fail a trophy-name paragraph that piles up famous people, brands or titles without a specific shared scene and useful lesson.
4. Make relationship language no stronger than the evidence. A photo, interview or co-appearance does not alone establish friend, client, partner, mentor or endorsement. Narrow the noun and verb to the actual source or keep the stronger claim HOLD.
5. Check praise against the exact source quote, named person and applicable role/company or city, with permission where required. Anonymous praise or attribution only to a domain/company remains HOLD; do not replace the missing speaker with a guessed owner.
6. Keep the public page natural. Remove repeated defensive caveats, confidence scores, proof-record IDs, internal verification process labels and repurposing instructions unless that system is the actual subject. Preserve a materially necessary legal, regulatory, or compliance disclosure, limited to the claim that requires it.
7. Prepare the supported wording, source link or removal for each failed claim. Carry out authorized edits through the current source. Missing proof stays HOLD for public publication and repurposing; a caveat is not a workaround for an unsupported claim.
8. Recheck the canonical public wording, evidence links and visual context after changes. Keep the internal claim table private as appropriate, record exact unresolved evidence and hand it to the owner. Do not call the entire site verified if only the about page was reviewed.

## Definition of done (QA checklist)

- [ ] Every claim in the stated scope has sufficient evidence or an explicit unresolved HOLD/removal.
- [ ] Personal-brand proof uses supported scenes and lessons rather than trophy-name lists.
- [ ] Relationship nouns and numerical scope match the record; named praise is exact and properly sourced.
- [ ] Public copy omits internal review/repurposing metadata and repeated defensive caveats, while retaining necessary scoped compliance disclosure.
- [ ] Authorized public edits and source links are rechecked; the internal audit table is retained separately.

## Example(s)

**Fictional teaching example — no real person’s claim was checked.** Alex’s sample page says, “I partner with the city’s top bike shop.” The supplied fictional record shows only that Alex appeared in a shop’s repair workshop video.

The supported scene is: “At the repair workshop, I showed how a clear brake photo helps the shop decide what to inspect next.” The real execution would link the actual source segment. “Partner” remains HOLD unless a separate record supports that relationship.

Do not append “This does not prove partnership” to the public paragraph. Use the accurate sentence. The stronger claim stays out of derivative posts too until its proof exists.

## Handoff and Content Factory context

The content owner receives exact accepted wording and missing proof. [Verify social-proof photos](https://local-service-spotlight.github.io/task-library/?task=verify-social-proof-photos-present#task-verify-social-proof-photos-present) checks photo context. Any later repurposing must inherit these evidence limits, not restore a stronger claim.

This is a supporting quality check for the [Content Factory](https://blitzmetrics.com/content-factory/). Produce gathers real source material; Process makes useful assets; Post places and checks them; Promote distributes suitable work within its own scope. This check does not automatically execute all four stages. Use the actual next step above; catalog neighbors are not prerequisites.

## When this runs

Run before publication and when claims or supporting evidence change. Recurring rechecks use a real defined scope and tracker; no automatic lifetime verification is promised.

## First-run setup and continuity

Open the supplied task file and its linked source. Verify the project’s real inputs, account, access and output folder before work. This Markdown file is a guide; it does not install an app, connect an account, supply a subscription or create a schedule. Carry out work already authorized; do not ask for the same approval again. Keep any unsupplied destination or new action outside that scope clearly pending.

Save source IDs, versions, decisions, checked outputs and next owner in the project tracker. Before a retry, check the saved state and other workers’ changes. A model name does not guarantee memory or a running timer. Repeated work needs an actual configured trigger and durable state; one-off work can be started by the prompt above.

Keep agent media muted with volume zero before playback. If mute cannot be verified, use captions, metadata or still frames. State the limit: silent visual checks do not prove spoken-word accuracy or audio quality. Do not start sound through the user’s speakers unless explicitly asked.

## Write up the real run

For every actual attempt, [write its meta article](https://blitzmetrics.com/meta-article-prompt/) with this recipe and revision, trigger, steps performed, output evidence, measured result, gaps and next owner. Failed, blocked and partial attempts also get a written record. A draft can satisfy writing; publishing it follows the existing job scope.

Keep one stable execution ID across retries and edits. A separately scoped child task may have its own ID linked to its parent. Writing the parent’s meta record is part of that run, not an endless new chain. The [recipe and meta-article guide](https://localservicespotlight.com/meta-articles/) explains this distinction. Teaching examples are not real executions and must not enter the run count.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 2, gating 3 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- Canonical article: https://blitzmetrics.com/website-qa-audit
- Exact task: [Verify achievements are evidenced, not just claimed](https://local-service-spotlight.github.io/task-library/?task=verify-achievements-are-evidenced-not-just-claimed#task-verify-achievements-are-evidenced-not-just-claimed)
- Writing standard: [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Website QA Audit](https://blitzmetrics.com/website-qa-audit/)

## Review and evidence still needed

The source contributor status is preserved. It is not certification of this draft or proof of account access, completed work or a live outcome. The worked example teaches the method and is explicitly fictional.
- Actual primary evidence, exact quote permission, site-wide coverage and public change receipts require the project.