---
name: validate-cross-reference-integrity-across-articles
description: A link should take people to the help its words promise.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Validate cross-reference integrity across articles

A link should take people to the help its words promise. This guide checks both ends of each link around one page. Start with the page and a list of the pages that point to it.

**The path:** Reference list → Read both pages → Scoped fixes → Check again

**Start when:** An audit needs to check whether the links around a page still describe their targets accurately.

## Inputs

- The audited article’s current URL, known aliases, role and source revision.
- A scoped site export or internal-link report, with its coverage and collection time.
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/) and the owned [SEO Tree, how related pages link to their main topic](https://blitzmetrics.com/seo-tree/) for topic relationships.

## Steps

1. Build the inbound list from the available site export or link report, checking known aliases and title mentions. Search can find more candidates, but it cannot prove a complete inventory; record the covered sites, dates and any inaccessible sources.
2. Read each inbound anchor with its surrounding sentence and then read its current destination. Check whether the destination really teaches the promised task or concept and whether any cited section still exists.
3. Mark wrong subject links, removed fragments, misleading descriptions and redirects to the wrong page. A successful page load proves reachability only, not that the linked claim is true.
4. Use concise descriptive anchors that fit the sentence. Link owned topic or task explainers for those concepts; retain an external primary source when it supports a provider-specific fact. Never retarget an external documentation link solely because an internal page mentions the same product.
5. Reverse the process for outbound links, including related task and topic links. A task recipe, an entity hub, a comparison and a story have distinct purposes; do not relabel one just to fill a required link slot.
6. Prepare exact source edits for inaccurate references and preserve all unrelated content/media. Release only through the owning source and existing authority; otherwise hand the owner the precise sentence, destination and reason.
7. Reopen the changed links and read the rendered sentence at both ends. Record unresolved items and recurring patterns; propose a source-workflow fix when repeated renames or edits leave references stale.

## Definition of done (QA checklist)

[Quality assurance (QA)](https://localservicespotlight.com/article-guidelines/) means checking the work against the agreed result.

- [ ] The reference inventory states actual coverage; every listed link has a semantic result.
- [ ] Wrong destinations and descriptions have a verified repair or an exact owner handoff.
- [ ] Readback covers changed anchors and targets; reachability is not substituted for meaning.

## Example(s)

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

A fictional article links “how to set up your library” to a story about one team’s library. The story loads, but it does not teach setup. Change the link only after locating and reading the actual setup guide. A separate vendor link for a supported file limit stays as primary evidence; the owned guide does not establish that limit.

## Handoff and Content Factory context

This work supports the [Content Factory, our four stages of using real content](https://blitzmetrics.com/content-factory/): Produce → Process → Post → Promote. Use the specific inputs and next task below to place the work; a maintenance task does not manufacture transcripts, clips or other stage outputs it does not call for.

[Record the audit result](https://local-service-spotlight.github.io/task-library/?task=update-status-table-in-definitive-article-guide#task-update-status-table-in-definitive-article-guide) receives the link findings and coverage limits. Article owners receive exact unresolved source changes.

## Run with an agent

Give the AI worker this recipe, the real Inputs above, the intended result and the actions already authorized. Ask it to return the saved output, checks, evidence and remaining owner. Check its work against this guide; loading a skill does not prove access, installation of a job, or successful execution. Keep media muted with volume at zero if playback is needed.

For recurring work, keep the actual trigger, owner and runtime in the job record. Scheduling and observed firings are separate. Do not create a schedule merely because this guide mentions a review interval.

## Record the real execution

Open the run record when the work starts. Keep the exact starting recipe revision, one execution ID, source evidence and actual state. Write a [meta article, the record of one run](https://blitzmetrics.com/meta-article-prompt/) with decisions, results, checks, failures and next owner. Link it to this task and register it through the [Task Library](https://local-service-spotlight.github.io/task-library/) execution process. Writing is part of the work; public release follows existing authority.

Reuse the same execution ID for revisions, QA, meta writing and retries within that run. A blocked run stays open with its dependency and next owner; do not invent a finish time. Use supported findings to propose and verify a better recipe. A historical public-example count without distinct run IDs remains dated article volume, not verified execution frequency.


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

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

- **Phase:** —
- **Importance:** 2/5 `●●○○○` — frequency 2, revenue 1, 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-system-maintenance/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=validate-cross-reference-integrity-across-articles#task-validate-cross-reference-integrity-across-articles)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [current article guide](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records work 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 verify document readiness, a client outcome, access or an executed task.

A real execution still needs its own source, reviewer, saved result and handoff evidence. The fictional example teaches the method; a real example with relevant proof is still needed where required. The task-specific flow above is source guidance; its visible presentation and the full document need a named reviewer and desktop/mobile checks.