A sourcing team works to a calendar built on when things arrive. The sample arrives, it gets fitted, comments go back, a revised sample arrives, and somewhere in that sequence the imagery gets made from something.
Generated imagery changes what happens when that sequence slips, and the change is not the obvious one. It does not let you skip a sample. What it does is let the imagery be produced before the sample confirms what the garment is, which converts a schedule problem into an accuracy problem and moves it downstream, where it is more expensive.
Virtually try on clothes work is worth having in this situation. It is worth having with one rule attached.
What a late sample actually breaks
| What was waiting on the sample | What a delay tempts you to do | Where the work actually goes |
|---|---|---|
| A direction decision: colorway, proportion, how it sits in the range | Photograph the proto and decide from that | Nowhere. This one is legitimate, and it is the reason the route exists |
| Product page and line sheet imagery | Produce it from the proto and treat it as the garment | Downstream, as a mismatch between the page and the parcel that every check passes |
| The fit session | Look at images and form a view | Nowhere. It waits, and an image-based view is an impression that delays the real one |
| Colorway sign-off | Approve from the screen because the lab dip is late | To the mill, as a shade nobody confirmed physically |
| The size set | Sign off on proportion from imagery across sizes | Into grading, unresolved, and it surfaces at the second fitting |
Reading the third column, the pattern is that a late sample does not remove work. It relocates it, usually from a controlled step into an uncontrolled one, and usually onto somebody who did not schedule it.
The one row where generated imagery genuinely helps is the first. The rows below it are where the trouble starts, because the same capability that helps with the first invites the others.
What it legitimately does when a sample is late
The useful case is narrow and real. A proto exists, it is close but not final, and a decision needs making about direction rather than about specification: which colorway to pursue, whether the proportion reads, how the piece sits against the rest of the range.
Photographing that proto and producing colorway and fabric direction from it is a legitimate use, because the question being asked is a direction question and the proto is adequate evidence for it. The decision gets made earlier, with less money committed, and the answer does not depend on the sample being final.
Nothing about that use requires pretending the proto is the production garment. It requires labeling it, which costs a word.
Where the trouble starts
The trouble begins when the same images move from answering a direction question to standing in for the garment.
A proto differs from production in exactly the ways that matter to a customer: the trim may not be the final trim, the fabric may be a substitute, the placement may shift, the hardware may be a stand-in. Imagery produced from it is accurate to the proto and wrong about what ships, and every downstream check will pass, because the on-model output genuinely matches the source it came from.
That is the specific mechanism to watch. The conformity check compares output against source and cannot tell you the source was provisional. Logos, printed text, care labels, and small hardware get compared against the source image on every single output, without exception, and a comparison against a proto's hardware confirms only that the proto's hardware was reproduced. Reconstructed detail lands almost right — a letterform slightly off, a stitch count wrong, a zipper pull the wrong shape — and a provisional source adds a second, larger error underneath a check that looks clean.
So the rule is a labeling rule rather than a prohibition: any asset derived from a proto carries that status with it, and it does not lose the label by being cropped, resized, or moved into a different folder.
The re-shoot decision nobody schedules
When the production sample finally arrives, somebody has to decide whether the imagery gets remade. That decision is almost never on a plan, which means it gets made by whoever notices, under time pressure, at the point where the assets are already in use.
Deciding it in advance costs one line per style. Re-shoot when the fabric changed, when a trim or hardware changed, when placement moved, or when the colorway was approved against a strike-off that differs from what was shown. Do not re-shoot for a difference in construction that is not visible, and record that decision rather than re-arguing it.
Where a single element changed and the rest of the garment did not, a targeted correction to that region is smaller than a full re-shoot and keeps a colorway set aligned. That is a genuine saving and it depends on knowing which element changed, which is a sourcing record rather than an image question.
In Lightchain AI (apparel AI) the uploaded source stays beside every AI Virtual Try-On output derived from it, which matters here specifically: when a sample lands and something has changed, the question is which published images came from the superseded source, and that is a lookup rather than an investigation.
What imagery cannot compress
The temptation with a late sample is to use imagery to buy back the lost time, and it is worth being exact about which parts of the lost time are recoverable.
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. So a fit session cannot be brought forward by generating images of the garment, and a size set cannot be signed off from imagery however good the proto photograph was.
Color is the same. Screen color is not a physical reference, exact code matching is not something to promise, and the gap between a monitor and a roll of cloth stays open regardless of display quality. Colorways get settled by strike-offs against an agreed standard, so a late lab dip is not recoverable by showing the colorway on screen, and a colorway shown before the strike-off is a direction.
Two scope answers matter for planning. Footwear is not covered by this class of workflow, and that is structural. Lace and open work, sheer fabrics, complex prints, and heavily layered looks are documented weak spots, so a late sample in one of those categories does not become a candidate for this route just because the schedule is tight.
What imagery does compress is the direction decisions, and those are worth compressing. What it does not compress is anything that requires the physical garment, and a late sample is precisely a shortage of the physical garment.
Setting the rule before the season
The whole thing reduces to a few decisions that are cheap in advance and expensive during.
-
Label anything derived from a proto at the moment it is created, and require the label to travel with the file rather than living in somebody's memory
-
Write the re-shoot triggers per style before the season: fabric, trim or hardware, placement, and colorway against strike-off
-
Decide who is told when a production sample differs from the proto, since that person is the one who has to find the affected assets
-
Keep the direction decisions and the specification decisions in different documents, because a late sample is exactly when they get merged
-
Record which styles went out on proto-derived imagery, since that list is what you check first if something is reported
Across a catalog at scale the last item is the one that pays. A single list of proto-derived assets turns a vague worry into a bounded set. Whether the work runs through Lightchain AI or a camera, a late sample is a sourcing problem, and imagery can carry a decision forward without being asked to carry a garment forward.
Frequently asked questions
Can we launch on proto-derived imagery if the sample will not arrive in time?
It is a commercial decision rather than a technical one, and it should be made with the differences named rather than assumed away. List what is provisional — fabric, trim, placement, colorway — and decide against that list. Launching without naming them is the version that produces a problem nobody can locate later.
How do we label proto-derived assets in practice?
As a state field travelling in the record and the message rather than in the filename, since filenames get rewritten. The same field that carries proposal, selection or confirmation elsewhere can carry proto or production here. One word, attached at creation.
The sample arrived and only the buttons changed. Do we re-shoot?
If the buttons are visible, that is a re-shoot or a regional correction rather than a judgment call, since a customer comparing the parcel to the page will see them. If they are not visible in any published image, record the difference and move on. The test is visibility rather than significance.
Does this apply to line sheet imagery for buyers?
Yes, and with more at stake per decision, since a buyer plans an order around what they were shown. Proto-derived assets going to a buyer should say so on the sheet. A buyer who learns later that the fabric changed is being told after they committed.
Who should own the re-shoot decision?
Whoever holds the sourcing record, since the decision depends on knowing what changed rather than on looking at images. Give the trigger list to that person before the season and the decision becomes a check rather than a discussion.
We are always working from protos. Is that unworkable?
It is workable with labeling and a re-shoot trigger list, and unworkable without them, which is a process difference rather than a difference in how you source. Teams that operate this way routinely need the record more than teams that do not, because the affected-asset list is longer.
In closing
A late sample does not remove work; it moves it somewhere less controlled. Generated imagery genuinely helps with the direction decisions in that window, and it cannot help with anything requiring the physical garment, which is what a late sample is short of. So the useful arrangement is narrow: use proto-derived imagery for direction, label it at creation, write the re-shoot triggers before the season, and keep a list of which styles went out on it. The last item is what turns a later surprise into a bounded check.
Start here
Write the four re-shoot triggers on one line and send them to whoever holds the sourcing record: fabric, trim or hardware, placement, colorway against strike-off. Then ask for a list of styles currently published on proto-derived imagery. Most teams find the list exists in nobody's head as a list, only as individual memories, and assembling it is the whole exercise. Do it before a sample lands rather than after one does.
**Start with the on-model workflow → **https://www.lightchainai.com/global/solutions/aiVirtualTryOn