TEST IT IN MOTION
A still is only a hypothesis. Run the motion your shot actually needs, then change one variable at a time until the visible failure points at either the source asset or the motion you asked for.
START FROM SOMETHING DIAGNOSABLE
When the character is the question, keep the location out of it. Use a plate that already holds its geometry, depth, materials and light.
Street edges, depth and light all read correctly. The character is the only real uncertainty, so any failure has one plausible cause.
The location already has structural failures — warped storefronts, torn vehicles. Now every character failure has a second plausible cause and the test proves nothing.
This is the same reason a bug is reproduced on a clean checkout before anyone argues about the fix.
READ THE CONTROLLED RESULT
One bad clip is a symptom, not a diagnosis. Compare its first failure against the source stills, then change exactly one thing and look again.
THREE REAL DIAGNOSES
All three came from building this pipeline, and all three were solved by changing one thing.
1. The vision model described the wrong video entirely.
Same three frames, same prompt, same settings — only the model changed. gemma4 said “a person's arm in foliage”, then “wild birds in woodland”. qwen3.6 said “a snow leopard… snow-covered peaks”.
The input was identical, so the input was not the problem. One model reads frames and one invents them, and its own capability list says both can.
2. The voiceover came out at 4.8 seconds for a 10-second clip.
Same narration text, same node, same settings — only the reference voice changed. A 19.7s reference gave 4.78s. A 6.4s reference gave 10.92s. Then, holding the reference and changing only speed to 0.6, the output got SHORTER, not longer.
Length is governed by the reference's own seconds-per-character, not by the script. And the second control caught something nobody would have guessed — the speed parameter runs backwards.
3. The vision model returned an empty reply, so vision looked broken.
The same model, same prompt, one image instead of six. It answered perfectly. Then the raw response was printed rather than summarised, and the answer was sitting in `message.thinking` with `content` empty.
Two unrelated faults produced one identical symptom — VRAM exhaustion AND a thinking model splitting its reply. The first explanation that fitted was not evidence. Shrinking the input separated them.
TWO THINGS TO REFUSE
A percentage cannot approve a shot
Not a confidence score, not a quality number, not a model’s reputation. The evidence is the named source assets, the motion you required, and the visible result.
A diagnosis is about this asset, not about the model
“This reference produced rushed narration” is a finding. “F5-TTS is bad at pacing” is a story. And one clean rerun does not guarantee the next — generation is not deterministic, so a pass is evidence about one result, not a promise about the batch.
Related: Proof, not promises is how you decide something is wrong. This is how you find out what caused it.