Defining an Input Contract Before You Automate Video Draft Reviews

Where Video Draft Review Breaks Down

Most teams that iterate on short-form video concepts hit the same bottleneck: the gap between an approved idea (a prompt, a reference image, or a rough storyboard) and something reviewable on a timeline. If every iteration requires a full production pass — asset sourcing, editing, rendering — reviewers end up approving concepts based on text descriptions alone, and misalignment only surfaces after real production time has been spent.

The underlying issue is not rendering speed. It is that most workflows never define a stable input contract for what counts as a reviewable draft. Without that contract, every reviewer interprets "send me a draft" differently, and every generation step (manual or automated) receives inconsistent input, which makes output quality impossible to compare across iterations.

This note describes how we structured that contract for a team producing short video drafts from prompts, images, and keyframes, and where a generation tool sits inside it — as a supporting step, not the whole pipeline.

Defining an Input Contract for Prompts, Images, and Keyframes

Before generating anything, we fixed the shape of an acceptable input. This matters more than the generation tool itself, because inconsistent input is the most common cause of unusable drafts.

{
  "draftRequest": {
    "sourceType": "keyframe | image | text",
    "prompt": "string, required, max 400 chars",
    "referenceAssets": ["url or file id"],
    "resolution": "string, matches downstream editor project settings",
    "duration": "seconds, integer",
    "audio": "native | none",
    "shotIntent": "medium-action | close-up | reveal"
  }
}

The shotIntent field exists because reviewers kept approving prompts that were technically correct but produced the wrong framing. Naming the intended shot type up front — a medium character action, a product or subject close-up, a final reveal — forced requesters to commit to a decision before generation instead of after.

Turning the Contract into a Draft: Where the Generation Step Fits

Once a request matches the contract, it moves to a generation step. This is where we plugged in Flux 3 as one option among the tools we evaluated. According to the product page, Flux 3 is an AI video generator that turns text, images, keyframes, and visual references into video output, with configurable resolution, duration, and native audio, and it supports the shot-type framing described above (medium action, close-up, reveal) as generation presets.

We treat this step as a black box from the workflow's perspective: it consumes a validated request object and returns a draft video file plus the resolution and duration metadata that were requested. Whatever tool sits here, the contract from the previous section stays the same, which is what lets us swap or compare generation approaches without rewriting the review process around them.

What to Check Before a Draft Moves Downstream

A generated draft is not automatically reviewable. Before it goes to an editor or stakeholder, we run it through a short checklist:

• Does the resolution and duration match what the editing project expects, or does it need a conversion step first?
• Does the shot framing match the requested shotIntent, or did the generation step default to something else?
• Is the native audio track present and aligned, or does it need replacement before review?
• Is the reference asset (image or keyframe) visibly reflected in the output, confirming the input was actually used rather than ignored?
• Does the draft length match the intended edit slot, avoiding a resize pass later?

These checks are deliberately mechanical. They are not a creative review; they exist to catch mismatches between the contract and the output before a human reviewer spends time on judgment calls that a spec check could have caught first.

Where This Approach Stops Being Enough

This contract-and-checklist pattern helps with draft-stage iteration, but it does not replace production-grade editing, color work, or final audio mixing. A generated draft is meant to validate direction — pacing, framing, whether the concept reads correctly — not to ship as final output. Teams that skip this distinction end up treating draft output as finished work, which reintroduces the same misalignment the contract was meant to prevent.

It is also worth noting that the contract above was built around one team's editing pipeline; the field names and shot-intent categories will need adjusting for tools with different project settings. If you are building a similar review loop and evaluating generation options, start with the input contract, not the tool — it is reusable regardless of which generator you plug in.