---
name: check-topic-coherence-for-each-definitive-article
description: A page should help readers with one clear subject.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: complete
---

# Check topic coherence for each definitive article

A page should help readers with one clear subject. This guide finds text, links, and media that send them elsewhere. Start by saying what the page is for, then check each part against that purpose.

**The path:** Page purpose → Every element → Relevance decision → Fix list

**Start when:** An article audit begins and its declared purpose needs to be checked against the whole page.

## Inputs

- Exact page URL and source revision, declared role and reader need.
- [current article guide](https://blitzmetrics.com/definitive-article-guide/) and the [SEO Tree, the map of related pages](https://blitzmetrics.com/seo-tree/).
- The page outline, media/transcript sources, link list and audit-record location.

## Steps

1. State the page’s purpose and role from its real body and opening. A task recipe teaches a repeatable job; a hub explains a subject; a reference or story has another role. An unclear purpose is a finding to resolve.
2. Inventory every section, image, video, example and meaningful link. For each, record how it supports the purpose; use captions/transcripts or silent frames for media, without claiming a sound review.
3. Check examples for matching subject and method. A related person’s photo proves that moment, not their use of the method or a customer result.
4. Check headings for a competing topic and links for useful parent, prerequisite or supporting context. A related prerequisite link can belong without turning the whole page into that topic.
5. Classify each item keep, clarify, move, remove or not verified. Give the exact location and reason. Preserve source evidence and prior history before proposing a move.
6. Apply authorized small corrections through the owning editor/source. For structural moves, prepare destination and cross-link changes together so useful material is not lost.
7. Save the checked inventory and open issues. Capture reusable lessons within 24 hours; a ticketed defect remains unresolved on the page until a fix is verified.

## Definition of done (QA checklist)

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

- [ ] The page’s purpose and role are explicit; all elements have dispositions.
- [ ] Every proposed removal or move has a relevance reason and preservation plan.
- [ ] Open defects remain visible with owners; tickets are not counted as repaired pages.

## Example(s)

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

A fictional bike-repair guide includes a video about a roofing company. The video has no lesson about bike repair, so the audit proposes moving it to its true topic. A link to the shop’s booking page stays because it is the reader’s next step. The move is not marked done until both pages are checked.

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

[Check the current article structure](https://local-service-spotlight.github.io/task-library/?task=verify-structural-completeness-against-8-step-framework#task-verify-structural-completeness-against-8-step-framework) uses this relevance review; [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 findings after all four audit checks.

## 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=check-topic-coherence-for-each-definitive-article#task-check-topic-coherence-for-each-definitive-article)
- [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 `complete`. 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.