---
name: run-content-factory-on-any-engine
description: "Use the tools you have to turn real work into content people can trust."
category: Strategy & Measurement
stage: —
definitive_article: /content-factory
status: complete
---

# Run the Content Factory with your available tools

Use the tools you have to turn real work into content people can trust. This guide shows the steps and the files each person or tool needs next. Start with one real source and the result you want to make.

**The path:** Produce → Process → Post → Promote → Learn from results

**Start when:** One recording or source set needs a coordinated Content Factory plan using the operator’s actual tools.

## Inputs

- One real recording or source set, use rights, goal, audience and owned page map.
- [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/) current method and the relevant task recipes.
- Actual supported tools, file access, verified release gates, named owners and the allowed scope for each stage.

## Steps

1. Write the specific goal and outputs first. Confirm the accepted business scope and which actions are authorized. Source drafting can proceed where allowed; current engine plumbing gates apply before shipping or amplification.
2. Produce gathers real source material. Verify the original file, speaker, date, permission and tracker entry. An AI worker can plan and inspect supported sources, but it does not become the person who performed the work.
3. Process turns the source into the selected useful outputs: transcript where needed, [Goals, Content, Targeting: the result, proof and people for this work](https://blitzmetrics.com/gct-business-strategy/) brief, article, clips or creative as the assignment requires. Use the actual available editor or a verified transcript export; a model name does not establish browser or media-tool access.
4. Apply the current writing and [article review](https://local-service-spotlight.github.io/task-library/?task=grade-article-using-jennifer#task-grade-article-using-jennifer) checks. Keep the person’s voice, sources and proof, a grade-five opening and a useful first-screen visual. An A-minus editorial grade is one gate, not permission to ignore factual, media or release defects.
5. Post uses the destination’s supported editor/source rail. Preserve existing builder data, page type and media. Check authorship, metadata, owned links and the [SEO Tree, the map of related pages](https://blitzmetrics.com/seo-tree/). Save drafts or publish only under current authority, then verify source and public rendering separately.
6. Promote reviews actual organic evidence and prepares the relevant [Dollar a Day, small paid tests of proven content](https://blitzmetrics.com/dollar-a-day/) test or other accepted distribution task. Do not prescribe paid spend for every content job; a live URL alone does not establish campaign readiness or authority.
7. Pass a concrete packet between stages: source files and rights; selected edited outputs and checks; exact saved/live destinations; then distribution settings and measured results. One usable shared file trail can support multiple tools, but each receiving worker must prove it can read it.
8. Record actual tools, file paths, checks and blockers in the run record. Reuse the same four-stage method without promising every provider or local model can perform every action. Next work starts from the retained evidence, not an assumed cross-vendor memory.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the result against its agreed requirements; see the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] All completed stage outputs are real, source-backed and readable by the next owner.
- [ ] The four stages are Produce, Process, Post and Promote; plumbing and measurement support them.
- [ ] Actual tool access, release authority and observed results are distinct; blocked stages are not called complete.

## Example(s)

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

A fictional owner has one recording and an AI app that can read text but cannot control the video editor. A teammate provides a checked transcript. The app drafts the article from it and saves the source links. Publishing and paid promotion remain with their authorized owners; one engine has not been claimed to run the whole line.

## Handoff and Content Factory context

The next real stage owner receives its exact packet. [Write the agreed weekly report](https://local-service-spotlight.github.io/task-library/?task=submit-weekly-maa-report-every-friday#task-submit-weekly-maa-report-every-friday) receives any measured business results; recipe changes follow the recorded review path.

This recipe coordinates the four stages in the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Each stage produces only its actual assigned outputs, and each handoff preserves source evidence and authority.

## Start with an agent

Give the AI worker this recipe, the real Inputs, the desired result and the actions already authorized. Ask for the saved output, source evidence, passed and failed checks, and the next owner. A skill is a set of instructions. Loading it does not prove access, install a scheduled job or complete the work. Use the [current installation guide](https://localservicespotlight.com/install/) only if reusable setup is needed; a ZIP contains instructions and is not an access grant.

Use the actual supported app and verified source access. A model name is not a promise of browser control, memory or unattended work. For recurring work, inspect the real job’s trigger, owner, timezone and observed firing; this recipe creates no schedule. Before any media playback, mute the player and set volume to zero. A silent review does not prove sound was heard.

## Record the real execution

Open the run record when work begins. Keep one execution ID, the exact starting recipe revision, input sources and actual state. Write a [meta article, the record of one real execution](https://blitzmetrics.com/meta-article-prompt/) with results, checks, failures and next owner. Link it to this task in the [Task Library](https://local-service-spotlight.github.io/task-library/). Writing is required; public release follows existing authority.

Reuse the same execution ID for internal reviews, meta writing, revisions and retries. A blocked run stays open with its dependency and owner, without an invented finish time. Keep historical public examples as dated evidence; article counts alone are not verified execution frequency. Use supported findings to propose and verify a recipe improvement.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 5/5 `●●●●●` — frequency 5, revenue 5, gating 5 (runs every factory cycle or weekly; ads/revenue path; unblocks a chain (access/plumbing))
- **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/content-factory/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=run-content-factory-on-any-engine#task-run-content-factory-on-any-engine)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](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, account access, an actual execution or a client outcome.

A relevant real execution, source evidence, independent reviewer and accepted handoff remain to be recorded. The fictional example teaches the method and does not fill a real-run evidence gap. The opening and full method need a named semantic reviewer; the task-specific path is source guidance, with visible desktop/mobile presentation still to check.