AI video preproduction checklist: from brief to first render

Use this checklist to decide whether generation should begin. It checks readiness, not how to write every shot or judge an already delivered video. The worked example is an illustrative approval scenario; its files, decisions and attempt limit are proposed planning records, not reported client approvals or generation results. Product documentation was checked on October 4, 2026.

Use three readiness states

Ready means the necessary evidence is present and the person responsible accepts the planned first trial. Blocked means a required input, permission, claim or capability remains unresolved. Not applicable means that the project does not need that check, with a reason: a silent product clip does not need a voice-consent record if no voice is used. Do not turn an unknown into not applicable to make the list look complete.

Separate required conditions from creative preferences. Missing source permission, an unsupported input or an unverified factual claim can block the affected work. A preferred camera style may remain flexible for the trial. Record that flexibility so the reviewer does not reject an otherwise suitable result against a requirement nobody supplied.

The preproduction readiness checklist

• Brief: one audience, one intended message, one next action and an identifiable version.

• Facts: every visible or spoken claim has an owner and supporting material.

• Permissions: intended source use, identities, voices, music and brand assets are cleared for this project.

• Assets: exact files are present, usable and consistent with the approved item or person.

• Route: selected tool accepts the inputs and supports the required settings.

• Delivery: runtime, crop, resolution, audio, copy and destination are specified.

• Review: pass/reject criteria and an available reviewer are named.

• Limits: first-trial scope, retry allowance, deadline and fallback are explicit.

• Handoff: operator has the current files, instructions and approval record.

• Release: finished-output approval remains pending until the export is reviewed.

1. Freeze the brief and claims

Give the brief a version, such as brief-v3, and identify which script, copy and references it governs. Replace “make it premium” with the intended communication: show the actual bottle clearly and invite viewers to open its product page. An attractive render cannot settle whether the underlying message is true. Resolve that decision before adding visual polish.

List exact factual statements, including text that appears only on a card or caption. A product claim, price, feature, performance comparison or quoted testimonial needs its own supporting material and owner. If approval is missing, remove that claim from the proposed clip or hold the affected shot. Do not turn a plausible generated scene into evidence that a real product performs as shown.

2. Clear the inputs for the intended use

Record who supplied each image, video, voice, music track and brand asset, plus the permission or agreement relevant to this project. Distinguish access to a file from permission to transform and distribute it. For identity-bearing media, name the person and the permitted role: a portrait animation, a synthetic spoken message or a face replacement are different proposed uses.

Keep unresolved rights questions with the person authorized to resolve them. Do not infer a third-party license from a paid tool account or a publicly available download. If music is optional and clearance is unknown, plan a silent trial while the owner checks the music. If the main identity or product artwork is unresolved, choose an approved substitute or block that input. This checklist records project decisions; it does not provide a legal determination.

3. Inspect the actual source files

Open the files the operator will use, not only thumbnails pasted in a brief. Check focus, compression, subject visibility, crop and unwanted details. Compare product packaging and labels across views. Check that identity references depict the intended person and that wardrobe or scene differences are deliberate. Name the exact version so a folder containing several similar files does not become a guessing exercise.

For a motion shot, ask whether the required visual information exists. A single front packshot does not establish an unseen back label or mechanism. If exact details matter, obtain an appropriate view or redesign the action to use the visible surface. Also check any overlay artwork and recorded audio independently; a good source photograph cannot repair missing words or an unusable voice track.

4. Confirm the production route can meet the brief

Choose the route from the required input and output. Animating an approved photograph suggests image-to-video. A concept scene with no specific source may use text-to-video. An exact price card or legal line may belong in an editor-built graphic. Separate generation from finishing so text, music and timing have a clear owner rather than assuming one request will complete the whole deliverable.

Check the current tool’s supported duration, resolution, input types and audio controls before the trial. Add an end frame only if the selected combination supports it. An account’s available choices and a provider’s advertised capabilities are not interchangeable. Save the selected settings with the brief; a model or setting change that affects a hard requirement needs another readiness check, even when the new option appears cheaper or newer.

When choosing an image-to-video route, use the image-to-video generator comparison to review workflow differences. If the brief requires two endpoint images, the first-frame and last-frame guide explains pair preparation and supported-settings checks.

5. Specify the delivered file and destination

Write the final runtime, aspect ratio or crop, required resolution, sound requirement and export destination. Verify current destination specifications when they determine acceptance. Make the editor’s allocation distinct from the generation request: a short insert may be trimmed from a longer supported clip. Check that important faces, packaging and text fit the intended crop before uploading source media.

Name the exact approved CTA and destination URL. Confirm any visible offer agrees with that destination. Decide where captions and overlays will be added and who checks them. A silent preview, a clip in the wrong crop or a working download link cannot satisfy a brief that requires a sound-on ad with readable copy and a verified landing page.

6. Define acceptance before seeing a result

Use conditions another reviewer can apply: one bottle throughout the used segment, correct cap and color, no invented label, no unwanted hand, and enough space for the approved overlay. Identify the highest-risk part of the intended action, such as a turn revealing a face or a camera move exposing product detail. Agree what may vary, such as minor background motion, and what must cause rejection.

Name the reviewer and when they are available. Record whether they approve the concept trial, factual accuracy, source use or final delivery. One person may own several checks, but do not hide the distinction behind “team approved.” If the reviewer cannot assess a technical or rights question, leave that item with its actual owner.

7. Limit the first trial and choose a fallback

Define one representative first clip, the permitted settings, the maximum attempts or spend allowance, and the point at which the operator returns for a decision. Use a limit appropriate to your own project; there is no universal attempt count that proves a workflow reliable. Include active repair time and space for final review rather than allocating every minute to generation.

Write a fallback that still fulfills the message: approved still with an editor-controlled move, a simpler action, an existing authorized clip, or revised delivery scope. The fallback should be known before a deadline forces an improvised substitution. A missing capability calls for another route; recurring geometry or identity damage may call for a better source or simpler brief, not another unchanged attempt.

Worked readiness example: an approved product photo

Scenario: a store proposes a short bottle reveal followed by an end card. The intended message is product recognition, with no efficacy claim. The following records are hypothetical. They show the difference between material being available and a first trial being approved; they do not assert that a real store or client supplied these approvals.

A revised readiness record could say: brief-v3 removes the unsupported claim; bottle-front-v2.png is the product owner’s chosen source; the trial uses no music; the operator confirms a supported image-to-video configuration; the CTA and product URL are approved; the reviewer will inspect product geometry and label preservation. This is a proposed resolution path. The record becomes ready only when the named people actually confirm those items.

For the example, allow a first attempt and one revised attempt before returning to the owner. That two-attempt allowance is a hypothetical project decision, not a recommended global rule. If both fail the declared product checks, use the approved still fallback or revise the brief. Final video publication remains pending through assembly, exported-file inspection and release approval.

Send a compact approval-ready handoff

Give the operator one current record: brief version, approved source paths, exact copy, intended route and settings, acceptance criteria, trial allowance, reviewer and fallback. Include the permission evidence where the operator can find it. Make unresolved items explicit; a general “go ahead” message without an agreed scope can produce a render that no one can responsibly release.

When an approved photo and motion brief are ready, open Magic Hour Image-to-Video. Upload the confirmed file, enter the approved motion instruction and choose currently supported settings. The current creator exposes image upload, motion prompting and model/settings controls. This is the handoff for a limited trial; inspect the result against the brief before assembling or releasing the final video.

If your route uses the API

Magic Hour’s development documentation describes a mock server for integration wiring without real processing or credit charges. Mock output does not establish generation quality, account eligibility or real delivery behavior. Keep that engineering check distinct from the creative trial. The product-video recipe creates a real project and consumes generation credits, so confirm the intended environment and trial allowance before running it.

Plan how the operator will retain the returned project ID and retrieve its existing result if waiting or downloading is interrupted. A client-side timeout does not cancel a project. Check the accepted job rather than submitting another creation request solely because the local wait ended. Keep credentials out of the creative handoff and use the linked official instructions for integration details.

Reopen only the readiness gates that changed

A new source image reopens asset and permission checks. New copy reopens factual and destination checks. A different model or duration reopens route and acceptance feasibility. A new crop reopens composition and readable-copy checks. Record the changed version and affected approval so the operator does not continue under an older decision.

Use the shot-list template to plan a sequence after readiness is established, and use an output-QA checklist to approve the finished media. This preproduction checklist owns the earlier decision: whether the current brief has enough evidence and a feasible route to justify its first render. After the named owner approves the resolved record, it establishes scoped trial authorization. Output quality and finished delivery still need separate verification.

Official sources and product references

Magic Hour: development and testing

Magic Hour: starter recipes