---
name: schedule-and-assign-quarterly-auditors
description: A page can drift if no one owns its next check.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Schedule and assign quarterly auditors

A page can drift if no one owns its next check. This guide gives each page a reviewer and a real due date. Start with the current page list and people who can do the work.

**The path:** Current pages → Named reviewers → Agreed dates → Coverage check

**Start when:** A new quarterly audit window needs named reviewers and agreed page-level due dates.

## Inputs

- The maintained audit inventory, current register and prior unfinished checks.
- Reviewer availability, relevant source access and independent-review requirements.
- An agreed quarter, timezone and authority for assignments/calendar changes.

## Steps

1. Reconcile the article list from the current register and canonical index. Include existing gaps and page roles; the old guide’s teaching table is not the live inventory.
2. Assign one accountable reviewer per page, with needed specialist help. Balance actual scope and avoid an author being the only reviewer of their own changes.
3. Agree specific due dates and an audit window with those reviewers. Q3 2026 was the source’s first-cycle target; retain it as history rather than assigning an expired deadline to every new run.
4. Save assignments in the existing system. Include page URL, source revision, reviewer, due date/timezone, required checks and evidence location.
5. Create only authorized calendar reminders or jobs, check their saved details and confirm intended participants can see them. A saved event is not an accepted assignment or a completed audit.
6. At the midpoint and quarter close, compare planned checks with actual receipts. Carry misses with named owners and revised dates, keeping the old due date and reason.
7. Capture load or workflow problems from the real rotation and propose improvements. Do not erase missed audits by changing a status label.

## Definition of done (QA checklist)

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

- [ ] Every in-scope page has one accountable reviewer, clear scope and an agreed date.
- [ ] Saved assignments/reminders are verified; conflicts and access gaps remain visible.
- [ ] Coverage uses actual audit receipts, with unfinished checks carried forward honestly.

## Example(s)

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

A fictional quarter has 12 pages and two reviewers. One large guide is split into specialist checks but keeps one accountable reviewer. At close, 10 have complete receipts and 2 remain blocked on source access. Report 10/12 audited, not 12/12 because all were assigned.

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

Auditors begin with [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) and finish with [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). The coordinator owns missed-review follow-through.

## 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=schedule-and-assign-quarterly-auditors#task-schedule-and-assign-quarterly-auditors)
- [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 `gap`. 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.