---
name: establish-entity-identity
description: "Make it clear which person a page is about."
category: Personal Branding
stage: —
definitive_article: /knowledge-panel
status: needs-work
---

# Establish entity identity

Make it clear which person a page is about. This guide checks your name, site and key facts so people can tell you apart from someone else. Start with your own site and the profiles you know are yours.

**The path:** Known person → Profile inventory → Fact and identity checks → Corrected source map

**Start when:** An identity audit or panel project needs one verified record of the person and known naming conflicts.

## Inputs

- [Align photos and bio facts](https://local-service-spotlight.github.io/task-library/?task=add-consistent-headshots-and-bios-across-profiles#task-add-consistent-headshots-and-bios-across-profiles) with the approved name, real photo and current role facts.
- The person’s home site, known profiles, outside sources and current structured markup.
- Actual edit rights and a defined research scope; prior collisions and rejected identity matches.

## Steps

1. Create or update the existing identity record. Include the accepted professional name, valid alternate names, home URL, role and organization with source evidence. A person may have legitimate historic names and photos; consistency means resolving facts, not deleting their history.
2. Inventory the in-scope owned and outside pages. Record URL, source type, name used, current role, image, website target and evidence date. Search known variants and useful languages; record coverage limits rather than claiming to find every page on the web.
3. Resolve each page to this person using its actual role, organization, context and sources. A matching name, a search snippet or a photo with another person is insufficient. Keep wrong-person and uncertain matches excluded from accepted identity links.
4. Compare current owned fields with the approved record. Prepare corrections for factual drift and broken links. Preserve valid older credits with their dates. Retiring profiles, redirecting URLs or changing another publisher’s page requires its actual owner and existing authority.
5. Inspect the live website’s Person markup, meaning structured facts identifying the person. Reuse one stable identity ID for that person across relevant blocks. Person and business remain separate entities; do not merge the person with a company profile simply because they own it.
6. After authorized corrections, reopen affected pages and check saved facts and destinations. Pass verified identity pages to [Add verified Person markup](https://local-service-spotlight.github.io/task-library/?task=implement-person-schema-with-sameas-links#task-implement-person-schema-with-sameas-links). An inaccessible source stays unresolved until a supported inspection proves its identity; a response code alone is insufficient.
7. Save accepted aliases, rejected matches, checked sources and next actions. Review when a role, domain or profile changes. Any quarterly schedule needs its real owner and observed configuration; clean identity evidence does not guarantee a [Knowledge Panel, Google’s information box for an entity](https://blitzmetrics.com/knowledge-panel/).

## 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/).

- [ ] Accepted pages unambiguously describe the intended person; aliases and collisions remain documented.
- [ ] Corrected owned facts are read back and outside corrections have their actual state.
- [ ] The identity map distinguishes Person and company and supplies verified sources to schema work.
- [ ] 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 designer shares her name with an actor. A podcast page names her design firm, while a film page belongs to the actor. The team accepts the podcast profile and excludes the film page. An old employer bio stays as dated career history, with only its broken current-site link proposed for repair.

## Handoff and Content Factory context

[Check outside proof](https://local-service-spotlight.github.io/task-library/?task=build-third-party-validation#task-build-third-party-validation) receives the resolved identity; [Maintain the identity graph](https://local-service-spotlight.github.io/task-library/?task=implement-technical-schema-markup#task-implement-technical-schema-markup) receives accepted URLs and fact changes.

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:** `judgment` — Frontier judgment: honest scoring, entity disambiguation, the subject's voice. Claude, ChatGPT, or Grok — pick the one you have.
- **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=establish-entity-identity#task-establish-entity-identity)
- [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/)

## 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.