---
name: verify-social-proof-photos-present
description: "Show the real source behind a proof section. Keep photos and claims tied to what actually happened."
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify social proof photos present

A proof section should show something real that readers can check. This guide helps you match each claim with an honest visual and source. Start with the actual record, not a picture chosen just to fill space.

**The path:** Claim and scene → Real visual source → Accurate caption → Publication gate.

**Use this when:** A site’s testimonial, results, event, review or press sections need their visual evidence and public captions reviewed.

## Inputs
- All scoped proof placements, including slides, result cards, press logos and review embeds.
- Original approved photos, exact primary quotes, review/metric sources and permitted visual captures.
- The maintained credibility/attribution standard, supported edit scope and the actual content owner.
- An internal proof record separate from client-facing/public copy.

## First-run prompt

> Review the supplied proof blocks, real assets and primary evidence. Match visual scope, exact quotes and relationship wording, complete authorized truthful changes, and retain HOLD for missing evidence. Keep private scoring/repurposing metadata out of public copy while preserving necessary compliance disclosure.

## Steps
1. Inventory every scoped proof block and state the exact claim it makes. A source-backed text quote can be evidence, but the owned page standard also requires a meaningful real visual for the proof section; these are separate checks.
2. Find the actual relevant photo or artifact: a permitted reviewer portrait, real job scene, primary-review capture or correctly scoped results screenshot. A stock face, unrelated logo or synthetic event image cannot stand in for missing evidence.
3. Trace the asset to its source and rights. Reverse-image results can provide leads, not prove identity or authenticity. Do not upload private source images to a third party without authority, and do not guess a person’s identity from their face.
4. Match the image, caption and claim. A results capture needs the right metric and period; an event photo supports the depicted moment, not an automatic friend, partner, client or mentor relationship. Stronger unsupported relationship wording stays HOLD.
5. Write a compact source-supported scene and useful lesson, with the relevant identity/date/source when known. Reject a trophy-name wall or name-dropping caption that substitutes familiar people and brands for an actual shared moment.
6. Check attached praise against the exact named person’s source quote and applicable attribution/permission. A logo, domain, initials or “happy customer” is not a named speaker. Incomplete praise remains HOLD for publication and repurposing.
7. Keep internal scores, proof IDs, inventory/harvester labels, repurposing instructions and repeated “this does not prove” caveats out of unrelated public copy. Preserve a materially necessary legal, regulatory, or compliance disclosure scoped to the triggering claim.
8. Apply authorized accurate visual/caption changes or remove held public proof within scope. Recheck canonical desktop/phone readability and source links. Save the internal evidence table and missing-source requests without publishing its confidence/status fields.

## Definition of done (QA checklist)

- [ ] Every scoped proof section has a relevant real visual plus sufficient underlying claim evidence.
- [ ] Photo provenance, factual scope and rights are established or explicitly unresolved.
- [ ] Captions show a real scene and lesson without trophy-name or inflated relationship claims.
- [ ] Quotes are exact and fully attributed; incomplete proof remains HOLD across repurposing.
- [ ] Public copy avoids internal review theater and preserves necessary scoped compliance disclosure.

## Example(s)

**Fictional teaching example — no proof block was changed.** A sample photo shows Alex explaining a repair checklist at a workshop. The draft caption says “My trusted partner endorses my system.” The source record supports only that workshop scene.

The teaching caption describes the real demonstration and its useful lesson, then links the actual source when one exists. The partnership/endorsement claim remains HOLD. Adding “This is not proof of endorsement” would leave the wrong framing in place; the better fix is to use the accurate scene.

An attached quote signed only “maplecycle.example” still needs a named speaker and its exact source before becoming a testimonial.

## Handoff and Content Factory context

The content owner receives accurate visual/caption changes and held proof requests. [Check testimonial headshots](https://local-service-spotlight.github.io/task-library/?task=verify-testimonials-include-headshots-with-attribution#task-verify-testimonials-include-headshots-with-attribution) and [Check full attribution](https://local-service-spotlight.github.io/task-library/?task=verify-testimonials-with-full-attribution#task-verify-testimonials-with-full-attribution) apply to actual praise blocks.

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 proof is published or repurposed and when sources, captions or visual placements change. Stored prior verdicts need source/version comparison; no automatic perpetual 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 social proof photos present](https://local-service-spotlight.github.io/task-library/?task=verify-social-proof-photos-present#task-verify-social-proof-photos-present)
- 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 proof, asset rights, complete quote attribution and canonical visual evidence require the site.