A faceless-video pipeline is still an editorial pipeline.

Start with stages, not apps

Tool-first pipelines become brittle because every new model or editor changes the architecture. A stage-first pipeline describes durable work: research, source review, scripting, scene planning, asset collection, narration, assembly, quality control, and release.

Each stage should declare its inputs, outputs, upstream dependencies, and whether it is manual or executable. Tools can then be swapped without changing the meaning of the workflow.

A useful nine-stage map

1. Research: create a brief, claims table, and source list.
2. Source review: confirm the chosen evidence and record an approval.
3. Script: write the narration against the reviewed claim set.
4. Script approval: fingerprint the exact script version cleared for production.
5. Scene plan: map narration beats to visual requirements.
6. Assets and narration: create or collect the material needed by the plan.
7. Rough cut: assemble a reviewable render.
8. Quality control: inspect factual, visual, audio, rights, and platform concerns.
9. Release approval: record the final human decision before publication.

Give every stage a contract

A stage contract should be boring and explicit. Research may require brief.md, claims.csv, and sources.csv. Scene planning may require an approved script and produce scenes.json. A rough cut may depend on scenes, assets, and narration, then produce a video file.

Empty files should not count. Paths should stay inside the project root. Executable commands should be arrays rather than shell strings so unreviewed interpolation cannot introduce arbitrary shell behavior.

Default to preview

The workflow should show the next command before running it. Explicit execution is especially important when a stage calls a paid API, a long render, or a publication tool. Retries should be bounded and logs should record the command, exit code, duration, and output without storing credentials.

Keep publication separate

A completed file is not the same as a publish decision. Treat release as a gate with its own reviewed inputs. This keeps a successful render, script, or automation from becoming accidental authorization to make something public.

Minimal project checklist

• Stages have stable IDs and explicit dependencies.
• Inputs and outputs are project-relative paths.
• Manual stages are first-class, not treated as failures.
• Approvals fingerprint the files actually reviewed.
• Changed inputs mark derived outputs stale.
• Commands preview before execution.
• Publishing requires a separate release decision.