Recording a ComfyUI run

October 2026 · About the ComfyUI and IPTC bindings

Open a PNG saved by ComfyUI and you will find the whole run inside it. The Save Image node writes the graph exactly as it executed, with every node, every setting and every link, into a text chunk in the file. A second chunk holds the editor layout. Drag the PNG back into ComfyUI and the run reopens, ready to go again.

That makes ComfyUI's saved image the most complete record of an AI generation in everyday production use. Most tools that generate media keep far less, and few keep it in the file.

A production needs that record to do more than it was built for, though.

What a production asks of it

Picture a cleanup shot. An artist takes a live-action plate with a boom mic in the window reflection and paints it out with an inpainting model. A depth pass keeps the geometry and a lookbook still keeps the look. A LoRA trained on the show's other shots does the rest. A sky from a hosted model goes in behind, and a film-grain node finishes it. The PNG on the artist's disk says all of that, in ComfyUI's terms.

Three months later, other people need answers from it:

• Legal needs to know whether the shot contains generated content and which systems made it.
• The compliance team needs a machine-readable label for the delivery.
• The VFX supervisor needs to know which plate it came from and whether that plate was the approved one.

By then the PNG has usually been through a review platform that stripped its metadata. Even with the chunks intact, they never said who ran the graph, for which production, from which approved plate, or what happened to the image next.

So a production record of a ComfyUI run has to:

• keep everything ComfyUI wrote;
• connect it to the work around it;
• and say what it says in the terms the rest of the industry already reads.

How it fits OWG

The mapping is small, because OWG already had the pieces. One run becomes one task with the comfyui_graph executor, which the generative-AI profile has defined since v0.9.

• The task's interior is the executed graph, kept whole. ComfyUI's editor layout travels with it.
• What the graph loaded becomes the task's inputs, as assets: checkpoints, LoRAs, ControlNets, plates, mattes and reference stills. The output's lineage runs back to the plate it was painted on and the model that painted it.
• The output is labeled in IPTC terms. That means the Digital Source Type vocabulary that C2PA, IPTC photo and video metadata, and JPEG Trust all share, plus IPTC's four AI properties: which system, which version, which prompt, and who wrote the prompt.

The full mapping is on the ComfyUI and IPTC binding pages. None of it needed a schema change. Every document described here validates against v0.92.

Two test runs

We built two runs to test the mapping.

The first is ComfyUI's stock SDXL text-to-image graph. The second is the cleanup shot described above:

• a Flux inpaint of a plate through its matte, steered by a depth ControlNet and a style reference;
• two LoRAs, one of them set to zero;
• a second pass at low denoise, then a model upscale;
• a hosted model's sky composited in through a second matte;
• a grain node from a third-party package;
• a preview output alongside the saved one.

Both are synthetic, and ComfyUI itself checked and wrote them. ComfyUI 0.37.0 validated both graphs against its installed node definitions, and its own Save Image node wrote the PNGs. The metadata is exactly what ComfyUI produces. Only the pixels are placeholders, because nothing was rendered. The simple run is published as the reference workflow, along with the PNG it was read from.

The simple run recorded what you would expect: the checkpoint, prompt, negative prompt, seed, sampler, scheduler, steps and size. Its output was labeled trainedAlgorithmicMedia, made new by generative AI.

The composite is where the record has to make judgments. It came out labeled compositeWithTrainedAlgorithmicMedia, an edit of existing material, and its lineage leads back to the plate. Getting there surfaced six things a record of a run has to get right.

What the composite taught

A graph can have no negative prompt and still look as though it has one. Flux takes no negative prompt. The graph satisfies nodes that expect one by passing a zeroed copy of the positive conditioning. Follow that link naively and the record states a negative prompt identical to the positive, which nobody ever wrote. The rule: zeroed conditioning means no negative prompt.

The pass that ran last is not the pass that made the image. After the inpaint, a second pass at 0.35 denoise refined the result with its own seed. Reporting that pass's seed and steps as "the" settings would describe a touch-up. Every pass is recorded, and the summary leads with the one that created the content.

One frame can contain two AI systems. The inpaint ran on a local model, and the sky came from a hosted one. IPTC's AI System Used and Prompt Information name both, with the local model first. A label that named only one would be wrong in a way an auditor could find.

A LoRA at zero strength changed nothing. It was in the graph and it was loaded, but it had no effect on the image. It is recorded among the run's inputs and left out of the list of things that shaped the output.

Not every node can be read, and a record should say so. The grain node came from a package the reader did not know. It is recorded by name, package and version, and flagged as not interpreted. Had nothing in the graph shown whether AI was involved, the task's AI role would have been left unset for a person to review, never set to "none". OWG's compliance rule R1 exists for exactly that case.

A file name does not identify a model. ComfyUI refers to models by file name. A LoRA called shot42_lookdev_v3 can be retrained and saved under the same name, so a record that trusts the name can quietly become wrong. Where the file is held, its content hash is the identity.

The first three were caught by these test runs, in a reader we had already tested and believed correct. That is the case for testing with output written by ComfyUI itself.

What changes in OWG

Everything above works on v0.92 today, using conventions set on the two binding pages. The v0.93 draft, now published for review, makes them part of the specification:

• A typed asset.iptc field replaces the metadata.iptc convention. A new validator rule, OWG_IPTC_AI_MISMATCH, reports an asset whose Digital Source Type contradicts the AI role of the task that made it.
• Version 1.1 of the generative-AI profile gives the sampling passes, LoRA strengths and control inputs typed fields, and accepts the graph either inline or by reference.

Both are additive. The changelog lists every change in v0.93, and the schema and profile are published.

Try it

If you run ComfyUI in production, the useful test is whether the record above is the one your legal, compliance and VFX teams would need to find later. Feed it your own runs, the strange ones in particular. Start with the ComfyUI binding and the reference workflow.