A vendor sends a buying team forty images for eleven styles. Every one of them is good. Nobody asked for forty, nobody can say which eleven are the current ones, and by Thursday somebody has built a line sheet from a file that was superseded on Monday.
Ask a buying team what generated imagery cost them and the answer is rarely a bad picture. It is the afternoon spent working out which picture. AI try on made the marginal image close to free for the people producing them, and free production on one side of a relationship becomes unpaid sorting on the other.
So the question worth settling is not how to make more assets available. It is which files have to travel, at which point, and what has to be attached to them when they do.
A buying team's cost is adjudication, not absence
Missing files announce themselves. Somebody asks, somebody sends, the gap closes in an hour. Surplus files do not announce themselves at all — they accumulate, they look helpful, and they generate a decision every time anyone opens the folder.
That asymmetry is why sending everything feels generous and lands as work. Ten variants of a jacket do not give a buyer ten options; they give a buyer one question they were not asking and no basis on which to answer it. The vendor already knows which one is current. That knowledge is the thing the buyer needed, and it is the one thing that did not get sent.
A fixed manifest solves more of this than any naming convention will. Agree what travels at each stage, keep the list short enough to recite, and let everything outside it stay where it was made. The discipline costs the vendor a decision they were going to make anyway, several weeks earlier than they wanted to make it.
What travels at each stage
| Stage | What travels | What stays with the vendor |
|---|---|---|
| Line review and range build | One on-model image per style per proposed colorway, marked as a proposal, carrying the style and colorway codes | Every unchosen variant, every alternative model or pose, everything still in progress |
| Selection and order | The chosen image marked as a selection, the flat or line drawing, and the spec version in force | Anything showing a colorway that was not selected, however good it looks |
| Sample and confirmation | The physical sample, and the image reissued as a confirmation once it has been checked against that sample | Photographs standing in for the sample, which stop traveling the moment a sample exists |
| Channel onboarding | The confirmed master and the derived channel version, traceable back to the master | Any file that has not passed the detail check against its source |
Two things about the table are worth stating outright. The chosen image travels alone at every stage — never as a set with the runner-up attached, because a runner-up in a buyer's folder is indistinguishable from an alternative under consideration. And the physical reference stops traveling as a photograph the moment a sample exists, because a sample outranks any image of one and keeping both in circulation invites somebody to prefer the picture.
When a vendor works inside a single environment, holding to a manifest gets easier rather than harder. Lightchain AI (apparel AI) keeps generated outputs, their source files, and the history that connects them in one place, so restricting what leaves does not mean losing what stayed. The variants nobody chose remain retrievable without sitting in a buyer's inbox.
Identity does not travel inside the file
A filename is not an identifier. It survives one download, gets rewritten on the second, and carries no meaning to a system that runs on style codes. Any image that arrives without a style code, a colorway code, a season, and a state is orphaned on arrival, and an orphaned asset gets re-requested, re-sent, or re-created — usually all three across a season.
State is the field teams forget, and it does more work than the rest combined. An image is a proposal, a selection, or a confirmation, and those three carry different permissions. A buyer can share a confirmation with allocation and cannot share a proposal with anybody. Sending the same file with the same name at all three stages destroys the distinction entirely.
Generated workflows make this sharper because volume rises faster than any convention can absorb. A team producing on-model output through AI Virtual Try-On will have more files per style than a photo shoot ever produced, and the answer is not a longer filename. It is that the four identity fields live in the record and the message, where they cannot be renamed away, and the file is the attachment rather than the message.
What must not travel
The exclusion list is shorter than the manifest and does more of the work.
-
Variants that were not chosen, at any stage, for any reason
-
Any output that has not had its details checked against the source image
-
Any image offered as evidence about color
-
Anything a buyer could forward to a marketplace or a wholesale portal without a further decision
The second item has no exceptions attached to it. Logos, printed text, care labels, and small hardware get compared against the source image on every single output before that output leaves. Reconstructed detail lands almost right — a letterform slightly off, a stitch count wrong, a zipper pull the wrong shape — and almost right passes a buyer's review, reaches a channel, and gets found by a customer.
The third deserves its own line in the manifest. 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 does not close with a better display. Colorways get settled by strike-offs against an agreed standard, and values must never be read off a generated asset and carried forward. A colorway direction can travel as a shortlist if it is labeled as one; it cannot travel as a color.
What an image cannot decide for a buyer
Every file in the manifest supports a decision, and it is worth being exact about which decisions are not among them. 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.
For a buying team the sharpest consequence is the size curve. It cannot be read off imagery, however convincing the imagery is, and it does not become readable when there are more images. The curve comes from the measurement chart, the grading, the fit session, and the history of what sold through in that category. An image can show you what a style looks like at a given size and tells you nothing about which sizes to buy.
The same holds for the number a buyer is most often held to. Return-rate expectations come from the sizing chain and from your own sales history, not from how a garment renders. A range built on the assumption that better imagery will move that number has made a commitment nothing in the asset can support.
One master set, and versions derived from it
Channels will each ask for something different: aspect ratios, background rules, minimum resolutions, model policies, file naming. The failure is letting whichever channel asked most recently define the internal set, so the master drifts toward a marketplace specification and every other channel becomes a special case. Aspect ratio and output resolution belong to the derivation step rather than the master: both are configurable, and 2K or 4K output means a channel version is produced from the master you already checked instead of regenerating it to satisfy a channel rule.
Keep one internal master per style and derive from it. Derivation is cheap and reversible; regeneration is neither, because a regenerated asset is a different image and has to go back through the detail check.
-
One owner for the manifest, named, on the vendor side
-
One review of the manifest a season, timed after onboarding rather than before, so the revisions come from what actually broke
-
One place where the master and its derivatives live, so a channel version can be traced back to the master it came from
-
One rule that channel requirements never edit the master, only the derivation step
None of this requires a system. It requires somebody to write the manifest down and somebody else to be allowed to refuse files that arrive outside it. In practice the refusal is the hard part, which is why the manifest has to be agreed with the vendor rather than announced to them. A manifest one side wrote is a preference. A manifest both sides signed is a filter, and the filter is what buys back the afternoon. Lightchain AI or a camera makes no difference to that; the discipline sits in the agreement, not in the tool that produced the file.
Frequently asked questions
Our vendors send what they send. How do we change that?
Ask for the manifest to be part of the vendor agreement rather than a request in an email thread, because a stated file set is easier to hold to than a stated preference. Start with the two or three vendors who send the most and let the improvement be visible before extending it. Vendors generally welcome it, since a short list is less work for them too.
Is it not safer to have every version in case something changes?
Retrieval is the vendor's job and adjudication is yours, and keeping every version moves their storage problem onto your decision-making. The unchosen variants still exist and can be sent within the hour if a decision reverses. What you gain by keeping them locally is negligible; what you lose is the ability to tell current from superseded at a glance.
What state should an image have during line review?
Proposal, and it should say so in the message rather than in the filename. Proposals must not leave the buying team, must not reach allocation or a channel, and must not be used to build a line sheet that anybody outside the room will see. The moment a style is selected, the vendor sends the same image again with the state changed, which is cheap and unambiguous.
Can we use generated imagery to brief allocation?
For visual reference, yes, with the state marked as confirmed and the style code attached. For anything numeric — the size curve, the depth, the store grade — no, because none of that is present in an image and imagery in an allocation pack invites it to be inferred. Keep the numbers in the documents that hold them.
A vendor sent us a marketplace-ready file. Can we upload it?
Only if it went through the detail check and the state is confirmed, and only after somebody has verified it against the channel's current requirements rather than the version in the vendor's template. A file described as marketplace-ready is a claim about format and not about accuracy. The check that matters is still the one against the source garment.
Who should own the manifest?
The vendor, with the buying team's agreement, because the vendor is the only party who knows which file is current at the moment of sending. Ownership on the buying side produces a list that describes what buyers wish they received. Ownership on the vendor side, agreed rather than imposed, produces one that describes what can actually be sent.
In closing
The volume problem in buying is not caused by bad imagery, and it will not be solved by better imagery. It is caused by files arriving without identity, without state, and without anybody having decided what belongs in the set. Agree a short manifest per stage. Attach the style code, the colorway, the season, and the state to the message rather than the filename. Keep unchosen variants on the side that made them. Then the images that reach a buyer are the ones somebody meant to send, which is the entire ask.
Start here
Take one vendor and one style currently in review, and list every file you have received for it. Sort the list into three piles: files that supported a decision, files that created one, and files you cannot identify at all. The second and third piles are the manifest you never agreed. Write down what should have arrived instead, send that list to the vendor as a draft rather than a policy, and let the next style be the test of whether it holds.
**Start with the on-model workflow → **https://www.lightchainai.com/global/solutions/aiVirtualTryOn