---
name: build-third-party-validation
description: "Help people check your work with proof from other sources."
category: Personal Branding
stage: —
definitive_article: /knowledge-panel
status: needs-work
---

# Build third-party validation

Help people check your work with proof from other sources. This guide sorts press, talks and interviews into a clear record. Start with the real links you already have, then find what each one shows.

**The path:** Existing coverage → Identity and source checks → Proof inventory → Public use proposal

**Start when:** Identity facts are established and the team needs a checked inventory of outside evidence and gaps.

## Inputs

- [Check the person’s identity](https://local-service-spotlight.github.io/task-library/?task=establish-entity-identity#task-establish-entity-identity) with the accepted name, role, home site and known collisions.
- Existing press, podcast, talk, book and directory records, plus their source URLs, dates and use permissions.
- The actual claim to support and approved research scope; [Collect and classify positive mentions](https://local-service-spotlight.github.io/task-library/?task=positive-mentions-harvester#task-positive-mentions-harvester) classification rules.

## Steps

1. Read the current proof inventory and append there. Record the source title, URL, date, author, named subject, exact supported fact and whether the material is independent, self-published, paid or a simple appearance. Avoid counting syndicated copies as independent coverage.
2. Search the accepted names, useful variants and the languages in which the person has lived and worked. Inspect the primary page or supplied source, not just a search summary. Record sources or languages that remain inaccessible so a thin search is not labeled a thin career.
3. Resolve same-name people with role, organization, location and the source’s actual context. Keep the narrowest true claim: a speaker listing proves a scheduled role; a recorded delivered talk proves participation; praise requires actual attributable positive language.
4. Build the gap list around the reader’s needed proof. Use the podcast, speaking and press tasks to propose suitable opportunities. A missing type of proof is not permission to purchase a placement or manufacture a book credit.
5. Consider Wikidata only after checking its current notability rules, existing items, reliable references and identity fit. Wikipedia has separate notability and conflict-of-interest rules. Document the route and disclose relevant interests; neither platform is a compulsory branding checkbox or a guaranteed Google panel source.
6. Select the strongest relevant public-safe proof for the site with a short account of what it establishes. Keep permissions and private locators in the governed record. Pass only true identity pages to the schema task; an ordinary press story is a citation, not automatically a sameAs identity.
7. Save the covered scope, accepted and held records, changed facts and next owner. A bounded inventory pass can finish with honest gaps; new placements, a growing quarterly count or a Knowledge Panel are separate outcomes.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] Every accepted item identifies the right subject and the exact fact its source supports.
- [ ] Independent coverage, appearances, praise and duplicates are classified separately.
- [ ] The source-backed inventory and gap plan are saved; no new public placement or panel is invented.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional trainer has two interviews and a shared event photo. One interview contains a named client’s praise; the other is a neutral Q&A. The photo shows attendance only. The inventory keeps those three meanings separate and proposes a topic-specific speaking pitch, without presenting all three items as endorsements.

## Handoff and Content Factory context

[Review identity markup](https://local-service-spotlight.github.io/task-library/?task=implement-technical-schema-markup#task-implement-technical-schema-markup) receives verified identity pages. The site owner receives approved proof cards; press and podcast tasks receive scoped gaps.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.


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

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

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 2 (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

- [Maintained source guide](https://blitzmetrics.com/knowledge-panel/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=build-third-party-validation#task-build-third-party-validation)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

### Primary method references

- [Wikidata notability](https://www.wikidata.org/wiki/Wikidata:Notability)
- [Wikipedia conflict of interest](https://en.wikipedia.org/wiki/Wikipedia:Conflict_of_interest)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.