A 15-stage video workflow that survives handoffs

Key answer

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.

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

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

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.