From a marketing brief to a reproducible creative pipeline

XGen was an advertising and marketing content-generation platform. The useful output was a reviewable creative asset: the right subject, a controlled visual direction, an acceptable product representation and a clip that could enter the campaign workflow.

The retained project material includes design work, generated images and videos, a modular prompt library and embedded ComfyUI graphs. This series combines that historical evidence with an authored Nano Banana → Wan 2.1 reference implementation. Keeping those two strands explicit makes the technical story reproducible without inventing a deployment history.

The creative brief is the first data structure

A useful brief separates product identity from artistic variation. Product geometry, approved branding and mandatory claims should remain stable. Lighting, background, camera and motion may vary within the campaign’s direction.

The recovered prompt library separated categories such as camera, lighting, background and subject. That is a practical composition mechanism, but the final expanded prompt still needs to be recorded. Saving only a wildcard template cannot reproduce a particular output if its source lists change later.

The public examples use an invented bottle campaign. They preserve the engineering decisions while keeping original campaign prompts, personal likenesses and media out of the publication.

What the metadata audit recovered

We inspected 495 PNGs inside the retained archives. Of those, 240 had both prompt and workflow text metadata before their image-data chunk. The remaining files did not expose those fields at that location; this is not a claim that every possible metadata format was exhausted.

The graphs contain checkpoint and LoRA loaders, wildcard processors, samplers, face and hand detailers, comparison nodes, and upscaling/restoration paths. They reference SDXL, FLUX and later Wan 2.2 components.

The evidence supports a detailed record of configured experiments. It does not establish which unused editor nodes ran, the hardware that rendered each image, or the exact weight-file identity behind a local filename. Those questions require executed-node records, file hashes and run manifests.

Build around an approved keyframe

Video generation amplifies mistakes in the starting image. If the product is already misshapen, a motion model has no reliable instruction to restore the real object. Approving a still first is therefore a quality and cost boundary.

The reference pipeline has eight stages: validate the brief, generate or edit an image, approve it, prepare exact dimensions, generate motion, encode and finish, review, then publish the accepted artifact. Each stage produces an immutable reference rather than mutating a shared file in place.

Inspect the orchestration specification. It is an application-level JSON contract. The separate ComfyUI API graph is the node graph used within the motion stage; the two JSON formats serve different purposes.

Two image routes, one video contract

The managed image route uses Nano Banana through Google’s image API. The self-hosted route uses a compatible image model and local LoRAs. Both converge on an approved, prepared image with an asset hash.

Their controls are different. A local LoRA changes weights in a compatible model family. A managed image request supplies text and reference images through the provider’s supported API. There is no generic step that uploads an SDXL LoRA into Nano Banana.

After approval, the image-to-video stage can remain common. It receives the prepared image, motion prompt, model identity, dimensions, frame count and generation parameters. This keeps image-provider changes from silently changing the video contract.

Why Wan 2.1 and Wan 2.2 stay distinct

The requested reference uses Wan 2.1 I2V. Some recovered image-workflow metadata instead contains a Wan 2.2 low-noise model reference and a Wan 2.1 VAE filename. Shared supporting components do not change the identity of the diffusion model.

That distinction matters for adapters, schedules and reproduction. A LoRA trained for a different model or task is not interchangeable merely because both filenames contain “Wan.” Likewise, text-to-video and image-to-video checkpoints should not be selected only by parameter count.

The publication does not backdate the new graph. It is an independently inspectable implementation of the requested pipeline, grounded in the official model and ComfyUI interfaces.

The application owns the expensive state transitions

ComfyUI executes a graph. The product still needs job admission, tenant scope, budget limits, attempt ownership, retries, cancellation and durable artifact delivery.

A useful state sequence is queued → running → generated → reviewing → accepted with explicit failure and rejection states. Generation completion should not imply approval. A queue retry should not recreate an already completed clip simply because upload acknowledgment was lost.

Use unique prefixes for job and attempt artifacts. Persist the generation receipt before moving into review. A worker can then reconcile existing results after a timeout instead of starting another expensive GPU attempt blindly.

Reproducibility is more than a seed

The run record needs the expanded prompts, input image hash, checkpoint and adapter hashes, workflow hash, custom-node revisions, runtime, GPU, precision, seed and output hashes. Even with those recorded, bitwise reproduction can vary across kernels and hardware; the record still makes differences diagnosable.

The provided run manifest template leaves unknown measurements empty. Empty values should be filled from the actual worker, not replaced with plausible-looking historical numbers.

The following articles develop the image route, motion graph, LoRA registry, GPU workers and acceptance criteria. Together they turn a visually driven experiment into a pipeline whose inputs, costs and outcomes can be inspected.