---
name: follow-entity-linking-decision-tree
description: "Help readers reach the right person, business or guide."
category: SEO & Content Architecture
stage: —
definitive_article: https://blitzmetrics.com/entity-linking/
status: complete
---

# Follow entity linking decision tree

Help readers reach the right person, business or guide. This task checks what each name means and where its link should go. Start with the draft and a list of the names and ideas it uses.

**The path:** Named subject → Identity and page-role check → Useful destination → In-context review

**Start when:** A draft or existing page needs its first useful named-person, company, tool and concept links checked.

## Inputs

- The exact current draft/source, actual named subjects and supporting evidence.
- [Inventory pages and their purpose](https://local-service-spotlight.github.io/task-library/?task=step-1-inventory-content-and-establish-gct-per-page#task-step-1-inventory-content-and-establish-gct-per-page) or the maintained guide directory, verified personal/company homes and current relationship scope.
- The [entity linking, choosing the right home for a named person or topic](https://blitzmetrics.com/entity-linking/) method and necessary direct source, sign-in, install or download destinations used by the task.

## Steps

1. Read the actual sentences and list the names and unfamiliar terms they contain. Record whether each item means a person, an organization, a method, a tool or a particular piece of evidence. Resolve ambiguous names before linking; a matching title in search is not identity proof.
2. Route a person to their verified personal home and an in-network business to its verified official site. Check that the page describes the same entity and current relationship. Do not use a look-alike name, obsolete affiliate destination or unrelated profile merely because it opens.
3. For a BlitzMetrics method, choose the maintained owned explanation. For an outside tool, concept or well-known entity in explanatory copy, use our current guide when one exists. If no relevant owned guide exists, leave the name plain and record the actual knowledge gap instead of linking to a weak substitute.
4. Keep direct primary evidence and required action links when the step needs that destination. Label a research source, account sign-in or download by its real purpose; these are different from the first explanation of the tool. Do not retarget a source citation or login button to our general article.
5. Explain unfamiliar language on its first useful body mention in plain words, linked to the owned guide. Keep headings short and meaningful; if the term first occurs in a heading, give its explanation in the next suitable prose. Do not expand every repeated mention or repeatedly link the same entity.
6. Use the actual name or a concise phrase that predicts the destination. Three to six descriptive words is the house preference where natural, not a requirement to pad a two-word person’s name. Read the surrounding sentence after the edit to ensure the meaning and claim remain true.
7. Open the targets and inspect the final body links, preserving existing media, IDs and source ownership. Record unresolved identity, missing-guide and inaccessible-source cases separately. Pass the exact link log and remaining decisions to the page owner; a link is not proof of an endorsement or completed task.

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

- [ ] Each destination matches the named entity and the sentence’s purpose.
- [ ] Owned explanations, primary proof and necessary action links retain their distinct jobs.
- [ ] First-mention explanations are clear and limited; headings, existing claims and actual names remain accurate.
- [ ] 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 article explains an app, cites that app’s official format specification and asks the reader to sign in. Its first explanation links to the site’s maintained app guide. The specification stays a clearly labeled primary citation, and the sign-in link stays the actual action destination. None of those three links is substituted for another.

## Handoff and Content Factory context

[Check the placed links](https://local-service-spotlight.github.io/task-library/?task=step-5-qa-links-against-google-guidelines#task-step-5-qa-links-against-google-guidelines) receives the checked links and unresolved cases. The content owner receives a specific missing-guide request only where no useful owned explanation exists.

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/entity-linking/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=follow-entity-linking-decision-tree#task-follow-entity-linking-decision-tree)
- [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

- [Google’s descriptive link guidance](https://developers.google.com/search/docs/crawling-indexing/links-crawlable)

## Review and evidence still needed

The inherited contributor status is `complete`. 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.