# A 15-stage video workflow that survives handoffs

Use a renderer-neutral sequence of decisions, artifacts, and human gates. A recurring video project should be resumable from the work on disk, not somebody’s memory.

System guide · Video systems · By Mitchell Keller · Published Sep. 3, 2026 · 11 min read

[Back to resources](index.html) · [Open this resource as HTML](video-workflow-that-survives-handoffs.html)

## Key answer

- The workflow has four blocks and fifteen stages, each with a named input, artifact, and exit condition.
- Creative choices stay with people; scripts and checks handle bounded, repeatable work.
- Five approval gates prevent downstream production from outrunning an unsettled promise or story.
- QA can inspect a candidate render, but publication remains a separate, explicit human decision.

A handoff survives when the next operator can find the approved decision, the artifact it governs, and the next action without reconstructing context. The audited Video Content Engine models that requirement as a file-backed workflow: each stage names its input, writes evidence, and has an exit condition.

This production protocol assumes a person supplies footage and consequential creative judgment. Tools perform narrowly defined transformations and checks; they do not create the finished video by themselves.

## The bottleneck is lost state

Video projects tend to lose state at the seams: an approved hook exists only in chat, a script has competing filenames, or an editor starts visual work before the story is settled. A later operator may see files, but cannot tell which version is current or why a decision was made.

Put the decision beside durable evidence. An approved outcome belongs in `brief.md`; packaging and script decisions belong in receipts; the story cut and edit decision list live in `edit/`; a selected candidate and final review live with QA. If disk state and a receipt disagree, stop and expose both rather than guessing.

## Four blocks, fifteen stages

The release groups stages 0–14 into four blocks. This map is deliberately compact: it shows the order of work, not a claim that every project needs the same tools.

| Block | Stages |
| --- | --- |
| Define (0–3) | kickoff → outcome → packaging → script |
| Record (4–5) | capture → ingest and transcript |
| Build (6–11) | story architecture → cut and EDL → storyboard → assets → scene build → assembly |
| Ship (12–14) | QA and ship → publish → learn and repurpose |

For each stage, write down the required input, evidence written, and exit condition. The first stages answer what the viewer should get and what can honestly be shown. Build stages turn that approved story into a candidate. Ship stages review, publish only with confirmation, then capture a lesson for the next brief.

## Decide before expensive work begins

Lock the promise before scripting, the script before recording, the story before visual design, and the storyboard before a complex asset or render batch. Early decisions keep a polished downstream artifact from hiding an unmade upstream choice.

At packaging, select one title, opening hook, and thumbnail promise that describe the same useful idea. At story architecture, work from the timestamped transcript: record what to keep, remove, reorder, and prove before a cut becomes the source of truth. At storyboarding, give every visual a purpose, such as proof, orientation, comparison, or sequence, rather than “add movement.”

## Make every handoff recoverable

Use files that answer a narrow question. The immutable original belongs under `raw/`. A timestamped transcript belongs under `transcript/`. Approved source-time spans are inspectable in `edit/edl.json`. A storyboard records visual purpose and dependencies. Versioned candidates live in `renders/`. Receipts record the choice among them.

That structure supports recovery. If a gate is rejected, return to the artifact that gate owns instead of patching a downstream symptom. If a renderer fails, retain the approved storyboard and diagnose or replace only the implementation route. If no evidence shows why a stage is complete, recreate the evidence before continuing.

## Separate judgment from mechanics

| Human judgment | Mechanical work |
| --- | --- |
| Select the honest viewer promise and packaging. | Report project state from artifacts on disk. |
| Decide which transcript passages make the story. | Validate approved spans and assemble a rough cut. |
| Judge whether a visual clarifies the spoken idea. | Measure media properties and flag check failures. |
| Approve the final file, channel, metadata, and visibility. | Prepare metadata or perform an authorized upload. |

The division is practical. A cut builder can concatenate approved timestamp spans; it cannot decide which sentence deserves to survive. A QA tool can report a condition; it cannot take the ship decision for the person responsible for the publication.

## Five deliberate human gates

The release identifies five gates: promise lock, packaging lock, script lock, storyboard lock, and ship lock. A specialist can prepare options, make a recommendation, or run a measurement, but it does not approve its own work on the operator’s behalf.

- **Promise lock:** confirm the viewer outcome and honest proof before packaging.
- **Packaging lock:** select the coherent title, hook, and thumbnail promise before scripting.
- **Script lock:** approve the spoken story after a read-aloud review before capture.
- **Storyboard lock:** approve visual intent before asset production or complex rendering.
- **Ship lock:** record a human approval after reviewing the candidate render.

## Keep the workflow renderer-neutral

The workflow’s durable contract is the approved story, edit decision list, storyboard, assets, receipts, and candidate render, not a particular editor. The public release documents an optional HyperFrames route and also permits a traditional NLE or another renderer when it can implement the approved board and preserve traceability to its beats.

The approved artifacts make the workflow portable across compatible renderers; each renderer still needs its own checks. For the documented HyperFrames route, linting, snapshot checks, visual inspection, and an approved preview are required before final render.

## Separate QA from publication

QA begins with a candidate render. Run the mechanical check, watch the full candidate at normal speed, inspect the opening separately, and record the human final review. Look for timing, audio, captions, safe zones, stale assets, and the selected version, not merely whether a file exists.

Publication is a later boundary. Prepare metadata before authentication. Before upload, approve the exact file, channel identity, visibility, title, description, thumbnail, captions, and chapters where relevant. The documented uploader defaults to private; public visibility requires an additional explicit confirmation.

## Protect the public-release boundary

> **Scanner limits are real limits:** A release scanner can catch common credential and local-path patterns. It cannot determine whether every company name, screenshot, proprietary idea, or historical artifact is safe to disclose. Human review of the extracted release remains necessary.

The audited public edition intentionally excludes credentials, customer material, private prompts, production receipts, private asset libraries, local machine paths, and sensitive history. Before sharing a derivative, start from the clean public tree. Remove unintentional media and projects. Run the scan, then inspect the inventory and outbound URLs. Build an immutable archive. Extract it and repeat the review.

If sensitive material is exposed, remove access where possible, rotate or revoke credentials at the provider, inspect distribution and history, then rebuild from a clean tree. Deleting one file is not a complete response.

## Start with one real video

1. Create a small project and write the viewer outcome and evidence you can honestly show.
2. Choose one package, approve a spoken script, then preserve the source recording in `raw/`.
3. Use a timestamped transcript to approve the story cut before you design visuals.
4. Keep the EDL, storyboard, candidates, QA review, and publish metadata in their named locations.
5. At each gate, make the owner and decision explicit. After publication, wait until your chosen outcome data is mature enough to interpret before changing the next brief.

Use a small first project whose next operator can resume without a private conversation, a memory test, or a guess.

## Source notes

This guide is grounded in the audited public Video Content Engine release: *README.md* for scope and workflow framing; *PIPELINE.md* for its fifteen stages, stage contracts, recovery rules, and gates; *GUIDE.md* for the operating rationale; *TOOLS.md* and *SKILLS.md* for optional tooling and routing boundaries; *AGENTS.md* for human-approval rules; *SECURITY.md* for public-release limits; and *YOUTUBE-API-SETUP.md* for the private-by-default upload boundary.

It describes an audited public workflow release, not a customer deployment, a public offer, or a claim about a particular renderer’s capabilities.

## Related resources

- [From market signals to operator-ready opportunities](from-signals-to-opportunities.html): apply the same evidence-and-handoff discipline to a signal system.
- [47 GTM tools, ranked by what an agent can actually drive](../articles/gtm-tools-tier-list.html): assess where a tool can support an operator workflow.

## Build your operating system with Legion

Join the Legion waitlist to hear when new operator resources and product work are ready to share.

[Join the waitlist](https://waitlist.joinlegion.io/g/legion-waitlist)