Reviewing a Generation Before You Reroll

The default reaction to a generation that comes back wrong is to press the button again. It is fast, it requires no thinking, and roughly a third of the time it works — which is exactly why the habit survives. The other two thirds, you have paid for a second render that failed for the same reason as the first, and you still do not know what that reason was.

The alternative costs one lightweight vision check and about ninety seconds of attention: ask the agent what is actually wrong, read the verdict, then change one thing. This post is that loop, written out, with the part most people get wrong called out explicitly — which is not the reviewing, it is the discipline of changing a single variable afterwards.

What the review step actually returns

review_generation is a self-QC pass. You hand it the generated image or video, its media type, and the original prompt, and it runs a vision check against what you actually asked for. What comes back is structured rather than conversational:

• matches_prompt — did the output do what the prompt said
• issues — the specific list, not a vibe
• severity — ok, minor, or broken
• suggested_fix — one concrete change

You can also pass a focus to point it at a particular concern, which is worth doing when you already suspect the problem. "Check whether the product label is legible" gets a more useful answer than an open-ended review that spends its attention on composition.

There is a second, looser tool for a different question. analyze_content takes a generation ID (or just latest) and critiques quality, composition and improvements, optionally against a target platform. Use that when the generation is fine and you want it better. Use review_generation when you gave a specific instruction and want to know whether it was followed. Getting AI feedback on a generation covers both entry points.

Both are vision checks rather than new generations, which is the whole economic argument for the loop. Versely deliberately does not run them automatically after every generation, because they carry their own cost and latency — you ask when you want one.

Severity is a routing decision, not a grade

The severity field is the most useful part of the output and the part people read as a score. It is not a score. It routes you to a different action:

Severity	What it means	What to do
ok	The output matches the prompt	Stop. If you still dislike it, the prompt was wrong, not the render
minor	Matches, with fixable defects	Edit the existing asset — do not regenerate
broken	Does not match the brief	Change one variable and regenerate

The ok-but-I-hate-it case is the one worth dwelling on. When the model did exactly what you asked and the result is still wrong, no number of rerolls will help, because every reroll re-executes the same instruction. That is a prompt rewrite, not a retry, and recognising it early is where most of the saved credits come from.

minor is the other one people misroute. A wrong colour, a bad crop, a legible-but-ugly label — those are edits. Editing or redoing a previous generation lets you push a change into an existing asset rather than rolling the dice on a whole new one, and it resolves references like "that last one" from your history so you do not have to hunt for a URL.

The one-variable rule

Here is the thing that actually makes the loop work, and it is not the review tool.

When a generation comes back broken, the temptation is to fix everything the critique mentioned at once — rewrite the prompt, switch models, bump the reference weight, change the aspect ratio. Do that and the next render either works or does not, and in both cases you have learned nothing transferable. You cannot attribute the outcome to any of the four changes, so the next time the same failure appears you are back to guessing.

Change one variable per attempt. The candidate list, roughly in order of how much they move the output:

1. The model. The largest single lever, and the one people reach for last. Different models fail differently; a prompt that a text-to-video model mangles may be trivial for another.
2. The prompt's structural claim — one shot versus two locations, subject versus setting. Text-to-video models cut badly when a prompt asks for two locations, so a "broken" verdict on a two-location prompt is usually a structure problem, not a wording problem.
3. The reference input. Adding, removing, or swapping the still that a model is conditioning on.
4. The wording of one clause. Smallest lever. Worth trying only after the first three are ruled out.

And one attempt that is not a variable change at all but belongs in the sequence: take two or three passes on the identical prompt before you change anything. Variance between takes on one prompt is usually wider than the difference between two prompts. If three takes of the same prompt all fail the same way, that is a real signal about the prompt. If one of them is fine, you were about to rewrite a prompt that worked.

When you do take a pass, keep the take with the right motion even if the details are wrong. Details are fixable downstream. Motion is not.

The loop, end to end

For a single generation that came back wrong:

1. Ask for a review against the original prompt, with a focus if you already suspect the fault.
2. Read severity and route: ok → rewrite the prompt; minor → edit the asset; broken → continue.
3. Take two more passes on the identical prompt. If one is usable, stop.
4. If all three fail the same way, change one variable from the list above and take one pass.
5. If that fixes it, write down which variable it was. That note is the actual deliverable of the whole loop.
6. Save the working version so the next round starts from it rather than from the prompt — saving generations to a project does not spend generation credits and skips URLs already saved.

For a long job — a workflow run, a multi-scene movie — run the review as a matter of course when it completes. That is exactly the case the tool is built for: the failure is expensive to have missed, and one vision check is cheap against re-running an eighteen-scene assembly.

When to skip the review entirely

The loop is not free and should not be reflexive.

Skip it when the generation is short and the fault is obvious — you can see the hand has six fingers; a structured verdict telling you the hand has six fingers has bought nothing. Skip it on the first take of a cheap model where a second pass costs less than the check plus your reading time. Skip it when you have already changed the prompt for a different reason, because the review will grade against a brief that no longer reflects what you want.

Run it when the job was long, when you are about to send the output to someone, when the same failure has now happened twice, or when you genuinely cannot tell whether the model ignored you or you asked badly. That last one is the highest-value case, and it is the one people are least likely to ask about.

What this is worth

The measurable version of the payoff is your reroll rate — the number of renders you pay for per shot you actually keep. Budgeting credits against the shots you throw away is how to measure yours; quality per credit is the cross-model version of the same question. Both get better from the same behaviour, which is not rerolling less — it is rerolling deliberately, with one thing changed and a note about what happened.

Before a long attempt, checking credits in the agent and asking for an estimate takes a few seconds and prevents the specific annoyance of a workflow stopping halfway. Every generation on Versely draws on the same credit balance whether it runs in the app or through an integration, and how credits work covers what moves the number on a given job.

If you would rather work from symptoms than from a tool's verdict, a diagnostic tree for generations that come back wrong routes from what you can see in the output to what to change. The two approaches converge on the same discipline: identify the fault, change one thing, keep the note.

FAQ

Does the review tool run automatically after every generation?

No, and that is deliberate. It carries its own cost and latency, so Versely offers it rather than running it — most usefully after a workflow run or a movie completes, or when a generation is clearly not what you asked for. You ask for it explicitly when you want it.

What is the difference between reviewing and analysing a generation?

review_generation grades an output against the prompt you gave and returns a match verdict, an issues list, a severity and a suggested fix. analyze_content critiques quality and composition and suggests improvements, optionally for a specific target platform, and does not need the original prompt. The first answers "did it do what I asked", the second answers "is this good".

How many identical rerolls before I change something?

Two or three. Variance between takes on one prompt is typically wider than the difference between two prompts, so a single failure is weak evidence about the prompt. Three failures with the same fault is strong evidence — at that point change one variable, starting with the model rather than the wording.

What if the review says the generation matches the prompt but I still do not like it?

Stop rerolling. The model executed the instruction, so every subsequent identical attempt re-executes the same instruction. Rewrite the brief instead — and be specific about the thing you disliked, because "make it better" reproduces the original with different noise.