What you will do
Imagine that you have a good start frame of a courier and a bicycle. On the next attempt, you change the frame, camera movement, duration, and action text all at once. The new file looks better. Great — except for one small detail: you no longer know why it improved.
In this lesson, you will build one controlled test. You will place decisions in four separate layers, choose one variable to change, and name the visible sign that lets you accept or retry the test before you run it. This is not generation paperwork. It is how you stop repairing a video by guesswork.
The four places where decisions live
One test has four layers. They work together, but they should not compete for the same job.
Source files are files that already exist: a start frame, portrait, object photo, movement reference, or finished clip. They hold what you had before the run.
The prompt is the generator-facing text. It describes only what the viewer must see: the action, camera job, details to preserve, and the scene’s ending.
The interface is the separate control set in your chosen tool. If the current screen gives you fields for mode, duration, format, or quality, choose those values there instead of hiding them inside the story.
The check answers two questions in advance: what changes in this attempt, and what must be visible for the test to pass.
Give each source file a narrow job
“Use all references” does not explain anything. One file can support a particular part of the test, but it should not suddenly become the director of the whole scene.
In the courier example, the roles look like this:
- the start frame holds composition, pose, direction of movement, and lighting;
- a portrait, when needed, holds the face, hair, and distinctive features;
- a bicycle photo holds its shape, proportions, and material;
- a movement example controls pace and movement character only — and only if the selected route actually accepts that input.
When two files disagree about one property, choose the leading one before you run anything. A longer prompt does not solve the conflict; it only makes the argument wordier.
Keep interface settings in the interface
Story duration, available generation duration, and the length of the edited clip are different records. The same applies to mode, format, and quality: when the tool presents them as separate choices, they belong in the interface.
The prompt keeps the meaning: the courier grips the handlebar, walks the bicycle forward, the camera keeps the pair readable, and the clip ends in a clear state. The interface keeps the available choices for that run. An exception is possible only for a specific route that is confirmed to require a parameter in text; without that confirmation, do not guess.
Key point: look at the current screen first, then record the available value. A memory of an old guide is a poor interface, even when it is very confident.
If the needed route or required input is unavailable, record: “route not confirmed.” That is more honest than presenting preparation as a run.
One-test plan
The plan now has a purpose: it does not collect everything at once; it keeps the boundaries between the four layers visible. Copy the form and fill it in for one short action.
Test objective:
Selected route in the current interface:
Source files and the narrow role of each:
What the prompt describes:
What is selected only in the interface:
One variable to change:
Accept if this visible result appears:
Reject and retry if this is visible:
Run status: prepared / file reviewed:Filled example
You have an accepted start frame: a courier stands beside a bicycle. The test objective is to see the beginning of movement without changing the person, bicycle, or location.
The plan selects a future route that you still need to confirm in the current interface. The start frame holds the person, bicycle, composition, lighting, and starting state. The prompt describes one action, a calm camera, the elements to preserve, and an ending. Available duration, format, and quality are selected only in the interface. The variable to change is action speed.
Accept the test when the courier and bicycle remain consistent, the movement reads clearly, and the camera does not rebuild the scene. Retry when the face or bicycle shape changes, a second action appears, or the camera loses the subject.
Here is the text to paste into the generator. It does not contain route, duration, format, or quality; those values are checked and selected separately.
The courier grips the bicycle handlebar and begins walking the bicycle forward at a calm pace. Keep the same person, clothing, bicycle geometry, location, composition, and lighting from the attached start frame. The camera remains steady and keeps the courier and bicycle readable. End with the bicycle moving forward under the courier's control. No identity change, no object duplication, no sudden camera move.One variable, one answer
A variable is one meaningful part of the test that you intentionally change. In this example, it is action speed. Everything else stays as the accepted baseline so that the comparison can teach you something.
If the action is too fast, change only the speed. If the face drifts, change only the identity support. If the camera loses the subject, simplify only the camera job. If the bicycle deforms, clarify or replace only the object support.
This produces more than another file. It produces a small usable piece of knowledge: for example, a calm pace preserved the bicycle, while a fast instruction made the action unreadable. That is more useful than accidental luck because you can carry it into the next test.
Practice: prepare an honest test
Choose one future frame or clip. Fill in the plan, prepare one English prompt, name one variable, and write what will count as acceptance and rejection before you run anything.
If you have real access to the selected route, run one test, save the actual file, and compare it with the criteria. Then record accept or retry and one reason.
If you cannot run it now, you can still finish the lesson at the preparation level: you have a completed plan and ready prompt text. Do not call that a verified generation. Verification begins only when an actual file exists and you have watched it.
Check and next step
The lesson is complete when every source file has a clear role, interface settings are not hidden inside the prompt, exactly one meaningful variable changes, and the criterion describes something you can see.
After a real run, one more piece of evidence is required: the saved file and an honest accept / retry decision. If the plan still contains alternatives joined by “or,” return to route selection. If you cannot name the visible result, return to the shot plan. If a file already exists but breaks the criterion, the next move is to diagnose one cause, not to replace the entire project at once.
Takeaway: generation stops being a lottery wherever you know what the source file holds, what the prompt explains, what the interface chooses, and which one thing you are testing now.