---
name: create-sop-amendment-proposal-500-words
description: If a guide keeps causing trouble, write down the fix.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: complete
---

# Create task guide Amendment Proposal (≤500 words)

If a guide keeps causing trouble, write down the fix. This guide helps you show the problem, proof, and exact new words. Start with the current guide and two real examples.

**The path:** Two real examples → Exact change → 500-word check → Review queue

**Start when:** Two real cases show a repeatable method defect that needs a formal proposed correction.

## Inputs

- The affected [standard operating procedure, or task guide](https://blitzmetrics.com/how-to-document-a-task/) and its current revision.
- At least two source-backed cases showing the problem, plus the shared proposal location.
- The applicable change authority and a named reviewer.

## Steps

1. Check whether the current guide already covers the issue or has changed since the examples. Identify the exact faulty or missing step; a stale local copy may need updating instead.
2. Draft four parts: problem; affected guide and section; exact added/replacement wording; at least two real examples with dates and sources. If only one exists, capture that lesson and mark the evidence gap. Do not wait for a second harm when an urgent correction is already authorized through the proper route.
3. Write one coherent change in the guide’s voice. Separate the method from product controls, and describe the expected result and failure behavior.
4. Count the whole proposal body against the 500-word maximum. Trim background before evidence or exact wording. Split unrelated guide changes into linked proposals.
5. Compare the proposed text with adjacent steps and current shared rules. Confirm the examples support the claimed defect rather than merely mentioning the subject.
6. Save the proposal and its source revision in the shared location, then read it back. Queue it for review; a proposal saved is not a live procedure change.

## Definition of done (QA checklist)

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

- [ ] Four parts, exact affected revision and two real examples are present, or the proposal remains evidence-incomplete.
- [ ] The body has 500 words or fewer and one coherent proposed change.
- [ ] Saved proposal is readable and ready for the named reviewer; live state is reported separately.

## Example(s)

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

A fictional proposal has: Problem—two reports used the wrong week. Guide—weekly reporting, date check. Wording—“Compare export start/end dates with the report title before computing totals.” Evidence—two labeled sample report/export pairs. This teaches the four-part form; real use requires actual records, not the invented reports.

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

[Tag and queue the proposal](https://local-service-spotlight.github.io/task-library/?task=tag-proposal-with-affected-sop-and-queue-for-review#task-tag-proposal-with-affected-sop-and-queue-for-review) receives the saved proposal. One-off lessons without the evidence for a proposal go through [Capture a lesson within 24 hours](https://local-service-spotlight.github.io/task-library/?task=generate-knowledge-capture-note-within-24-hours#task-generate-knowledge-capture-note-within-24-hours).

## 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=create-sop-amendment-proposal-500-words#task-create-sop-amendment-proposal-500-words)
- [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.