---
name: maintain-canonical-honor-and-story-leaves
description: "Keep one useful page about a real working bond. Link each true story to that page."
category: Content Factory — Process
stage: Post
definitive_article: https://blitzmetrics.com/one-canonical-honor/
status: needs-work
---

# Maintain a canonical honor and story leaves

You may have a few stories about someone you work with. This guide helps you give them one clear home. Start with the real source and the pages you have.

**The path:** Real shared work → One helpful hub → Distinct story leaves → Checked links both ways.

**Use this when:** New material about a real relationship should improve an existing or justified main honor page and its specific story pages.

## Inputs
- Verified relationship evidence, intended [Goals, Content, and Targeting](https://blitzmetrics.com/gct-business-strategy/) and public/private limits.
- Original recordings/transcripts/photos, media permissions and known identity home.
- An inventory of the existing honor hub, people-directory card and story leaves, with current source revisions.
- Approved site/channel edit scope, source owners and actual next recipient.

## First-run prompt

> Use the real relationship evidence and existing page inventory to improve one canonical honor hub and its distinct stories. Name actual themes, preserve rich URLs, add useful links both ways and verify media/identity. Keep private relationship data out of public copy. Complete only the already-authorized site/distribution actions and record true public or pending states.

## Steps
1. List the existing pages about the relationship and what each does. A people-directory card is not the full honor, and a short person-slug stub does not earn the main role by its URL alone.
2. Choose one helpful canonical relationship page on the relevant site. If it is thin, improve it from real shared work and sources before making claims about its authority. Do not create a competing biography to handle every new recording.
3. Name the real themes or limbs under that hub. Place each distinct tape/story under an appropriate theme. If no theme fits, record the content-placement decision rather than forcing an unrelated story onto the site.
4. Process each useful tape into its own source-faithful story with quotes checked against the transcript. Keep the real scene and lesson; the derivative story is not a second main relationship essay.
5. On each leaf, put the verified source player or meaningful visual early, with the named theme and link to the main hub visible in the first screen. Use the maintained caption/no-autoplay policy and no guessed or known-dead video IDs.
6. Update the hub with a useful summary and inbound link to each leaf under the correct theme. Link the person’s verified entity home. Keep relationship terms proportional to evidence and do not publish private contact data or invented introduction paths.
7. Preserve rich story URLs. Only a true duplicate honor might justify a scoped redirect; do not send a rich story into a thin stub or assume every similar slug should redirect. Verify any authorized redirect’s final target.
8. Save each change through its supported source and check normal canonical desktop/phone views. Reconcile the actual inventory: one hub, named themes, leaf-to-hub and hub-to-leaf links, source IDs and any pending external-site edit.
9. Use only the distribution destinations in the existing plan. Another person’s site or audience is not ours to edit from a relationship claim. If an intake monitor is requested, use a real watermark, duplicate check, quiet no-change path and named first-firing owner; do not install one for every honor page.
10. Write the run’s meta with the actual changed pages, proof and remaining work. Hand the useful public pages or staged changes to the next owner, with promotion reserved for the separate evidence-based scope.

## Definition of done (QA checklist)

- [ ] There is one useful relationship hub and distinct preserved stories, not competing masters.
- [ ] Each leaf names its theme and links the hub early; the hub links the real leaf and entity home.
- [ ] Evidence, media IDs, privacy and relationship wording are verified.
- [ ] The actual save/public state and inventory reconcile; no unasked redirects, outreach or scheduler are inferred.

## Example(s)

**Fictional teaching example — no real relationship or site edit.** A sample business owner has one page about working with a local mechanic and two stories: a shop visit and a photo-checklist lesson. The main page describes the actual shared work. The visit story remains about that visit; it links up under “Shop visits.” The checklist story links up under “Customer education.”

The hub links both leaves and the mechanic’s verified business home. It does not call the mechanic a partner or friend unless the real evidence supports that wording. No rich story is redirected into the hub merely to reduce the URL count.

## Handoff and Content Factory context

This record is cataloged in Process but its preserved reviewed stage is **Post**: the outcome places and links the honor pages. The site owner receives the inventory and checked URLs. [Notify the featured person](https://local-service-spotlight.github.io/task-library/?task=email-and-dm-client-about-published-article#task-email-and-dm-client-about-published-article) follows only after publication and within the existing message scope.

Produce supplies the real shared-work source. Process develops the story. **Post is this record’s reviewed stage**, even though the legacy catalog category is Process: it places the leaf and updates the hub. Promote follows only within the separate approved plan. Keep the actual source and handoff links above rather than treating catalog neighbors as dependencies.

## When this runs

For new relevant source material or a scoped repair to the honor tree. Optional phone/source intake needs its own real configured cadence; no universal daily scan is created.

## 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:** Post
- **Importance:** 4/5 `●●●●○` — frequency 4, revenue 3, gating 2 (runs every factory cycle or weekly)
- **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:** Draft URL or WP post ID, slug, author user ID, featured-image media ID. Promote reads the live URL, not the draft.

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

- Canonical article: https://blitzmetrics.com/one-canonical-honor/
- Exact task: [Maintain a canonical honor and story leaves](https://local-service-spotlight.github.io/task-library/?task=maintain-canonical-honor-and-story-leaves#task-maintain-canonical-honor-and-story-leaves)
- Writing standard: [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Entity linking: choose the right person, company or guide](https://blitzmetrics.com/entity-linking/)
- [SEO Tree: give a page its right topic home](https://blitzmetrics.com/seo-tree/)
- [Our YouTube caption-default method](https://blitzmetrics.com/youtube-captions-on-by-default/)

## 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.
- Real relationship/rights, exact hub/theme placement, current page edits and any external recipient authority need project evidence.