AI Video Generation Log: Keep Tests Comparable

An AI video generation log keeps tests comparable. Each row is one render, with the filename, the one variable that changed, the prompt version, the still source, the model route, the duration, the aspect, a keeper or reject reason, and the credits the screen showed for that run.

Teams lose days when a strong clip cannot be explained. The prompt was edited in a chat box, the still was replaced, the route was switched, and the duration was shortened, all before lunch. The folder then fills with files named final, final2, and new-new. A week later nobody can say which change produced the usable take. The log is the production notebook that makes that diagnosis possible.

This notebook sits beside generation. It is the record of how a clip was made. Prompt writing already has its own guides. Campaign structure and creative testing belong in the AI ad creative testing workflow. Export containers, crops, and captions belong in the AI video export settings checklist. If a still is the source, first-frame decisions belong in AI video first frame design, and broken image-to-video results belong in AI image-to-video failure fixes. Use those pages for their jobs. Use this page to record the run so those jobs can be audited later.

Cliprise is an AI creative platform at https://www.cliprise.app. The AI video generator turns a prompt, or a still plus a prompt, into a clip through the model route you select. The image-to-video generator is the path when a still should lead. The log does not replace either tool. It makes the outputs explainable after the credits are spent. For a first logged pass, generate one baseline and one single-variable follow-up in the AI video generator, then write both rows before you close the screen.

What the notebook is responsible for

A generation log answers a narrow set of questions:

• Which file is this?
• What was held constant?
• What single thing changed?
• Which prompt text was used, by version?
• Which still file was uploaded, if any?
• Which model route was selected, using the label shown that day?
• What duration and aspect were requested, and what did the file actually contain?
• Was the result kept, held, or rejected, and for what visible reason?
• What credit figure did the screen show for this attempt?

A generation log does not answer whether a hook will win a media test, whether a caption strategy is right, or whether a delivery file meets a platform spec. Those are real questions. They are answered in other notebooks, after this one has identified a usable picture.

Think of three layers of record:

1. Shot goal. One or two sentences that say what this shot must show. Example: a pale table, a closed bottle, a slow push closer, label geometry stable, no baked-in marketing text.
2. Generation row. The facts of one render, listed above.
3. Decision. Keeper, hold, reject, or void, with evidence a stranger can check by watching the file.

The shot goal changes rarely. The generation row changes every click. The decision is added after someone watches the output. Mixing those layers into a single chat message is how comparable tests disappear.

Semantic relationships worth keeping straight while you write rows:

• A text-to-video run starts from a prompt version and has no still source.
• An image-to-video run animates a specific still version.
• A model route is the generator path selected for that row, copied from the product on that date.
• A comparison set is a group of rows that share a parent and change one field at a time.
• A keeper is a file that meets the shot goal well enough to move forward.
• Credits are the usage units the product displayed for the attempt. Plan-level credit planning lives on the pricing page, not in a guessed column of dollar amounts.

A row is comparable only when the parent is explicit

Comparable does not mean identical, and it does not mean artistic. Comparable means a reviewer can point to two rows and name the difference without oral history.

Every test row needs a parent, except the baseline that opens a set. The parent is an earlier run id. The child copies the parent's prompt version, still version, model route, duration, and aspect, then changes one of those fields. The changed field is named in the row. If you cannot name the parent, you do not yet have a test. You have an exploration.

Two structures both work if you label them.

Sibling set. One baseline. Several children. Each child lists the same parent. Each child changes a different field, or changes the same field to a different value. Sibling sets answer, "Which single change helped relative to the baseline?"

Stepwise chain. Each keeper becomes the parent of the next run. Each step still changes one field. Chains answer, "Did this sequence of decisions hold together?" They do not answer which historical step mattered unless you keep the earlier rows and resist the urge to compare the newest file with the oldest file as if only one thing had changed.

Do not analyze a sibling set and a chain as if they were the same shape. Say which structure the rows belong to before you declare a cause.

Mark a row VOID when two or more of these change together: prompt version, still version, model route, duration, aspect. Void rows can stay in the notebook because the team did spend the attempt and may still like the picture. Void rows are not evidence. A happy void is a lucky file with a keeper decision, plus a note that the cause is unknown. If you need a cause, rebuild the idea as a new baseline and test forward one variable at a time.

Exploratory browsing is allowed. Production diagnosis is not browsing. If the operator is hunting for a look, label the rows EXPLORE, skip the parent rule, and do not cite them in a review meeting as proof that a route, a prompt, or a still is better. When a look is found, freeze it as a baseline and start a real set.

The fields that make a later diagnosis possible

Use one table per project, in a spreadsheet, a structured document, or a ticket system that can export a table. The storage tool matters less than the fields and the habit of writing them before the screen is gone. A shared table with locked header names will beat a beautiful template that people abandon.

Required fields:

Optional fields, written as "not shown" when the product does not expose them:

• seed, only if a seed control is visible
• resolution, only if the generation screen shows it
• audio on, off, or not offered
• avatar or voice reference id, if that run used one, stored as its own field so it is not buried in the prompt version
• error text, if the job failed before a file existed
• reviewer name, once the decision is added

Write "not shown" on purpose. A blank cell looks like a forgotten fact. "Not shown" tells the next person the product did not offer that control on that date, so they should not invent a seed or a resolution from the delivered file after an editor has touched it.

Shot goal text can live once at the top of the set, not repeated in every row, as long as each row points at the set id. If the shot goal changes, start a new set. Do not quietly redefine the goal under the old id or earlier rejects will look incompetent when they were answering a different question.

Filename convention

The filename is the primary key you can see in a folder, a review link, and a chat paste. If the name is sloppy, the table will be sloppy, because people trust the file they can see.

Use this pattern:

{project}_{shot}_{route}_{variable}_{run}.mp4

Example:

northline-bottle_s02_i2v_still-v03_r04.mp4

Read it from left to right. Project, shot, route type, the variable under test, run id. A stranger can sort the folder and see the experiment without opening the spreadsheet first. That matters on a Friday when the reviewer only has the folder link.

Rules that keep the pattern from rotting:

• Lowercase letters, digits, and hyphens inside a field.
• Underscores between fields.
• No spaces.
• No words such as final, final2, new, test, good, or latest.
• The run id is r plus a zero-padded number. r01 through r09, then r10. Never reuse a number, even if the render fails.
• The route field in the filename is the short type, t2v or i2v, not a long marketing name.
• The variable field names the change: baseline, prompt-p04, still-v03, route, dur-6s, aspect-16x9.
• Put the calendar date on the folder, not necessarily in every filename: 2026-10-29/northline-bottle_s02_i2v_still-v03_r04.mp4.
• The filename run id and the table run id are the same id.

Aspect in a filename should avoid extra punctuation that some tools dislike. aspect-16x9 and aspect-9x16 are safer than ratios written with a colon. The table can still say 16:9, which is how people speak. The file can say 16x9, which is how folders survive handoffs.

Keep a second copy of the raw generator output under that name. If an editor later exports a cut, that export gets a different name and a pointer back to the generation run id. Do not overwrite the raw file with a graded, captioned, or cropped version and keep the same name. The log would then describe a file that no longer exists.

When a download name arrives as a random string from the product, rename the stored copy to the pattern and record both names if you need a paper trail: source_download_name as an optional column, filename as the project name. Do the rename the same day. Tomorrow the random string is meaningless, and two people will rename it differently.

Collision rule: if r04 already exists, the next render is r05 even when r04 failed, was void, or was a duplicate click. Gaps are acceptable. Reuse is not. Reuse makes a keeper and a reject share an identity, which is worse than a missing number.

One variable per run

One variable is the whole method. Everything else in this guide exists to protect that rule.

The variables that count for this notebook are:

• prompt version
• still version
• model route
• duration
• aspect

Hold the others still. If the shot also depends on an optional control that the screen exposes, such as a visible seed or an audio toggle, treat that control as a variable too. Add it to the parent checklist for that set. A hidden change to audio, seed, or an uploaded reference is still a second variable even if your main column looks clean.

A clean child row reads like this: parent r01, variable still version, from v01 to v03, prompt p01 unchanged, model route string unchanged, duration 6 seconds unchanged, aspect 9:16 unchanged.

A dirty row reads like this: "Tried a new prompt on the other model in horizontal because the client mentioned widescreen." That sentence contains a prompt change, a route change, and an aspect change. It might produce a file you like. File it as VOID. Then decide which single question is worth a real set.

Practical limits that teams can keep:

• One comparison set asks one question. "Does a new still fix the label?" is one question. "What is the best look?" is not a question this log can answer in a single set.
• Change the variable to a specific value, not to a mood. still-v03 is specific. "A cleaner frame" is a mood until it is a file with a version id.
• Do not fix a reject by changing a different layer in the same click. If the reject reason was subject geometry on still v01, the next comparable run changes the still, not the prompt, unless the set's question is the prompt.
• If the operator notices a typo in the prompt while testing stills, save the new wording as a new prompt version and stop. Do not attach it to the still test. Run it later as its own child of the same parent, or start a new set if the wording change is large enough to alter the shot goal.
• Two clicks that you believe are identical still get two rows. Outputs can differ when the route does not expose a seed. The second row's variable can be repeat, with parent set to the first, and a note that no intentional field changed. A repeat is how you learn whether a keeper was stable or lucky.

The repeat row is the most skipped row in production, and it is the row that saves the most argument. If r04 is a keeper and r06 is a repeat of r04 with every recorded field identical and the result falls apart, you do not have a method yet. You have one good file. Say that in the reason. Do not promote r04 into a template for the whole campaign until a repeat or a tightly controlled sibling supports it.

When a client or a stakeholder asks for three new ideas by the afternoon, you can still protect the log. Produce the explorations, mark them EXPLORE, pick one direction, and only then spend a short set on a single variable. The deadline pressure is real. The cost of skipping the set shows up later, when someone asks why the approved look cannot be reproduced on the next product color. That later question is more expensive than one extra baseline.

Prompt version

The prompt version is a pointer to exact wording. It is not a summary, a nickname, or a recollection of the theme.

Store prompts as immutable text files or immutable blocks in the project doc:

prompts/northline-bottle_s02_p01.txt

prompts/northline-bottle_s02_p02.txt

The generation row contains p01 or p02 only. The text file contains the wording that was submitted. If the product rewrites, expands, or translates a prompt before generation and shows you the rewritten text, store that submitted text as the version, and add a note if you also kept your shorter draft. The version that matters is the text the generator received.

Version rules:

• Any edit creates a new id. A changed adjective is a new version. A deleted sentence is a new version. A reordered list is a new version.
• Do not overwrite p01 because you "meant" the new sentence all along. The old file is the parent of runs already in the table. Overwriting it rewrites history.
• Keep punctuation stable. If you paste from a document that converts quotes or dashes, save the pasted result as a new version instead of claiming it matches the old file.
• Record a negative prompt or avoid-list as part of the same version, or as a paired id such as p04 with n02, if you use one. A change to the avoid-list is a prompt change.
• If the team uses a saved preset inside the product, record the preset name and the date you confirmed its text. Preset names get edited. A name without a captured text snapshot is not a version.
• Do not describe the prompt in the reason column and skip the version id. "The shorter prompt" is not an id.

The log should not become a prompt-writing class. You still need enough discipline to know which words were present. When a review argues about wording, open the version file. Do not reconstruct it from memory. If the version file is missing, the run is weaker evidence than its decision suggests, and the reason should say "prompt text not archived" rather than pretending the id is enough.

Large prompt rewrites belong in a new set when they change the shot goal. Small wording tests can be sibling runs under one parent. Either way, the row shows the version boundary. People who want to study wording craft can leave this notebook and use the prompt guides. When they return with a candidate paragraph, it enters as a new version id and earns its own runs.

A useful habit: the operator pastes the prompt into the version file first, saves it, and only then pastes that same text into the generator. The reverse order, editing live in the product and copying back later, creates drift. Later copy steps drop a line, or the product shows a trimmed preview. Generating from the saved file, or saving the exact submitted text immediately after, is the safer order. The row's prompt_version must match a file you can hash with your eyes: open it, read it, confirm it is the one you sent.

If two operators share prompt duties, add initials nowhere in the wording. Put the operator on the row. Initials inside the prompt text become part of the model input if someone pastes the wrong block, and they make diffs harder to read. The version id is the only suffix the prompt file needs.

Still source

Image-to-video animates a still. The still is not a vague reference mood. It is a file with pixels, a crop, and a history. Text-to-video rows record still_version as none. If a still was uploaded, the route type is i2v even if someone thinks of the job as "mostly a prompt."

Record at least:

• still_version id, such as v03
• filename, such as stills/northline-bottle_s02_v03.png
• origin: camera photo, approved design export, generated still, screenshot, or client asset
• preparation note: crop, background cleanup, retouch, or "uploaded as received"
• whether this file is the approved first frame for the shot

The preparation note can live in a still register, one row per still version, while the generation log only stores the version id. That split stays clean if the register is linked from the set. What must not happen is a still that exists only as "the one in Slack."

Still rules that protect diagnosis:

• A new crop is a new still version, even when the source photo is the same.
• A color correction that changes the label or the product color is a new still version.
• Re-exporting a design at a new aspect is a new still version.
• Do not replace v02.png with a better file and keep the name. Old runs point at v02. Create v04.
• If the generator also accepts an end frame or extra references, give each reference its own id. A second image is a second variable.
• Record the aspect of the still itself if it differs from the generation aspect. A square still forced into a vertical generation is a clue when framing fails.

First-frame quality is a design problem before it is a logging problem. Build the opening with AI video first frame design, then log the approved file as the still version you actually upload. When motion breaks the subject, the label, the hands, or the geometry, use AI image-to-video failure fixes to choose the next still or prompt test. The log's job is to show which still was present when the failure appeared, so the fix is applied to the right parent.

A common false trail: the team dislikes the motion, rewrites the prompt three times, and never records that all three runs used the same cramped still. The log makes that trail visible. If prompt p01, p02, and p03 all reject for the same subject problem on still v01, the next comparable run should change the still, not add p04 on instinct. That is diagnosis, not a new prompt theory.

Origin matters when rights or accuracy matter. A client product photo and a generated stand-in are different sources even if the composition looks similar. Write the origin on the still register so a keeper is not later treated as photography of the real product when it was a generated proxy. The generation row does not need a legal essay. It needs the origin label and the version id so the legal or brand review can find the source without reopening every render.

When the still is a screenshot of an interface, record the build or the date of the screenshot in the preparation note. Product UI changes. A later retest that uses a fresh screenshot is a new still version, even if the prompt asks for the same camera move. Teams often call both files "the app screen" and then argue about motion when the underlying screen content changed.

Store stills in a folder that is not the downloads folder of a single laptop. If the operator's machine is the only place v03 exists, the log is a map to a missing file. Shared project storage, with the same version ids, is part of the notebook.

Model route

The model route is the path you selected to generate that row: the product surface and the exact option label. Cliprise can route a shot through different available models from the AI video generator or the image-to-video generator. Which labels exist can change. The log is a history of the label you used, not a private catalog of what the product will offer next month.

Write the label as copied from the selector, including version or mode words if they are part of the name on screen. "The fast one" is not a route. "The cinematic one" is not a route. If two options share a family name and differ by a mode, the mode is part of the route string. Copy it.

Before a retest, look at the current models list. If the old label is still there, a new row may use it and point to the parent run. If the label is missing or renamed, do not edit the old row to match the new name. Add a retest row whose variable is model route, and write that the original route was unavailable on the retest date. The old keeper remains a historical file. It is not a promise that the same path can be clicked again.

Route rules:

• A text-to-video selection and an image-to-video selection are different route types even if the brand name on the model looks similar.
• Changing route is the variable for that row. Do not also "tidy" the prompt while you switch.
• Record the surface you used if you have more than one way to reach generation, so a later person does not hunt in the wrong part of the product.
• If a run includes separate voice, music, or avatar steps, log those as their own references or their own rows. A visual route plus an unlogged voice pass is two processes pretending to be one.
• Do not rank routes in this notebook with slogans. Rank only inside a set: under this parent, with these fields held, this route was kept or rejected for this visible reason.

The models page is where you check availability before you plan work. The log is where you prove what you already did. Mixing those jobs leads to articles and spreadsheets that invent a fixed menu. Your row should survive a menu change because it quotes the label from the day of the render.

If the team compares two routes, make them siblings of the same parent with the same prompt version, still version, duration, and aspect. Watch both files against the shot goal. A route that wins on a different still is not a route win. It is a void in disguise. This discipline is also what makes a later model choice teachable to a new teammate. They can read the set instead of inheriting a preference.

Write the route string in the table even if the filename only says t2v or i2v. Filenames stay short. The table holds the exact selector text, which may be long. Both are required. A short filename without the table is incomplete. A table without a file is a rumor.

Duration and aspect

Duration and aspect are generation settings. They are also easy to confuse with later editorial decisions. The log should record the request and, when you check, the file you received.

Duration notes:

• Write the setting you selected, in seconds, using the values the product offered. Do not write "short" or "long."
• If you have time to check the file, write the duration the player reports. If they differ, say so in the reason or in duration_file. A mismatch is a fact, not a failure of the operator's character.
• A test that changes 4 seconds to 8 seconds is a duration test. Do not also change the prompt to "slower" in the same run unless you accept a void, because the wording and the setting would move together.
• When the shot goal depends on a finished action, such as a lid settling, note whether the action completed inside the file. That observation belongs in the reason. It explains why a longer duration might be the next single variable.
• Different routes may offer different duration choices. If the sibling you wanted is unavailable on the new route, you cannot claim duration was held constant. Mark the row VOID or pick a shared duration both routes actually offer and make that the baseline.

Aspect notes:

• Record the generation aspect, not the aspect you hope to crop later.
• A 9:16 generation and a 16:9 generation are different tests even when the prompt text matches.
• If the still was composed for one aspect, changing only the generation aspect often punishes the framing. The reason should say the still's composition, not a blanket judgment of the route.
• A later editor crop, a safe-area shift, or a cover frame for a platform is export work. Log it in the edit notes with the generation run id, and follow the AI video export settings checklist. Do not go back and rewrite the generation aspect to match the cropped delivery.
• Filename codes can use 9x16 and 16x9. The table can use 9:16 and 16:9. Pick that mapping once and write it in the project header so the team does not invent a third spelling.

Duration and aspect feel like technical trivia until a landing page needs a horizontal hero and the only keeper is vertical. The log shows whether you have already tested horizontal with the same still and prompt, or whether horizontal would be a new question that also needs a new still. That single reading prevents a weekend of unrelated regenerations. It also prevents a producer from telling a client the horizontal version is "the same shot" when the still, the route, and the duration all moved.

If the product offers a resolution or quality control next to duration, copy it when it is visible. If it is not visible, write "not shown." Do not infer resolution from a full-screen preview. Previews are not files, and files get re-encoded later. The export checklist owns delivery size. The generation log owns the setting you were given at creation time.

Keeper and reject reasons

A decision without evidence is a preference. Preferences are allowed in exploration rows. They are not enough for a keeper that other people must extend.

Use a small code list and keep it stable for the project:

The code is for sorting. The sentence is for thinking. Write both.

Weak reason: "Motion bad."

Useful reason: "On still v01, prompt p01, 6 second 9:16 image-to-video, the bottle mouth stretches in the second half of the push. The label letters stay readable. Parent r01. Variable under test was prompt p02, and the stretch remains, so this does not support a prompt-only fix."

That sentence tells the next operator what to change. It also tells them what not to change. The label survived. The mouth did not. The prompt child did not remove the mouth problem. The next comparable variable is the still, unless a reviewer overrides the shot goal.

Keeper reasons should be just as concrete. "Looks premium" will not help a retest. "Slow push completes, bottle silhouette stable, label lines straight, no extra text in the image, pale table matches the shot goal" will. A keeper that cannot be described cannot be defended when a stakeholder asks for a small change.

HOLD is for disagreement or for incomplete watching, not for politeness. If the reviewer did not watch the file, the decision is not HOLD. The decision is blank, and the row is unfinished. A HOLD that sits for days blocks the set. The ritual section below treats open HOLD rows as the first agenda item so they do not become a quiet backlog.

REJECT-GOAL is the code for a pretty miss. The pixels may be calm and the product intact, yet the camera never moves closer, or the lid is open when the goal says closed. Those files are tempting to keep because they are clean. Keeping them changes the shot goal in secret. Either update the goal and start a new set, or reject the file against the goal you actually have.

One reason code per row is the default. If two faults are present, name the one that blocks the shot goal first in the code, and mention the second in the sentence. Multiple codes on one row make sorting look more scientific than the watch really was. The sentence can carry the extra detail.

Tie the reason to time when the player shows time. "Stretch begins just after 3 seconds in a 6 second file" is checkable. "Near the end" is weaker but still better than silence. Do not invent frame numbers you did not step through.

The reviewer watches with the shot goal open and the parent row visible. They do not watch a folder of random downloads and assign codes from memory of what the test was supposed to be. If the filename lacks a run id, the review waits until the file is identified. Guessing the run during review is how void rows become false keepers.

A keeper means "usable picture for this shot goal." It does not mean the marketing test is won, the legal review is done, or the export is ready. Hand the run id to the next notebook. The AI video generator for marketing workflow can place that usable picture inside a campaign plan. The ad testing workflow can define hypotheses and success measures. This log should not grow columns for click-through rate, audience, or offer strategy. Those columns invite people to change five creative variables and call the result a generation record.

Credit notes without a homemade price list

Credits are how Cliprise accounts for eligible generation on a plan. The figure for a given run is whatever the generation screen shows for that selection on that day. Your log should capture that observation. It should not become a second pricing page.

Write:

• credits_shown: the number copied from the screen before or after the run, labeled the way the product labeled it if the wording matters
• credits_date: the calendar date of that observation
• credits_note: optional short context, such as "shown before generate" or "balance decreased by this amount after a failed job"

Leave the cell as "not recorded" if nobody looked. Do not backfill a number from a different day, a different route, or a coworker's memory. A blank that says "not recorded" is more honest than a borrowed figure, because borrowed figures get quoted in planning meetings as if they were measurements.

Do not add a dollar column based on a ratio you computed offline. Do not paste plan prices into the generation log. When a producer needs to plan spend, open pricing and use the current plan and credit information there. Prices, included credits, and per-action costs move. A note from last month is an observation about last month's screen, not a quote for next week's work.

Use the credit column for relative review inside a dated period:

• Which sets consumed repeated attempts without a keeper?
• Did reject reasons cluster on stills, which means more still preparation might save repeats?
• Did void and explore rows dominate the week's recorded credits?
• Did a duration or route change show a different on-screen credit figure on the same day, under notes you actually copied?

Those questions improve the next week's plan. They do not require a fake rate card. If two routes showed different credit figures on the same afternoon, you may say that, because you copied both figures. If you only copied one, you may not infer the other.

Failed jobs need credit notes too when the balance moves or the screen displays a cost. Record REJECT-FAIL, the error text you can copy in one line, and the credit observation. If you did not see a balance change, write that you did not check, not that the attempt was free. Assumptions about refunds, retries, or failed-job billing do not belong in the row unless you are quoting something you saw in the product or on the current pricing terms that day.

Batch clicks are a common place to lose the thread. Ten outputs from one submit can display as one credit figure or as a figure that covers the batch. Copy what the screen showed, and write whether the figure was for the batch or for a single file if the interface makes that clear. If the interface does not make it clear, write "batch figure, scope not labeled" rather than dividing the number by ten in your head and recording the division as fact.

Credit notes also keep exploration honest. An EXPLORE afternoon can be creatively useful and still be a large share of the week's observed credits. The log lets a lead say, "We used the credits the screen showed on twelve unparented runs, then one comparison set produced the keeper." That is a production conversation. It is not a claim that a specific workflow is cheap or expensive in currency.

Teams sometimes want the log to forecast a month of production. Forecasting belongs with current pricing and with a count of planned baselines, siblings, and likely repeats. The historical log supplies the count and the reject pattern. The pricing page supplies the commercial terms. Keep those sources separate so a changed plan does not force you to rewrite old rows.

A comparison set you can actually read

This worked example is a production diagnosis for a landing-page hero, not an ad test. The shot id is s02. The shot goal is fixed for the set: a closed reusable bottle on a pale table, slow push closer, label geometry stable, no marketing sentence rendered inside the image, vertical frame. The team is not choosing a hook, an offer, or an audience. They are trying to learn why one render is usable and another is not.

The operator records a baseline and then children. Credit cells say "copied from screen" because this article does not invent costs. In a real table those cells would hold the integers the product displayed that day.

Set s02-set-a, sibling structure, parent r01.

r01, baseline, route type i2v, model route string copied from the selector, prompt p01, still v01, duration requested 6 seconds, aspect 9:16, decision REJECT-SUBJECT. Reason: label letters bend on the front of the bottle before the push really starts. The still register says v01 is a generated stand-in, cropped tight, prepared as the first upload of the day.

r02, parent r01, variable prompt p02, still v01 unchanged, same route string, same duration, same aspect. Decision REJECT-SUBJECT. Reason: label bend remains in the opening. The new wording did not remove it. This row is evidence against a prompt-only fix for this still, inside this set. It is not evidence that p02 is a bad prompt for every bottle.

r03, parent r01, variable prompt p03, still v01 unchanged, other fields unchanged. Decision REJECT-SUBJECT. Reason: same label bend, plus a slight camera drift the goal did not ask for. Two prompt children have now failed on the same still. The set has answered its first question. Further prompt siblings on v01 are optional, not required, before a still change.

r04, parent r01, variable still v03, prompt returned to p01, same route string, same duration, same aspect. The still register says v03 is a new crop with more space around the bottle and cleaner label edges, origin still the generated stand-in, prepared after the v01 rejects. Decision KEEP. Reason: slow push completes, label lines stay straight, bottle stays closed, no extra sentence appears in the image, pale table matches the goal.

r05, parent r01, variable model route, prompt p01, still v01, same duration, same aspect, route string copied from the other option tested that day. Decision REJECT-SUBJECT. Reason: label bend still present. Because the still was v01, this row does not show that the second route fails on a good still. It shows that switching route did not rescue v01. That is a useful, narrow conclusion.

r06, parent r04, variable repeat, all recorded fields identical to the keeper. Decision KEEP. Reason: label, closure, and push match the r04 description closely enough that the keeper is not a one-off in this pair. If r06 had failed, r04 would stay a keeper file but would lose its status as a stable setup.

Read the set in order and the method is visible. Prompt changes did not fix v01. A route change did not fix v01. A new still did, with the original prompt and route held constant. A repeat supported the keeper. Nobody needed a new theory of prompting to see that. They needed parents.

A void that almost entered the set.

During r04 the operator also tried a horizontal version with a rewritten prompt because a stakeholder walked by. That file looked attractive. It was saved as r07, variable noted as "aspect and prompt," decision VOID, with a keeper-like comment in the reason: "Nice horizontal, but prompt moved from p01 to p04 and aspect moved from 9:16 to 16:9, still v03. Do not cite against r04." The file can still be shown as a sketch. It cannot be used to claim that horizontal works with the approved setup. Horizontal needs its own baseline, likely with a still composed for 16:9. First-frame design comes back into play before that baseline is generated.

What the team does next.

They do not generate twenty more vertical prompts. The vertical shot has a keeper and a successful repeat. If the landing page also needs 16:9, they open set s02-set-b. The baseline of that new set uses a still built for the wide frame, a stated prompt version, one route, one duration, and the wide aspect. Children change one field. The old void r07 stays in the archive as a warning, not as a parent, unless they deliberately choose one of its ingredients and freeze the others.

This is the tone of a generation review. It sounds slower than spraying renders. It is faster than reconstructing a week from filenames called final-horizontal-new.

If you map the same story onto a sheet, the columns that do the teaching are parent_run, variable, still_version, prompt_version, decision, and reason. Hide those, and the remaining columns are just a download history. Keep them visible in the review view. Color can help, but color without the parent column still fails. A green KEEP on a void is how attractive accidents become false standards.

Notice what the team refused to conclude. They did not conclude that prompt p02 is useless on every product. They did not conclude that the second model route cannot film a bottle. They concluded only what the parents allowed. That restraint is the difference between a generation log and a pile of opinions with screenshots attached. When a new teammate joins, they can inherit the restraint by reading the set instead of inheriting a slogan about a model.

The stakeholder who liked r07 still gets a respectful next step. The file is in the archive with an honest void label. The next baseline for widescreen uses the part everyone liked, which was the wide framing, and rebuilds the missing controls around a still designed for that frame. The stakeholder sees progress. The operator does not pretend the accident was a method.

How to diagnose a clip from the notebook

Diagnosis is a reading order. Use it before you spend another credit on a hunch.

1. Find the file's run id from the filename. If the filename has no run id, stop and identify the file. Do not diagnose a mystery download.
2. Read the shot goal for that set. Confirm the decision used this goal, not today's revised goal.
3. Read parent_run and variable. If the row is VOID or EXPLORE, do not generalize from it. You may still like the picture.
4. Open the prompt version file and the still file. If either is missing, write that into the notes before you blame the route.
5. Compare only rows that share the structure you think you are using. Siblings compare to the same parent. A chain compares each step to its own parent, not the latest file to the first file in one leap.
6. Cluster the reason codes. Three REJECT-SUBJECT rows on the same still point at the still. Three REJECT-MOTION rows on the same still with different prompts may point at motion instructions or at a still that cannot support the move. The cluster is a hint, and the parent links are the proof.
7. Check duration_requested against duration_file when the complaint is timing. Check aspect against the still's own framing when the complaint is crop.
8. Only then choose the next variable and write the next row's parent before you generate.

Specific symptoms and the fields to read:

The product or label changes between takes. Read still_version first, then prompt_version, then model_route. If all three match and there is no visible seed, record a repeat row's outcome and accept that the route did not give you a lock. If the still version differs, you do not yet have a mystery. You have a still change.

Motion feels wrong but the subject looks right. Read the reason codes on prompt siblings. If you have not tested prompt or duration as a single variable, do that before switching route. If prompt siblings already failed and the still is crowded, go to first-frame design and failure fixes, then return with a new still version as the single variable.

A keeper cannot be repeated. Confirm every required field. Generate one repeat with variable repeat. If the product no longer lists the model route, do not force a substitute into the old row. Record route unavailable, and start a new comparison if a current route on the models page is acceptable for a retest.

Credits were spent and the folder is full of rejects. Sort reason codes. If REJECT-SUBJECT or REJECT-FRAME dominates, stop prompt spray and fix inputs. If VOID and EXPLORE dominate, the team did not run tests. They ran searches. Searches are allowed when labeled. They should not be described as iteration in a status report.

The client asks for the same shot in another aspect. Read whether any child already changed only aspect. If the still was composed for the old aspect, plan a new still and a new baseline. Offer the old keeper as the vertical master, not as proof that the wide version is approved.

Two reviewers disagree. Use HOLD and make them point at a timestamp and a shot-goal line. Disagreement that cannot point at the file is a goal problem. Clarify the goal, then continue the set. Do not average the disagreement by generating a compromise prompt that also swaps the route.

A failed job has no file. The row still exists, with REJECT-FAIL, the error line, the same parent and variable you intended, and the credit observation if you saw one. The absence of a file is not a reason to delete the row. Deleting failed rows hides the fact that the combination was already tried.

Someone edited the keeper. Find the generation run id in the edit notes. Confirm the raw file still exists under the logged filename. If the raw file was overwritten, the generation record is damaged. Restore from backup if you can, or mark the row "raw missing" so nobody treats the graded file as the generator output.

Bring this reading order to the review. A fifteen-minute meeting that follows it will retire more confusion than an hour of playing files in filename order. The meeting is not a creative brainstorm. If a new idea appears, write it down as a candidate variable for a later set. Do not generate it during the meeting unless the parent and the single change are written first.

When the diagnosis points at the still, leave the log long enough to improve the still, then come back and log the new version. When the diagnosis points at export, leave the log and open the export checklist with the run id in hand. The log's value is the handoff, not the insistence that every problem is a generation problem.

A short diagnostic note can be added under the set after the meeting, dated, with the run ids you relied on. Example: "2026-10-29: label bend tracked with still v01 across r01, r02, r03, and r05. r04 changed only the still and was kept. Next set, if any, is widescreen with a new still, not more prompt children of r01." That note is the memory the chat will not keep. It should quote run ids, not vibes.

If the note and the rows disagree, the rows win until someone corrects them with an explicit edit log. Do not silently repair a row to match a cleaner story. Add a correction note with the date and the reviewer's name. Historical messiness is allowed. Historical fiction is not.

Who writes the row, and when

The operator who starts the render owns the factual fields. They write them before they leave the generation screen, while the route label, the prompt, the still filename, the duration, the aspect, and the credit figure are still visible. A reviewer owns the decision and the reason sentence after watching the file. One person may wear both hats on a small team. The hats are still sequential. Facts first, verdict second.

Write the row at these moments:

• Before generate: run id, parent, variable, prompt version, still version, route label, duration, aspect, filename you will use.
• Immediately after the file exists: actual filename if the product renamed the download, duration_file if checked, credits_shown if not copied yet, storage location.
• After review: decision, reason, reviewer.

Waiting until the end of the day is how optional fields become fiction. The operator will remember the keeper and forget which child used p02. If the day is busy, the minimum viable capture before leaving the screen is parent, variable, prompt version, still version, route label, duration, aspect, and credits_shown. The reason can wait for review. The route label cannot wait.

Shared log etiquette:

• One project table, not a private sheet per person that gets merged "later."
• The incoming shift reads open HOLD rows and the active set before generating anything.
• Chat messages can point to run ids. They should not be the only place a variable is named.
• Do not let a stakeholder's aside become an unlogged regenerate. If you run it, you row it.
• Lock header names. Adding casual columns midweek is fine for optional notes. Renaming prompt_version to copy for one afternoon is not.
• The operator may not delete a row because the result was embarrassing. Mark REJECT or VOID and move on. The embarrassing row is often the one that explains the credit total.

A weekly production pass, separate from creative reviews, takes a short agenda:

1. Unfinished rows missing a route, prompt version, still version, or decision.
2. Open HOLD items.
3. New keepers and whether a repeat exists.
4. Reject clusters by code.
5. Void and explore counts versus sibling tests.
6. Sum of credits_shown for the week where the cells were actually copied, with dates, and a note that this sum is not a price.
7. The single next variable the team is willing to test, with its parent named in the meeting.

That agenda is operational. It should stay boring. If it turns into a debate about brand platform or media mix, move that debate to the marketing workflow and come back with a shot goal the log can serve. Boring agendas are a feature. They are what keep the notebook small enough to survive contact with a real week.

New teammates should log a supervised set of at least a baseline, one child, and one repeat before they log alone. The supervision is not about taste. It is about whether parent, variable, and version ids are correct. Taste can be taught in review. Broken parents cannot be repaired from taste.

If the team uses a producer to guard the queue, the producer's power is to refuse an unparented render that someone wants to call a test. They can allow EXPLORE when the time box is explicit. They can insist that a keeper gets a repeat before it is called the setup. That authority belongs in production management, and the log is how it stays visible instead of personal.

Remote teams should agree on one time zone label in the header, such as "timestamps in Europe/Belgrade local time," and still write the calendar date in ISO form, 2026-10-29. The agreement matters less than the fact that it is written. A row that says 9:00 without a zone will be sorted differently by two offices. Put the zone in the header once, and keep the date on every row.

Mistakes that make the log useless

Memory as a source. Writing rows the next morning from memory will invent route labels and prompt versions. Capture facts at generation time.

Shared filenames. final.mp4 on two machines becomes two different films. The run id in the name exists to stop that.

Silent overwrites. Replacing still v02 or prompt p01 destroys the meaning of every earlier row that cites it. New ids are cheap. Lost history is not.

Double changes with a clean-looking column. Changing the still and "only a few words" is two variables. Mark VOID or do not make the second change.

Goal drift. Judging Tuesday's rows by Wednesday's shot goal makes the log look random. Start a new set when the goal changes.

Export edits written back into generation rows. A captioned, cropped, or color-graded file is not a new model route. Point the edit at the run id and keep the raw generation file.

Ranking models from void rows. A route that won while the prompt and still also changed did not win a comparison. It won a scramble.

Using the log as a prompt course. Long essays in the reason column about how to write prompts hide the evidence. Keep craft discussion in the prompt guides. Keep the reason tied to what is visible in this file.

Using the log as an ad lab. Adding audiences, bids, and hooks to every row will tempt multi-variable chaos. Send campaign tests to the AI ad creative testing workflow.

Inventing prices from credits. Copy the on-screen credit figure. Do the commercial reading on pricing. A homemade dollar column will be quoted after it is stale.

Deleting failures. Failed and ugly rows explain why the next test exists. Archive them inside the same table.

Calling a search a test. EXPLORE is an honest label. Renaming it iteration in a status report trains the team to skip parents.

Backfilling credits. A credit figure copied from a similar route on a different day is not a measurement. Mark it not recorded.

Rewriting old route labels when the product menu changes. The old string is history. The new test is a new row.

Reviewing from a compressed chat preview. Decide from the stored file named in the row. Previews crop, compress, and sometimes drop audio. A reject based only on a preview should say so, or it should wait.

Letting the loudest file set the parent. The most exciting void is not the parent of the next scientific child. Freeze a real baseline first, even if it is plainer than the accident.

Any one of these mistakes can be repaired if you catch it in the same week and mark the correction. A log that pretends it was clean is harder to trust than a log that shows a dated correction. Trust is the product of this notebook. A clever filename pattern without trust is decoration.

The repair pattern is always the same. Stop generating. Mark the damaged rows with a correction note and the date. Create new ids for any prompt or still that was overwritten if you can still recover the old bytes. If you cannot recover them, the affected rows lose evidentiary status and the reason should say so. Then start a fresh baseline. Do not try to surgically continue a set whose parents no longer point at real files.

Batch runs, retries, and handoff to other notebooks

A batch that returns several files from one submit is not one result. Give each file a run id and a filename. They may share a batch id column so you can see they were requested together. They may not share a single keeper decision unless the reviewer watched each file and the sentence is true for each. In practice, watch them one by one and let the decisions differ. The whole point of a batch is that the outputs can differ, so the log should be allowed to show difference. If the product does not explain what varied inside the batch, the variable column can say batch-member and the parent can be the request row. Do not invent an internal seed story the screen did not show.

Retries after REJECT-FAIL copy the intended parent and variable onto a new run id. They do not reuse the failed id. If you change anything before retrying, the new row must say so. The most common silent change is a pasted prompt that lost a line. Open the version file and paste from it again.

Handoff rules keep this notebook small enough to live:

• To first-frame work: bring the still version, the reject code, and the shot goal. Return with a new still version id.
• To image-to-video fixes: bring the parent, the still, the prompt version, and the timestamp of the fault. Return with one recommended variable, not five.
• To export: bring the keeper run id and the raw filename. Leave with delivery files that point back to that id. The export checklist covers the publish file. The generation log does not grow codec columns.
• To marketing: bring keepers that meet shot goals. The AI video generator for marketing guide can sequence those shots into a plan. Testing hypotheses across audiences stays in the ad creative testing workflow.
• To a future retest: bring the route string, the version ids, and the date. Check models before assuming the route is still offered.

If a project already has a creative brief, the brief owns audience, offer, and claims. The generation log owns renders. Link the shot id in both directions. Do not paste the entire brief into every row. A shot goal of one or two sentences is the extract the log needs. When the brief changes the offer, the shot goal may change too, and a new set starts. Old keepers remain valid for the old goal. They are not automatically valid for the new one.

Client review can use the log without showing every column. Show the keeper, the baseline it came from, and the one-sentence reason. Keep void sketches in an appendix labeled as sketches. Clients can prefer a sketch. The team then rebuilds that preference as a baseline with controlled fields. That rebuild is the professional move the log makes easy to explain: "We can pursue this direction. We cannot yet say which single change produced it, so the next session freezes a setup and tests from there."

Store the table next to the media, with a backup. A log that lives only in one person's browser profile is a private diary. The project needs a location that the reviewer and the operator can both open. Permissions should allow the operator to add rows and the reviewer to add decisions, and should discourage silent edits to old prompt files. If your tool has a history, turn it on. If it does not, the immutable version-id rule is your history.

Close a set when the question is answered, not when the folder feels large. A set is closed when you have a keeper supported by a repeat, or when you have a documented stop, such as "still v01 cannot meet the label goal under the routes tried, and no new still is available this week." A closed set gets a one-line outcome at the top. Open sets should be few. A project with twelve open sets is a project with no parents, only activity.

Archive by project and month if the table gets long, but do not split a set across two files. The parent link must resolve. If you archive, leave a pointer in the active workbook: "s02-set-a closed, see archive 2026-10." The pointer is a row or a header note, not a chat message.

Names of people on the rows are there so questions have a destination. They are not there for blame. A REJECT cluster on one operator's rows often means that person drew the hard shot, not that they generated badly. Read the shot id before you read the operator. The log is a production instrument. Used as a scoreboard, it will be gamed, and gamed logs omit the void rows that managers most need to see.

Generation log checklist

Use this before you call a set comparable.

• The shot goal is written and has not changed inside the set.
• The baseline has a run id, filename, route label, prompt version, duration, aspect, and still version or an explicit none.
• Each test row names a parent and exactly one variable.
• Prompt text for every cited version is stored and was not overwritten.
• Still files for every cited version are stored and were not overwritten.
• Model route strings were copied from the screen, not nicknamed.
• Duration requested is recorded, and duration of the file is recorded when you checked.
• Aspect is the generation aspect, and later crops are not rewritten into that cell.
• Filenames match run ids and contain no final, new, or latest.
• Decisions use the shared codes, and reasons cite visible evidence.
• VOID and EXPLORE rows are labeled and are not used as proof.
• A keeper you intend to repeat has a repeat row, or the reason says the repeat is still missing.
• Credits shown were copied with a date, or marked not recorded.
• No dollar amounts were invented in the sheet.
• Failed attempts remain in the table.
• The raw keeper file still exists and matches the logged name.
• Export, marketing, and prompt-craft notes live in their own places and point back to run ids.

If a box fails, fix the record before you fix the creative theory. Many "model problems" are parent problems.

Print the checklist into the project header or the ticket template so it is present on the day someone is tired. A checklist stored in a guide and never in the project will be forgotten by the third rush. The guide explains why. The project copy is what gets ticked.

Where this notebook ends

Stop logging in this table when the question is no longer "what changed in the render." A caption rewrite in an editor, a music swap, a legal line, or a media-buy hypothesis is a different question. Link the run id and continue elsewhere.

Continue in these places when the log has done its job:

• Generate the next parent and child in the AI video generator, or start from a prepared still in the image-to-video generator.
• Check which routes you can actually select this week on models.
• Plan credit use on pricing without copying stale figures out of old rows.
• Design the still that image-to-video will animate with AI video first frame design.
• Untangle a broken animate step with AI image-to-video failure fixes.
• Deliver the keeper with the AI video export settings checklist.
• Place keepers into a wider marketing setup with AI video generator for marketing.
• Run structured creative tests with the AI ad creative testing workflow, using generation rows as the record of how each file was made.

The habit to leave with is small. Name the parent. Change one thing. Save the prompt and the still under ids you will not overwrite. Copy the route label and the credits the screen shows. Write why the file was kept or rejected in a sentence a stranger can verify. That is an AI video generation log. It is how a team makes tests comparable and how a later diagnosis stays possible.

When a keeper is ready for the next single-variable test, run that test in Cliprise and write the row before the screen changes. The clip is the media. The row is the memory.

Related Articles

• AI Video Generator
• Image to Video AI Generator
• Models
• Pricing
• AI Ad Creative Testing Workflow
• AI Image-to-Video Failure Fixes
• AI Video Export Settings Checklist
• AI Video First Frame Design
• AI Video Generator for Marketing