An approval loop works on one assumption: each round produces information that makes the next round shorter. Send something, get a response, learn something, send something better. Three rounds converge.
Generated imagery can produce rounds that carry no new information, and when that happens the loop stops converging while continuing to feel productive. Everyone is busy, versions are circulating, and the distance to a decision is not shrinking.
That failure has a specific mechanism, and once you can see it the fix is small.
A round has to narrow something
The useful test for any round is what it eliminated. A sample photograph that shows a collar sitting wrong eliminates one construction. A supplier's note that a fabric cannot be sourced in that weight eliminates a direction.
Regenerating an image because the last one looked slightly off eliminates nothing. The same ambiguity that produced the first result produces the second, and the difference between them is variation rather than information.
Rounds that eliminate nothing are the ones to count. A loop that has run five times and eliminated two things is in worse shape than one that has run twice and eliminated two, even though the first looks more active.
Keeping that count visible changes behavior more than any rule. A thread annotated with what each round removed makes a non-converging loop obvious to everyone on it, including the person who has been sending versions without noticing that the last three answered nothing.
Why generated rounds fail to narrow
Three causes, and they compound.
The instruction did not change. Someone regenerates hoping for a better outcome from the same brief, which is a lottery rather than a step. This is the most common and the easiest to stop.
The feedback was aesthetic rather than specific. A response saying the shape is not quite right gives nothing to change, so the next attempt varies randomly around the same point. Specific feedback converges; impressions circle.
The ambiguity is in the source rather than the instruction. Where a base photograph does not resolve a detail, no instruction fixes it, and rounds spent trying are rounds spent on the wrong object.
One side got faster and the other did not
This is the structural problem in a sourcing context specifically.
A brand can now produce three versions in an afternoon. A supplier still needs to look at them, consult a technician, possibly check a fabric, and reply across a time difference. The brand's side of the loop compressed and the supplier's side did not.
The result is not acceleration. It is a queue at the supplier, and a supplier facing three versions with no indication of which matters will either answer the easiest one or answer all three shallowly.
Send one version per round with a stated question. It feels slower and it converges faster, which is the whole point of a loop.
The asymmetry is worth naming to the supplier as well. A supplier who understands that the volume has increased while the decision points have not will flag when they are being overloaded, rather than quietly reducing the depth of their responses — which is the failure mode nobody detects until a sample arrives wrong.
Change an input or do not send
The rule that fixes most of this fits in a sentence. No new round without a changed input — a different base photograph, a revised instruction, a specific piece of feedback acted on, or new information from the supplier.
Applied strictly, it kills the regenerate-and-hope round entirely. It also makes the loop legible: anyone looking at the thread can see what changed each time and therefore what has been eliminated. Keeping the assets in a shared library with the generation history means "what changed" is a lookup rather than a memory — the thread records the decision, the library records the input behind it.
Write the changed input into the message rather than assuming it is visible. A supplier receiving version three has no way to know what distinguishes it from version two unless someone says.
The rule has a second effect that is easy to miss. Being required to state a changed input forces the sender to establish that there is one, and a surprising proportion of proposed rounds fail that test at the point of writing. Those are rounds that never get sent, which is the cheapest possible outcome.
What each round should carry
| Element | Why | Cost |
|---|---|---|
| One version, not several | Prevents shallow or arbitrary responses | None |
| The specific question being asked | Converts an impression into an answer | One line |
| What changed since the last round | Makes elimination visible | One line |
| The status of the underlying sample | Prevents comment on a superseded version | One line |
| A note on what the imagery represents | Stops the picture being read as a spec | One line, reusable |
Five lines, most of them reusable between rounds. The discipline is in sending them every time rather than in composing them, since a template that gets skipped under deadline pressure is not a template.
The fourth row matters more in sourcing than elsewhere, because sample rounds and image rounds run on different clocks and a supplier commenting on imagery derived from a superseded sample is producing feedback that will have to be discarded.
Where the loop should terminate
Loops fail at the end as well as in the middle. A conversation that stays in imagery indefinitely is avoiding the step that actually settles things.
Set the termination in advance: imagery narrows the direction, and the physical sample decides. Once a direction is agreed, further rounds of imagery add polish to a question that has already been answered while the sample that would settle the remaining questions has not been requested.
Teams that name the termination point at the start have shorter loops than teams that discover it. Naming it also gives the supplier something to plan around, which is worth more than any single fast round — a supplier who knows a sample request is coming can begin sourcing rather than waiting for the imagery conversation to exhaust itself. Where the remaining variable is a material or a colorway rather than a construction, substitution from the approved base is a cheaper way to explore it than another sample round — swapping the fabric, color or style on the existing design — see Design with Purpose.
What no number of rounds resolves
Some questions do not converge because imagery does not address them, and recognizing those early prevents the longest loops of all.
The output is a visual asset. It does not predict fit, determine sizing, model how a fabric behaves in motion, or forecast returns. Those come from measurements, a graded pattern, a physical sample and your own data. A loop attempting to settle a fit question through imagery will run indefinitely and produce agreement rather than an answer.
Color has its own version of this. Screen color is not a physical reference, and a colorway discussion conducted entirely in images converges on a shared impression rather than on a standard. The strike-off governs, and no number of rounds substitutes for it. Worse, a shared impression feels like agreement, so both parties leave the conversation confident and unaligned.
Detail that the source photograph did not resolve is constructed rather than transferred, which means asking a supplier to confirm it from an image is asking them to verify something the image invented. Where that detail is the open question, send a photograph of the actual region instead — or rebuild that region against a reference and say plainly that it is a reconstruction, so the supplier is commenting on something real rather than on something invented. The AI Virtual Try-On module in Lightchain AI (apparel AI) produces the on-model output from an approved source, and what the source did not record is where these loops go wrong — see AI Virtual Try-On.
Questions sourcing teams ask
How many rounds is too many? Count eliminations rather than rounds. Two rounds that eliminated nothing are worse than four that eliminated three things, and the count tells you whether the loop is converging.
Should we send multiple versions to save time? No. A supplier facing several versions without a stated priority will answer shallowly or pick the easiest, and the round returns less information than a single version with a question attached.
What if the supplier's feedback is vague? Ask a closed question next time. Vague feedback usually follows a vague request, and converting an open comment into a specific choice is the fastest way to make a round productive.
When should we stop and request a sample? When the remaining questions are about fit, hand, color accuracy or construction, since none of those converge through imagery. Naming that boundary at the start shortens the whole process.
Can a supplier approve a colorway from an image? No. Screen color is not a physical reference and the strike-off governs. Imagery narrows candidates and does not settle a color.
What is the single most useful change? Refusing to send a round without a changed input. It removes the regenerate-and-hope round, which is the one that produces motion without progress.
Where the loop actually breaks
Not in the technology and not in the supplier. It breaks when rounds stop eliminating anything, which happens the moment someone regenerates without changing an input, and it is disguised by how fast and cheap those rounds are. Count eliminations rather than rounds, send one version with one question, state what changed, and name the point where imagery hands over to a physical sample. A loop run that way is shorter than it was before generation existed. Run the other way, it is longer and busier.
Add one line to your next round: what changed since the last.
**Send a single version, state the specific question you need answered, and say what input you altered to produce it. If you cannot name a changed input, the round is not ready to send. That one line converts a stream of versions into a sequence of eliminations, which is the only thing that makes a loop end. → **AI Virtual Try-On
About the author
[REPLACE — real person's name, role, relevant experience, LinkedIn URL. No team byline.]