Generative AI for fashion imagery: model, pose and clothing

Generative AI for fashion imagery is a narrow problem with a high bar. A general image generator can make a nice picture of "a person in a jacket". A fashion brand needs this jacket, on this model, in this pose, against this background, and it needs the garment to look like the real product down to the stitching. The interesting engineering is everything around the model that makes that repeatable.

Fashion Model AI is the project behind this post: it generates composed fashion images from model, pose, background and clothing inputs. I'll keep the generation technique general, because image models change every few months, and focus on the system design that holds up regardless of which model sits in the middle.

Treat a composition as structured data

The biggest early decision is how a request is represented. Free-text prompts are tempting and they fall apart fast: nobody can reproduce last Tuesday's image, and every user writes the same request differently.

I'd model each generation as a structured composition, where every input is a reference to a stored, approved asset:

import { z } from "zod";

export const Composition = z.object({
  modelId: z.string().uuid(),
  poseId: z.string().uuid(),
  backgroundId: z.string().uuid(),
  garments: z
    .array(
      z.object({
        garmentId: z.string().uuid(),
        slot: z.enum(["top", "bottom", "outerwear", "dress", "shoes", "accessory"]),
      })
    )
    .min(1)
    .max(5),
  aspectRatio: z.enum(["1:1", "4:5", "9:16"]).default("4:5"),
  seed: z.number().int().optional(),
});

export type Composition = z.infer<typeof Composition>;

That gives you a lot for free. Requests are validated before they cost anything. You can store the exact composition next to every output and regenerate or vary it later. Slot rules (one top, one bottom, or one dress) are enforced in code before the model ever sees them. And the UI becomes a set of pickers, which is what fashion teams actually want.

The asset library is the real product

Each input type is its own library with its own preparation rules:

• Models: reference images of the person, captured consistently. If real people are involved, their consent and usage rights are stored with the asset and checked before generation.
• Poses: a library of approved poses, so outputs match a brand's catalogue style.
• Backgrounds: studio colours, locations, seasonal sets.
• Garments: clean product photos, ideally flat-lay or on a mannequin, with the background removed.

Garment preparation deserves the most care. The output can only be as faithful as the input, so I'd normalize every upload on ingest: auto-rotate, resize to a standard working resolution, convert to a consistent colour space, and reject images that are too small or too blurry. That is ordinary server-side image work, and I cover it in image processing pipelines with Sharp and S3.

Generation is a background job

Image generation is slow and variable, often far longer than an HTTP request should stay open. Every composition should become a job:

1. Validate the composition and check asset permissions.
2. Insert a job row with status queued.
3. A worker resolves asset references to storage URLs, calls the generation service, and uploads outputs.
4. The job moves to review (or failed with a reason), and the UI updates.

Generating several variants per job is usually worth it. Users pick the best one, which is faster than regenerating one at a time. The queue pattern itself is in running slow AI jobs in the background with queues.

Consistency and garment fidelity

Fashion users notice everything. The failure modes I'd plan for:

• Garment drift: a logo that changes shape, a pattern that repeats wrong, a colour that shifts a shade. Colour is the most common complaint and the easiest to check automatically, by comparing dominant colours between the garment input and the output region.
• Identity drift: the model looks like a slightly different person in each image. Consistent reference images and fixed seeds for a campaign help.
• Anatomy errors: hands, fingers and limbs that are wrong in subtle ways. These are hard to catch automatically and are the main reason for human review.
• Pose mismatch: the output ignores the requested pose. Comparing pose keypoints between input and output is one way to flag these.

None of these checks needs to be perfect. Their job is to sort outputs into "probably fine" and "look at this one first" so reviewers spend time where it matters.

Keep a human in the loop for publishing

Generated images for a real catalogue should never go straight to a product page. A simple review queue (approve, reject, regenerate with notes) protects the brand and builds a dataset of what "good" means for that customer. Rejected outputs with a reason are the most useful feedback you will get. I describe review queues and approval flows in human-in-the-loop AI design.

Store everything needed to reproduce an image

For each output, I'd keep:

• The full composition (every asset ID and version)
• The seed and generation parameters
• The generation service and model version identifier
• The reviewer decision and any notes

When a customer asks "can we get the same shot with the navy version?", you swap one garment ID and rerun. When the underlying model is upgraded, you can regenerate a sample of past compositions and compare before switching everyone over.

Rights, disclosure and trust

Two non-technical points shape the technical design. First, likeness: if a composition uses a real person as the model input, their consent has to be recorded and enforceable, including revocation, which means you need to be able to find every output that used their asset. Second, disclosure: many brands and marketplaces now expect generated imagery to be labelled. Storing generation metadata from day one turns both of these into a simple query.

Where I'd start

Start with the asset libraries and a structured composition schema, and generate one variant per job behind a queue. Add the review queue before the first real customer sees an output. Automated quality checks come after that, guided by what reviewers actually reject.