---
name: audit-this-maintenance-article-every-6-months
description: Rules can get old too.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Audit this maintenance article every 6 months

Rules can get old too. This guide checks whether your team’s guide system still helps people do good work. Start with the last six months of records and look for what worked, failed, or was never checked.

**The path:** Six-month evidence → Five processes → Decisions → Next review

**Start when:** The agreed six-month system review is due, with actual records for a declared period.

## Inputs

- The current maintenance article and revision history, with an agreed review period.
- Audit receipts, proposal records, capture notes and portability results for that period.
- [The proposal-pattern review](https://local-service-spotlight.github.io/task-library/?task=review-past-6-months-of-sop-amendment-proposals-for-patterns#task-review-past-6-months-of-sop-amendment-proposals-for-patterns) and named review/approval owners.

## Steps

1. Record the period and source coverage. If six months of records do not exist, state the actual window and missing evidence; do not backfill fictional history.
2. Run [Check whether the page stays on topic](https://local-service-spotlight.github.io/task-library/?task=check-topic-coherence-for-each-definitive-article#task-check-topic-coherence-for-each-definitive-article), [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), [Check facts against current sources](https://local-service-spotlight.github.io/task-library/?task=check-information-currency-with-latest-data#task-check-information-currency-with-latest-data) and [Check links and their meaning](https://local-service-spotlight.github.io/task-library/?task=validate-cross-reference-integrity-across-articles#task-validate-cross-reference-integrity-across-articles) against the maintenance article itself. Apply current article requirements to its hub and task sections.
3. Assess all five processes: quarterly audits, proposal review, lesson capture, method/tool separation and this recursive review. Compare planned events to actual receipts, delays, outputs and unresolved gaps.
4. Give each process a reasoned disposition: keep, propose a change, propose retirement, or evidence insufficient. Missing records do not prove success or justify removal.
5. Use repeated problems to propose a missing process only when evidence supports it. Draft exact changes through [Draft a process-change proposal](https://local-service-spotlight.github.io/task-library/?task=create-sop-amendment-proposal-500-words#task-create-sop-amendment-proposal-500-words) and retain review decisions; do not silently change the rules being used to judge the system.
6. Apply approved changes through the owning sources and reconcile affected Task Library guides. Record the audit result and changed revisions in the current register.
7. Name the next review owner and agreed six-month date. Verify any saved calendar/job separately; keep completion of that later review unclaimed.

## Definition of done (QA checklist)

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

- [ ] Four article checks and all five process assessments have evidence or explicit gaps.
- [ ] Every proposed change has scope, reason and owner; approved releases have readback.
- [ ] Current audit record and next review handoff are saved without invented dates or runs.

## Example(s)

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

A fictional six-month review finds two of two planned article audits, six capture notes, and no proposal export. Keep the audit method based on its receipts; mark proposal review unverified and ask the queue owner for the missing export. “No export” is not “no proposals” or a reason to remove the process.

## 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) records the result. The named maintenance owner handles approved changes and [the next review setup](https://local-service-spotlight.github.io/task-library/?task=schedule-first-6-month-recursive-review#task-schedule-first-6-month-recursive-review) if no cycle exists.

## 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=audit-this-maintenance-article-every-6-months#task-audit-this-maintenance-article-every-6-months)
- [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.