---
name: apply-portability-discipline-to-meta-articles
description: A good run note helps the next person use what you learned.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: needs-work
---

# Apply portability discipline to meta-articles

A good run note helps the next person use what you learned. This guide keeps the lesson clear and saves the exact steps as proof. Start with one real run and its source files.

**The path:** Run evidence → Method → Tool details → Checked record

**Start when:** You are writing or reviewing a real run record whose reusable method is mixed with its tool details.

## Inputs

- The in-scope run records, their execution IDs, source revisions and evidence.
- [meta article, the record of one run](https://blitzmetrics.com/meta-article-prompt/) and the two-layer [knowledge maintenance method](https://blitzmetrics.com/knowledge-system-maintenance/).
- Editing authority and the record’s current private, draft or public state.

## Steps

1. List each record in scope and its actual outcome. Keep the same execution ID when improving the wording; a rewrite is not a new run.
2. Extract the decisions and reasons another operator can reuse. Label this the approach. Avoid turning one result into a universal promise.
3. Keep exact tool names, versions, commands, dates and failures in a separate “How this run worked” passage. Link retained private proof safely; do not expose credentials or replace a failed attempt with a successful teaching story.
4. Test the approach with the tools hidden in a review copy. A reader should see the inputs, decisions, checks and handoff; this does not prove a different platform has the required features.
5. Recheck each factual sentence against the original evidence, then save through the record’s existing editing route. Keep old evidence links and outcome states.
6. Check whether the current meta prompt already asks for this separation. If not, propose the exact missing instruction 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). Record the reviewed IDs and changed revisions.

## Definition of done (QA checklist)

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

- [ ] Approach and actual implementation are clearly separated.
- [ ] Dates, tools, failure evidence and same execution identity are retained.
- [ ] A reader can state the method without assuming another app works; saved copy matches the review.

## Example(s)

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

A fictional run corrected a transcript in Tool A but failed to upload it. The approach says to check spoken claims against the recording. The run details retain Tool A’s version and the failed upload. The improved record still says upload blocked; changing its headings does not make the run successful.

## Handoff and Content Factory context

The [Content Factory, our four stages of using real content](https://blitzmetrics.com/content-factory/) runs through Produce → Process → Post → Promote. This review improves a run record in Process; any public release belongs to Post and follows its existing authority. The record can describe work from any stage.

The record owner keeps the checked revision. Process improvements go to [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); future authors use the maintained meta prompt.

## 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=apply-portability-discipline-to-meta-articles#task-apply-portability-discipline-to-meta-articles)
- [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.