# Video Prompt and Verified Clip

## What you will build

One clip is not a promise of a future generation. It is a small, feasible job with a clear start, action, and stopping frame. In this lesson, you will build that job: separate story time from what the interface actually offers, choose a route from the inputs you have, write a clean video prompt, and prepare an honest review of the result.

Start with a simple scene. A person at a table notices a white sheet, shifts their gaze, and reaches forward — but the clip ends before contact. There is one action, one camera job, and an obvious stopping point. That is enough to learn control without asking the generator to make an entire film in one breath.

```learner-callout
{"stable_id":"aiv-c075-one-executable-clip","role":"key-point","title":"Key point: the record is not the result","body":"A good record and a strong prompt prepare a run, but they do not prove a clip. The result exists only after an actual test and review of the saved file."}
```

---

## One clip, one feasible job

One segment may contain several connected phases when the scene, main subject, causality, and camera remain continuous. For example: a character notices an object, reaches toward it, and pauses before contact. That is still one readable gesture.

Split the task into a new clip when location or time, the main subject, the main action, camera logic, an important world state, or the generation route changes. Split it when the viewer can no longer read what is happening. The rule is not “one script line equals one generation.” The rule is “one action must remain physically feasible and readable.”

```learner-callout
{"stable_id":"aiv-c075-split-observation","role":"observation","title":"Observation: too many actions hide the cause of failure","body":"When a clip changes the character, location, camera, and action at once, you cannot honestly tell what failed. A small segment is not less ambitious; it is more testable."}
```

## Three times that must stay separate

A clip has three different times. They are related, but they do not have to match.

| Time | What it means | What to record |
|---|---|---|
| Source story interval | The moment in the story that the clip covers | For example, `0:10.0–0:13.5` |
| Interface-available duration | The value the chosen route actually shows now | For example, `4 s` |
| Editing target | The part of the file needed for the edit | For example, keep `3.5 s` and trim the quiet tail |

A story interval does not prove that the interface has a button with the same duration. Check the real available option first, record it, and only then decide how the clip will work in the edit.

```learner-callout
{"stable_id":"aiv-c075-timing-technique","role":"technique","title":"Technique: measure the interface before promising the edit","body":"Story time carries meaning, the interface determines the available generation, and the edit needs its own target length. Keeping these records separate prevents you from assigning the tool a capability you have not checked."}
```

## Choose the route before writing the text

Route names vary, and their inputs and availability change. Do not guess from an old review: open the current interface and see what it actually accepts. You may have text only, a start image, several materials with distinct roles, first and last frames, several keyframes, an existing video to edit, or a separate route for speech.

Choose one route that accepts the inputs this clip requires. If a required input is unavailable, change the route or the task itself. A longer prompt cannot create a missing upload field — it already has enough ambition.

```learner-callout
{"stable_id":"aiv-c075-route-caution","role":"caution","title":"Caution: do not claim an unverified route","body":"Do not write that a selected route supports start and end frames, several references, speech, or a specific duration until that is visible in your current interface. If the segment contains dialogue, assign a separate speech or dialogue route."}
```

## Short clip record

Fill in the record before you run anything. It keeps the facts that do not belong inside the prompt together: the actual route, inputs, editing target, and review.

```template
Source story interval:
Tool, model, or version, if shown:
Selected route and actual input:
What the current interface confirms:
Interface-available duration:
Meaningful settings:
Editing target / what to trim:
Starting state:
One main action / phases:
Camera job:
Visible physical response:
What must stay consistent:
Exact end state:
Music: none / generate / add in editing:
Ambient sound and effects: none / generate / add in editing:
Speech and voice: none / generate / add in editing:
Input materials and their roles:
Video prompt text:
Review criterion:
```

Add a reference, keyframe, music, speech, or separate effect only when it genuinely participates in the job. A material without a role does not create control; it creates a queue of conflicting wishes.

## Build a clean video prompt

Only the scene and its constraints go into the generator. Build the prompt in one order: scene and subject → main action → connected phases, if needed → one camera job → visible physical response → exact end state → what to preserve and the risk to avoid.

```template
[Scene and subject]. [Main action and ordered phases]. [One camera task].
[Visible physical response]. [Exact end state].
Preserve [critical continuity]. Avoid [specific likely failure].
```

Interface settings, file roles, the source of the decision, the editing note, and the full review list stay beside the prompt. They matter, but they do not make generator-facing text clearer.

```learner-callout
{"stable_id":"aiv-c075-prompt-technique","role":"technique","title":"Technique: give the camera one job","body":"“Dynamic cinematic camera” describes neither a path, speed, nor stop state. Choose one: stay still, move slowly closer, follow the action, reveal an object, or end in an exact composition."}
```

## Example: stop before contact

The source scene is a candidate at a table who notices a white sheet. The sound decision is honest: no music and no speech; quiet room tone and clothing sound will be added in editing. The stop state matters: the hand freezes before contact and the sheet remains still.

```prompt
The approved job candidate remains seated at the near side of the table, facing the recruiter. He notices the white sheet, shifts his gaze down, and reaches forward once with his right hand, stopping just before contact. The sheet remains face-up, flat, and completely unmoved on the tabletop. The camera makes a restrained slow push-in while preserving the table axis, the candidate's identity, charcoal jacket, hand anatomy, room geometry, and soft screen-left light. End with his hand held still just short of the sheet, before contact, while the sheet remains face-up and unchanged for a clean edit point. No touching or turning the sheet, no extra papers, no object duplication, no camera jump, no background music, no generated speech.
```

The prompt does not ask the character to turn the sheet. That would be the next phase or a new clip. An explicit ending reduces uncertainty, but it does not guarantee execution. Only review of the actual file confirms it.

When another hypothetical clip truly needs connected phases, name them in order: notice the object → reach toward it → touch it → hand and object hold an exact end state. This is the action’s internal rhythm, not a promise that the interface accepts every fractional time value.

## Keep prompt, settings, materials, and sound apart

Keep four layers separate:

- **Prompt to paste** — clean English text for the scene, action, camera, and constraints.
- **Settings and materials** — the selected route, available duration, actual inputs, and file roles.
- **Review** — a short list of visible properties for the accept-or-retry decision.
- **Sound** — a separate decision for music, effects, speech, and anything added in editing.

Speech, music, and effects are not required for every clip. When you need them, assign one owner: generation through the selected route or addition in editing. Do not call sound finished until an actual result exists and has been listened to.

```learner-callout
{"stable_id":"aiv-c075-audio-inference","role":"inference","title":"Inference: no sound can also be a decision","body":"For a simple gesture, the honest note “music: none; speech: none; ambience: add in editing” is stronger than the vague request “make it atmospheric.” It leaves a testable boundary between the video clip and the next audio step."}
```

## Real run: accept or retry

Do this part only when you have real access to the selected route. Open it, upload only the declared materials, record the available duration, run one test, and save the actual file under a clear name. Watch the entire file, including its first and last frames.

Then complete the review record.

```template
File actually reviewed:
Status: accept / retry:
Does it cover the source story interval:
Does it perform one main action:
Are subject, objects, geometry, and lighting preserved:
Did the camera perform one clear job:
Does the end state support the next edit:
Actual sound status:
One observable reason for the decision:
One change before the next test:
```

You can accept a clip when it covers the required story interval, performs one main action, preserves critical continuity, ends in a usable state, and is judged from the reviewed file. If the test fails, choose one observable defect and change one likely source: input frame, action, camera, end state, or generation route. Do not turn a retry into a lottery of five simultaneous changes.

```learner-callout
{"stable_id":"aiv-c075-acceptance-checkpoint","role":"checkpoint","title":"Checkpoint: the decision comes from the file","body":"Preparation is complete when the record is filled in. A clip is accepted only when the saved file has been reviewed, the reason for the decision is named, and a retry has one observable problem and one next change. No run was performed or proven in this worker candidate."}
```

## Takeaway

You now have a route for one clip, not a “magic prompt”: story interval → actual route and duration → record → clean prompt → real test → honest `accept / retry`. The next route can refine control or diagnose a failure, but it needs this clear, testable segment first.
