A pre-launch QA checklist for generated ad footage

Six of these checks, on one frame

Tap the marks

123456

One of ours. Six of the twenty-one checks below are visible in this single frame, which is the argument for running QA on stills pulled from the cut rather than on the cut playing at full speed.

01In what order should you QA a video ad?

Kills first, then weaknesses, then arguments. Physics and depth are unfixable once shot and visible in a second, so they go first. Story and the leak are next, because they decide whether anything else matters. Type, frame and sound follow. Message logic and brand come last, because they are judgments rather than defects.

Nearly every line there exists because something of ours failed on it. That is the only reason to trust a checklist: not that it is complete, but that each line was paid for. If you are doing this on the buying side rather than the making side, reviewing creative when you are not a video person covers the same ground from the other chair.

Run it cold, and run it once. The first watch is the only honest one you get, because after that you know where everything is and your eye stops behaving like a stranger's. If you need a second opinion, hand the file to somebody who has not read the brief instead of watching it again yourself.

02Physics, depth and the leak kill a cut outright

These three are first because they are not fixable in a grade or a caption. A photographed object performing an event it could not perform is caught by the eye faster than a soft shadow is. Two layers cut from the same pixels shear against each other the moment they move. And a leaked payoff ends the film in beat two, whatever happens afterward.

The bread kill is the one I keep going back to: two halves of a photographed loaf pulling apart, passing every automated check we had, killed on sight because the craft was fine and the event was invented. It is told in full in why AI ads look fake.

The depth version of the same mistake

We built a depth effect once by duplicating pixels from a single plate into two layers and sliding them against each other. In a still frame it looked defensible. In motion the eye saw one object doubled and shearing against itself, and it died on the first watch. This is the class of defect a frame-by-frame check cannot catch, which is why the item on the list asks you to watch rather than to scrub.

03How do you check type on a phone?

Two floors and one habit. The line has to stay fully opaque for at least 1.2 seconds or 0.35 seconds per word, and it has to clear a contrast ratio measured against the worst local background under each run of letters, at delivery width and again at about 360 pixels. The habit is doing it on the delivered file rather than in the editor.

Type your own line and see whether it survives a phone

Type into it

The line you want on screen

How long it holds

Type size

Plate behind the type

Words-

Dwell floor-

Your hold-

Contrast-

The dwell floor is ours and deliberately blunt. The contrast reading here is a simplification of what we actually run, which measures the worst local ground under every glyph run rather than a single average across the string.

A mean is what makes this check fail silently. One of our headlines measured a perfectly respectable average and 1.17 to 1 against the actual worst ground beneath it, because the word sat across a doorway edge and a lit white blouse in the same line. When we re-measured fifteen delivered statics this way, fourteen of them failed, and sixty of seventy-eight text runs failed with them.

The failure was the house style rather than one card, which is the useful and unflattering version of that finding. The full treatment, including why weight beats size, is in the legibility floors for captions on a phone, and where the interface eats your frame is in safe zones as constraints.

04What does an automated version of this look like?

About half of the list above is measurable, so about half of it should never reach a human at all. Here is a real shape of a run: the floors get measured on the delivered bytes, the failures are named with the number that failed, and everything that needs judgment is routed out rather than guessed at.

Two properties make that run worth having. There is no force flag, so nobody can wave a failure through at five in the evening. And a re-render voids every verdict, because a verdict belongs to the bytes rather than to the project. Sorting the measurable half from the rest is the whole subject of turning taste into checks a machine can run.

05Who should run the checks?

Not the person who made the ad. A maker reads their own intention into a frame and a stranger reads only what is there. Nothing here is packaged until five separate verdicts come back from reviewers who have seen the delivered bundle and nothing else: no build notes, no direction lock, no previous verdicts.

One more property is worth copying. A re-render voids all five verdicts, with no exceptions and no partial credit, because a verdict belongs to a specific file rather than to a project. It sounds pedantic until the first time somebody re-exports at the last minute to fix a caption and quietly ships a version nobody checked.

06All green means the floors cleared, not that the ad is good

This is the part a checklist post normally leaves out. Fewer than half the films that clear every automated check here survive the first human viewing, and that number is not a fault in the checks. It is what checks are for. They clear the floors so the remaining argument can be about whether the thing works.

A checklist takes every argument about a defect off the table. What is left to disagree about is the work. Everything above is downstream of one decision anyway, which is approving the story on paper before anything renders.