---
name: create-shared-location-for-sop-amendment-proposals
description: Good fixes get lost when they stay in chat.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Create shared location for task guide Amendment Proposals

Good fixes get lost when they stay in chat. This guide gives your team one place to propose a change and see its answer. Start by checking whether a shared queue already exists.

**The path:** Current queue → Format and roles → Test proposal → Tracking handoff

**Start when:** The approved process needs one findable proposal queue, or the existing one needs repair.

## Inputs

- The approved team workspace, current proposal locations and their owners.
- The [knowledge maintenance method](https://blitzmetrics.com/knowledge-system-maintenance/) proposal format: problem, affected guide, exact new wording and at least two real examples, within 500 words.
- Named submitters/reviewers and authority for any storage or access change.

## Steps

1. Find the maintained proposal home before creating one. The source allows a document, a WordPress draft or a project board; choose the approved tool that the intended users can reach.
2. Organize three clear areas: format/help, pending queue, resolved archive. Keep existing IDs, decisions and evidence links; do not merge histories without checking provenance.
3. Map roles to needed actions: submit, read, review and resolve. Grant only approved access and keep confidential client examples in authorized storage.
4. Seed the blank four-part format and one clearly labeled teaching example. A sample item uses a test ID and never counts as a real accepted amendment.
5. Have an intended submitter and reviewer perform a test handoff. Confirm they can find, read and resolve the sample with a reason. Use a test document for any simulated version/changelog update.
6. Link the canonical home from the maintained workflow under existing publishing authority. Prepare or send the exact notice only within the job’s communication scope.
7. Hand location, roles, test evidence and unresolved access to the tracking-system task.

## Definition of done (QA checklist)

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

- [ ] One identified home contains format, queue and archive without losing prior records.
- [ ] Approved roles are verified by a submitter/reviewer test.
- [ ] Sample records are labeled and excluded from production amendment metrics.

## Example(s)

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

A fictional team already has a proposal board but no format card. Add the format and a sample item there rather than making a second board. A reviewer can open the sample but cannot change its state; record that missing role and leave the round-trip test incomplete.

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

[Set up proposal tracking](https://local-service-spotlight.github.io/task-library/?task=set-up-sop-amendment-proposal-tracking-system#task-set-up-sop-amendment-proposal-tracking-system) adds the metadata and review schedule to this checked location.

## 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-shared-location-for-sop-amendment-proposals#task-create-shared-location-for-sop-amendment-proposals)
- [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.