Why a batch line needs a gate

Generation is the cheap part of on-model production. A frame costs cents and seconds; a line can produce 1,000 to 1,500 SKUs a week with every view per SKU without breaking stride. What is not cheap is a frame that is wrong in a way the client notices: the wrong model on a collection that locked a face, a styling piece that rode into the plain views, a garment generated from a detail crop instead of the hero photograph.

At small volume a human catches these before delivery. At batch volume the arithmetic runs the other way. Suppose the inputs are ambiguous on 2% of SKUs and the engine guesses. On 1,000 SKUs a week that is 20 wrong faces, found by the client's QC, each a regeneration, a re-delivery and a dent in the one thing a production partner is paid for. The guess rate does not fall with practice; it falls with a gate.

What the preflight reads

A preflight is a read of every SKU folder before anything is generated. It is not a quality check on output; it is a check that the inputs can produce the output at all. Ours reads twelve things, the same twelve that a client's QC has, at one time or another, written in red:

  1. One SKU, one folder, named by its code. The folder name is the only key the whole pipeline uses.
  2. The hero photograph is named, not implied. A detail crop filed as the hero produces a detail, not a look.
  3. Front and back both exist. A side or three-quarter helps on anything with a collar.
  4. The character sheet names one person. One identity per SKU, named the same way everywhere, references attached.
  5. The plain look and the styled look are separate. A scarf in the plain folder rides every view.
  6. Every worn piece has its own photograph. A folder name is not the object; socks filed under shoes are still socks.
  7. Styling facts are written, not implied: tucked, open, hem, legwear, sleeves.
  8. Notes agree with pictures. When they do not, the SKU is held, not generated on the note.
  9. Colour references are the brand's own photographs, one per garment in the look, with a tolerance.
  10. Lighting comes from one deck. Two documents that describe the light will disagree.
  11. The view list is explicit per SKU, including which way the three-quarter faces.
  12. Names, tree and marking are fixed before the run: file names, delivery structure, the uncorrected copy, the AI-provenance marking in every file.

The full list, with the way each rule fails, is a one-page checklist you can run on your own folders before you send a batch to anyone.

The three verdicts

Every SKU leaves the preflight with one of three verdicts, and the verdict is the whole point: it is a decision made before money is spent, with the evidence attached.

  • WILL GENERATE. Every input the look needs is present, named and consistent. The SKU runs without a question, and most SKUs in a well-kept batch are here.
  • CHECK FIRST. One fact is ambiguous: a sheet that could mean two models, a note that contradicts the photograph, a second garment with no reference. The SKU waits for one answer, listed on a shared sheet with the photograph that raised the question.
  • WILL NOT. An input is missing or two inputs contradict each other, and no answer short of a new file resolves it. The SKU is returned with the reason. Nothing is generated on a guess.

What the client sees: one page. The clean SKUs listed first in a line, then one row per held SKU prefixed STOP, CHECK or NOTE, with thumbnails of the photographs involved, and a sheet with one question per SKU. The client answers the sheet; the batch runs the same day. Nothing waits on a meeting.

The arithmetic of a held SKU

A held SKU costs one question and an afternoon on the client's side, usually less. A wrong face costs a regeneration on ours, a re-delivery into the client's tree, a note from their art director, and the suspicion that the rest of the batch has the same problem, which is the expensive part. On a batch of several hundred SKUs the second cost is paid several times over if the gate is missing, and once if it is there.

This is also why the preflight is the first step and not a sampling step at the end. A gate that reads inputs scales with the batch for free; a check that reads outputs scales with the number of frames, which at every view per SKU is five to eight times the number of SKUs.

How it fits the rest of the line

The preflight is the first of three gates, and each catches what the one before cannot.

  1. Preflight reads the inputs and holds the ambiguous SKU. It catches the wrong face before it exists.
  2. Measurement reads the output frame by frame: colour part by part against the brand's references, lighting against the deck, the three-quarter view against the facing rule. It catches the drift the eye forgives. How colour is measured against your references is its own article.
  3. A person looks at every frame anyway, because the instruments cannot see a print whose scale changed or a cast that sits only on the lips.

What it looked like on a real batch

A European e-commerce studio sent one week of production: flat lays, mannequin shots and character sheets, with their own lighting deck and their own product-page photographs as references. The character sheets used four naming schemes, so for 57 SKUs the engine could not be certain which model a sheet meant. All 57 were held with one question each, the studio answered the sheet, and none of the 57 became a wrong frame. The rest were delivered in 4K with every view per SKU in eight days, and when the art director's notes came back the batch was reworked and redelivered within seven. The case study walks through it; the gallery shows eighteen looks from two such batches.

The 57 were the good part. A supplier that generates on a guess ships a wrong face and finds out from the client's QC. A supplier whose engine is allowed to say no ships a question instead.

Frequently asked questions

What is a preflight check in on-model production?

A read of every SKU folder before any frame is generated, ending in one of three verdicts: WILL GENERATE, WILL NOT, or CHECK FIRST, each with its reason and the photograph that raised it. It checks the inputs a batch needs (one folder per SKU, a named hero photograph, front and back, a character sheet that names one person, styling separated from the plain look, written styling facts, notes that agree with pictures, colour references, one lighting deck, an explicit view list and fixed delivery names) and holds any SKU that fails one.

Why not generate anyway and fix the wrong frames afterwards?

Because at batch scale the arithmetic runs the other way. A line producing 1,000 to 1,500 SKUs a week with a 2% guess rate ships 20 to 30 wrong faces a week, each one found by the client's QC, each one a regeneration, a re-delivery and a dent in trust. A held SKU costs one question and an afternoon. Generation is cheap; a wrong frame in a client's tree is not.

What does the client see when a SKU is held?

A one-page report with the clean SKUs listed first, then one line per held SKU prefixed STOP, CHECK or NOTE, with the reason and thumbnails of the photographs involved, and a shared sheet with one question per SKU. The client answers the sheet; the batch runs the same day. Nothing waits on a meeting.

How long does preflight add to a batch?

Minutes per batch, not days: the scan runs on the folders as they arrive and the report is ready before the first frame would have been generated. The time it saves is the correction round that would otherwise follow delivery.

Can I run a preflight on my own folders before sending a batch?

Yes. The twelve rules are published as a one-page checklist, with the way each one fails, at jinkomage.com/on-model-production, and they apply to any supplier, not only to us. A batch that passes them is a batch that runs without questions.