---
name: set-up-consistent-headshots-and-bios-across-profiles
description: "Use the right photo and true story on each profile. Keep a clear source for future edits."
category: Digital Plumbing
stage: —
definitive_article: GAP — to be written
status: needs-work
---

# Set Up Consistent Headshots and Bios Across Profiles

Do your profiles tell the same true story? This guide helps you keep the facts and photos clear. Start with a real photo and a short story you can prove.

**The path:** Verified identity → Approved assets → Profile variants → Public proof.

**Use this when:** a person or business changes its public positioning or finds stale, conflicting or inappropriate profile assets.

## Inputs
- The correct person or business identity, current approved real image, rights and source-based identity confirmation. Do not identify people by comparing faces.
- A canonical factual bio with supported claims and short/long variants suited to the actual audiences.
- The in-scope profile list, field limits and usable editing access. Separate personal profiles from company Pages and service-area business listings.

## First-run prompt

> Update the supplied profile set from its approved image and factual bio. Adapt length and voice to the actual person, business and platform without inventing claims. Record public read-backs and legitimate differences. Preserve evidence HOLDs and private data.

## Steps
1. Separate the person, business and location profiles. Decide which asset each should use: a personal headshot may fit the individual while the company uses its logo. An identical face on every surface is not the definition of correct identity.
2. Confirm the image from an approved source record and publication rights. Use a current real image for the role. Do not infer who someone is from facial appearance, and do not replace missing proof with a generated portrait.
3. Write the factual core: who the person or business helps, what it does and a supported proof point when available. Apply the maintained credibility rules: show a real moment rather than a trophy-name paragraph, and make relationship language no stronger than its evidence.
4. Create short and long variants without changing the underlying story. First person fits the individual’s own narrative; company “we,” a formal third-person bio or a clearly attributed quote may be appropriate. Do not force identical first lines or claim language across unlike entities.
5. Keep anonymous, domain-only or unverified praise on HOLD until evidence and permission meet the rule. Do not turn co-appearance into friendship, mentorship or endorsement. Derivative and repurposing work inherits the same evidence limits.
6. Store the approved source image and text versions in the project’s content library, then update each scoped profile through its supported source. Match actual crop and field limits; do not expose a private contact address to fill an optional public field.
7. Read back the public profiles and check intended asset, name and factual meaning. Document necessary differences and pending review states. An internal verification process or confidence label does not belong in public bio copy; keep a needed compliance disclosure when applicable.
8. Save the profile-by-profile change record, asset version and next owner. A missing account does not justify claiming every profile is updated. Route the exact remaining surface instead of asking for every login again.

## Definition of done (QA checklist)

- [ ] Each profile uses the right person/business identity and an approved sourced asset.
- [ ] Bio variants preserve verified facts, appropriate voice and limited relationship claims.
- [ ] HOLD evidence remains held across all derivatives; no fictional proof enters real copy.
- [ ] Public crops, fields and website links are checked for the declared profile set.
- [ ] The source library and unresolved profile owners are recorded without private contact or internal verification leakage.

## Example(s)

**Fictional teaching example.** Lee Hart’s personal profile says “I help local owners explain roof repairs.” Oak Repair’s company Page says “We repair roofs for local homeowners.” The profile uses Lee’s approved headshot; the Page uses the company mark. Both tell a consistent factual story without pretending they are the same entity. A draft claim that Lee is a famous speaker’s mentor remains HOLD because the only evidence is an event appearance.

## Handoff and Content Factory context

Give the approved asset and bio variants to the profile owners. Use [ensure nap consistency across platforms](https://local-service-spotlight.github.io/task-library/?task=ensure-nap-consistency-across-platforms#task-ensure-nap-consistency-across-platforms) for business contact facts or [add schema markup person localbusiness](https://local-service-spotlight.github.io/task-library/?task=add-schema-markup-person-localbusiness#task-add-schema-markup-person-localbusiness) for matching machine-readable identities.

This setup supports 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 when the approved image, role or positioning changes. A periodic stale-profile review can be configured separately; the model does not automatically retain or publish the latest canon.

## 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:** Gate
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, 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:** Record only the property IDs, access and checks required by this task in the client register. Pass the verified result to the task that needs it.

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

- Dedicated canonical article: not mapped in this source record. Use the maintained owned training below until that article gap is reviewed.
- Exact task: [Set Up Consistent Headshots and Bios Across Profiles](https://local-service-spotlight.github.io/task-library/?task=set-up-consistent-headshots-and-bios-across-profiles#task-set-up-consistent-headshots-and-bios-across-profiles)
- Writing standard: [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Digital Plumbing training](https://blitzmetrics.com/digital-plumbing/)
- [Entity linking](https://blitzmetrics.com/entity-linking/)
- [Schema.org sameAs](https://schema.org/sameAs)

## 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.
- The dedicated article is unmapped. Actual source identity, media rights, claim proof and profile access must be supplied.