A defect taxonomy for generated video

"Looks off" is the most expensive two words in a review thread. Nobody can act on it, nobody can count it, and six weeks later nobody can tell you whether the thing that keeps going wrong is your model choice, your prompts, your brief, or your export preset.

The fix is unglamorous and it works: name the defect classes, define severity by consequence rather than ugliness, and route each combination somewhere specific. Once a rejection reads "CONTINUITY, S2, shot 4, wardrobe drift" instead of "hmm," the fix goes to the right person, the rework becomes countable, and the pattern across thirty rejections tells you which part of your pipeline is actually broken.

Six classes, sorted by where you can see them

The classes are organised by the smallest unit you need in order to detect the defect. That sounds academic and it is the reason the taxonomy works, because the detection unit is also the fix unit.

RENDER — visible in one frame. Malformed hands and teeth, extra fingers, warped logos, garbled text on signage, melted product geometry. Pause on any frame and it is there. Hands, teeth and signage covers what current models still get wrong and what that means for shot design.

MOTION — visible only across frames of one shot. Flicker, morphing between frames, objects that pop in or out, limbs that pass through solid things, an unrequested speed ramp, background that boils. A still frame looks fine; the clip does not. This is the class most likely to survive a review that consisted of scrubbing rather than watching.

CONTINUITY — visible only across shots. The character's jacket changes colour, the product label differs, the grade jumps warm to cool, a set dresses itself differently between cuts. Every shot passes on its own. The sequence does not. Four consistency mechanisms and when each fails explains why the right fix depends on which mechanism you were relying on.

SYNC — picture and audio disagree. Lipsync drift, captions landing late, a music hit on the wrong frame, room tone changing mid-line, a dub whose timing no longer matches the cut. These are almost never generation defects; they are assembly defects, which is why they get their own class.

BRIEF — technically clean, wrong answer. The shot is beautiful and it is not what was asked for. Wrong subject, product missing, a negative constraint ignored, tone mismatch, wrong duration or aspect ratio. This is the class that prompt adherence measures, and the one that gets misfiled most often, because a well-rendered wrong thing feels like a quality problem rather than a specification problem.

RIGHTS — a policy or legal problem regardless of how it looks. An identifiable real person without clearance, a third-party mark in frame, unlicensed music, a missing disclosure label, provenance metadata stripped by the export, an unsubstantiated on-screen claim. Craft is irrelevant here. A perfect asset in this class is still a defect.

Six is deliberate. Add a seventh and reviewers start deliberating about which box something goes in, which is time spent on taxonomy rather than assets. If a defect spans two classes, file it under the one whose fix you are about to apply.

Three severities, defined by where it can ship

Severity is the field people get wrong, because the instinct is to rate how bad it looks. Rate consequence instead.

Severity	Definition	Ships?
S1 Blocking	Cannot ship anywhere, in any placement, in any market	No
S2 Major	Cannot ship to the intended placement; could ship somewhere lower-stakes	No, not here
S3 Minor	Ships as-is; logged; fixed if the fix is cheap	Yes

Two rules make this usable.

Severity depends on placement, not on the defect. A soft hand in the background of a 6-second organic story is S3. The same hand in the hero frame of a paid campaign is S2. This is why the placement field belongs in the log — without it, severity is an opinion and two reviewers will never agree.

Every RIGHTS defect is S1 by definition. No exceptions, no judgement call, no "it's probably fine." That single rule removes the most dangerous conversation from the review process, which is a tired person at 6pm deciding whether an unclear likeness question is worth escalating. It is not their call to make, and the taxonomy should not let them make it.

The routing table

This is the part that converts a label into a saved hour. Class determines where the fix lives, and the cost of the fix varies enormously between classes.

Class	Where the fix lives	Typical cost
RENDER, local	Region edit on the affected area, or hide it with a cut or overlay	One edit, or nothing
RENDER, structural	Reroll the shot, often with a different model or a tighter prompt	New generation
MOTION	Reroll with motion constraints, shorten the shot, or change model	New generation
CONTINUITY	Re-generate the odd shot against the reference, not the whole sequence	One generation, not all
SYNC	Editor. Retime, re-align, re-export	Export only
BRIEF, one-off	Re-prompt	New generation
BRIEF, recurring	Fix the intake form, not the prompt	Process change
RIGHTS	Stop. Escalate. Never a prompt fix	Process, and possibly legal

Three things worth pulling out of that table.

SYNC defects should never trigger a reroll. They are the most commonly over-fixed class, because the asset looks wrong and the reflex is to regenerate. The cut is one re-renderable timeline, so retiming and re-aligning is an editor operation. preview: true returns a 480p pass at no credit cost with a short per-user cooldown between passes, which is enough to confirm a timing fix, and the final export is charged once regardless of clip count. Previews and the final export has the billing shape.

CONTINUITY fixes are one shot, not the sequence. The instinct on a drift problem is to regenerate everything against a new reference. Usually one shot broke, and re-generating that one against the existing reference is cheaper and less likely to introduce a second drift.

A recurring BRIEF defect is not a production problem. If the same "you missed the product" note appears across three jobs, no amount of better prompting fixes it. The information was missing before generation started.

The log record

Seven fields. Any more and it does not get filled in.

Field	Example
Asset or batch ID	q3-launch-b12-shot04
Class	CONTINUITY
Severity	S2
Intended placement	paid, 9:16
Where the fix landed	prompt / asset / brief / preset / checklist
Attempts to resolve	2
Repeat cause?	yes — third time this month

The fifth field earns the whole exercise. "Where the fix landed" is the difference between a defect log and a rework log. A log full of asset means you are fixing symptoms one at a time forever. A healthy log trends toward prompt, preset and checklist, because each of those removes a future class of defect rather than one instance. Asset IDs only work if they are stable and meaningful, so asset naming and version discipline is the prerequisite.

What thirty entries tell you

Once you have about thirty logged defects, the class mix is a diagnosis of your pipeline. Read it like this:

• RENDER-heavy. Model or shot-design problem. You are asking for shots that current models handle badly. Change what you ask for before changing how you ask. Why AI video artifacts happen and how to fix them is the reference.
• MOTION-heavy. Shots are too long or too complex for the model. Shorter shots and simpler camera moves usually collapse this category.
• CONTINUITY-heavy. You are missing a consistency mechanism, or using one that does not hold across the shot types you need. Consistency collapse and diagnosing drift between shots is the walkthrough.
• SYNC-heavy. Assembly and preset problem, not a generation problem. Fix the template once.
• BRIEF-heavy. Your intake is incomplete. This is the most common finding and the least often acted on, because it points away from the production team.
• Any RIGHTS at all. A non-zero count is itself the finding. One is a process gap, not bad luck.

Also watch two derived numbers. Attempts per resolved defect tells you whether your fixes are actually fixes or guesses. Repeat-cause rate tells you whether the fix is landing in the right layer — a high repeat rate with fixes landing on asset means you are patching instead of solving.

Where the taxonomy ends and diagnosis begins, a diagnostic tree for generations that come back wrong takes a symptom and walks it to a cause, and it is what stops a reflexive reroll from becoming the default response to every class.

FAQ

Isn't six classes overkill for a two-person team?

You already make these distinctions informally — you know a lipsync problem and a wardrobe problem get fixed in different places. Writing them down changes one thing: the note becomes countable. A small team can skip the severity field for a while, but not the class field, because class is what routes the fix.

How do I get reviewers to actually use the codes?

Put the six class names in the feedback template as the only way to reject. If a reviewer has to pick a class to submit a rejection, adoption is instant. If the classes live in a document people are supposed to remember, adoption is zero.

What about defects that are genuinely subjective taste?

Those are not defects and should not enter the log. "The energy is wrong" is direction, and it belongs in the revision conversation rather than the defect data, because mixing taste into defect counts destroys the diagnostic value of the class mix. If a taste note recurs across jobs, it is a BRIEF problem — the reference and anti-reference at intake were not specific enough.

Where do accessibility problems go?

Missing captions, unreadable contrast and unsafe flashing are RIGHTS if a platform or legal requirement mandates them, BRIEF if only your own standard does. Most teams should file them under RIGHTS at S1, because the enforcement path is external and arguing about the box costs more than blocking the asset.