ComfyUI Provenance: A Complete Capture Guide

Saving a ComfyUI workflow JSON doesn’t mean you can reproduce its output. There are at least 17 distinct variables that determine what a ComfyUI generation looks like—and the default workflow export captures fewer than half of them.

If you’ve read our companion piece on why Git isn’t enough for ComfyUI versioning, you know that file-level tracking misses the semantic relationship between workflows and outputs. This guide picks up where that one leaves off: here, we catalog every variable that affects reproducibility and show what a complete provenance record actually contains.

Why “Save Workflow” Isn’t Provenance

ComfyUI’s built-in workflow export is genuinely useful. It serializes your node graph—connections, parameter values, prompt text—into a JSON file you can reload later. Many users treat this as their documentation strategy.

Here’s the problem: reload that same workflow on a different machine, or even on the same machine three months later, and you may get a visually different output from an identical seed. The workflow JSON captures your intent. It doesn’t capture your environment.

Provenance means recording everything required to explain why a specific output looks the way it does. That includes the obvious parameters, the non-obvious environment state, and the completely hidden execution context. I think about this in three tiers.

Tier 1: The Parameters Everyone Tracks

These are the values visible in ComfyUI’s node interface. Most teams capture them, at least informally.

• Positive and negative prompts: The text conditioning that steers generation.
• Seed: The random number initializing the latent noise. Same seed + same everything else = same output.
• CFG scale (classifier-free guidance): Controls how aggressively the model follows the prompt. A shift from 7.0 to 7.5 changes composition, not just detail.
• Steps: Number of denoising iterations. More steps don’t always mean better—but different step counts produce different images at the same seed.
• Sampler and scheduler: Euler, DPM++ 2M, UniPC—each implements the denoising math differently. The scheduler (normal, karras, exponential) shapes the noise reduction curve.
• Resolution (width × height): Not just an output detail. Resolution changes the latent tensor dimensions, which changes what the model “sees” at each step.
• Denoise strength: For img2img and inpainting workflows, this controls how much of the original image survives.
• Checkpoint model name: Stable Diffusion 1.5, SDXL, a fine-tuned merge—the model file used.

If you’re only tracking these eight variables, you’re covering roughly what a casual screenshot-and-notes approach captures. And that matters because these are the parameters people change intentionally. The reproducibility failures come from the things people don’t change—or don’t realize changed.

Tier 2: The Variables Teams Overlook

This is where most “I can’t reproduce my old result” problems originate.

Checkpoint File Hash, Not Just Name

Model files get updated, replaced, or corrupted. Two files named dreamshaper_v8.safetensors can have different weights if downloaded from different sources or at different times. Record the SHA-256 hash of every model file loaded.

VAE Version

The Variational Autoencoder decodes the latent image into pixel space. ComfyUI lets you use the checkpoint’s built-in VAE or an external one. Different VAEs produce different color profiles and detail levels from identical latents. The shift from SD 1.5’s default VAE to the community vae-ft-mse-840000 VAE is well-documented—same seed, same model, noticeably different color saturation.

LoRA Files, Weights, and Load Order

Each LoRA modifies the base model’s weights. Loading LoRA-A at strength 0.8 then LoRA-B at 0.6 can produce different results than the reverse order, because each LoRA modifies weights that the next LoRA reads. Record: file name, file hash, strength, and position in the chain.

ControlNet Models and Preprocessor Settings

If your workflow uses ControlNet for pose, depth, or edge guidance, the specific control model version and preprocessor parameters (resolution, threshold values) all affect the output.

Custom Node Versions

This is the single most overlooked variable in ComfyUI provenance. Custom nodes are installed via git repositories. They update independently. A node author’s bug fix or optimization can change numerical output without changing the node’s interface. The git commit hash of every custom node at generation time is part of your provenance record.

Tier 3: The Hidden Execution Context

These variables aren’t visible in ComfyUI’s interface at all. They live in your hardware and software stack.

• Python version and package versions. PyTorch 2.1 and 2.2 can produce different floating-point results from the same operations due to internal implementation changes. Record your pip freeze output—or at minimum, your Python, PyTorch, and xformers versions.
• GPU model and driver version. Different GPU architectures (Ampere vs. Ada Lovelace, NVIDIA vs. AMD) handle floating-point math with subtle differences. Even driver updates on the same card can shift results.
• Execution graph order. ComfyUI executes nodes in a topologically sorted order, but when multiple nodes have no dependency relationship, execution order can be non-deterministic.
• torch.backends.cudnn settings. PyTorch’s cuDNN backend selects algorithms dynamically. Setting deterministic = True and benchmark = False improves reproducibility but doesn’t guarantee it across different hardware.
• CLIP tokenizer version. The text encoder that converts your prompt into embeddings. Tokenizer updates—rare but real—change how text maps to vectors.
• OS and precision handling. Float32 vs. float16 execution paths, OS math library differences, and CPU-side preprocessing operations can introduce variation.

A complete Tier 3 record is essentially a system snapshot. Without it, you can reproduce results on your machine today, but you can’t guarantee reproduction on a colleague’s machine or on your own after an OS update.

A Manual Provenance Checklist

For teams who want to start capturing provenance today, here’s what a complete manual record looks like per generation:

1. Export the workflow JSON from ComfyUI.
2. Screenshot or log all Tier 1 parameters.
3. Record SHA-256 hashes for: checkpoint, VAE, every LoRA, every ControlNet model.
4. Record git commit hashes for every custom node in ComfyUI/custom_nodes/.
5. Run pip freeze > requirements.txt and save it alongside the output.
6. Log GPU model (nvidia-smi), driver version, CUDA version.
7. Note the ComfyUI core commit hash (git rev-parse HEAD in the ComfyUI directory).
8. Record OS version, Python version.
9. Save all of this linked to the specific output file.

That’s nine steps. Per generation. In batch production workflows that produce hundreds of variants in a session, manual provenance capture breaks down almost immediately.

I tried maintaining this discipline for a two-week stretch on a personal project. I lasted four days before I started skipping the hash calculations, and by day six I’d stopped recording custom node versions entirely. The friction isn’t in any single step. It’s in the repetition across every output.

Why Automated Capture Is the Only Approach That Scales

A typical ComfyUI production session generates 20–80 images. A team of five running daily sessions produces 500–2,000 assets per week. Adding nine manual documentation steps per output creates friction that compounds faster than anyone anticipates.

Automated capture works differently. Instead of asking the human to document what happened, the system observes the execution environment and records provenance as a byproduct of generation. Every parameter, every file hash, every dependency version—captured at the moment of creation, linked immutably to the output file.

Three things make automation qualitatively different from faster manual logging:

• Completeness. Automated systems capture Tier 3 variables that humans routinely skip. You don’t forget to log your PyTorch version because you don’t have to remember.
• Consistency. The 500th capture is identical in thoroughness to the first. No fatigue, no shortcuts under deadline pressure.
• Linkage. Provenance metadata is bound to the asset, not stored in a separate spreadsheet that drifts out of sync. The record travels with the file.

What Good Provenance Unlocks

Complete provenance isn’t just about reproducibility, though that’s the most immediate benefit. It enables:

• Regulatory compliance. The EU AI Act’s transparency obligations under Article 50 take effect on August 2, 2026, requiring machine-readable provenance marking for AI-generated content. The first draft Code of Practice explicitly references C2PA-style provenance embedding. Teams without capture infrastructure will face a hard deadline.
• Creative iteration. When you can reproduce a result, you can systematically vary one parameter at a time. Provenance transforms AI generation from slot-machine pulls into controlled experimentation.
• Team collaboration. A new team member can understand exactly how an approved asset was created—without asking the person who made it, who may have left the company six months ago.
• Audit trails. When a client asks “what model was used for this campaign asset?”—a question increasingly common in licensing and IP discussions—you have an instant, verifiable answer.

Getting Started: A Practical Path

If you’re building a ComfyUI provenance practice from scratch, I’d recommend this sequence:

1. Start with Tier 1 today. Use ComfyUI’s workflow export consistently. It’s incomplete, but it’s better than nothing.
2. Add model hashing this week. Write a simple script that computes SHA-256 hashes for everything in your models/ directory and timestamps the result. Run it before each session.
3. Version-lock your custom nodes. Pin every custom node to a specific git commit rather than pulling from main. This doesn’t capture provenance retroactively, but it prevents the most common source of silent reproducibility failures.
4. Evaluate automated infrastructure. Once you’ve felt the friction of manual capture—and you will, quickly—explore tools that handle provenance as infrastructure rather than process.

The gap between “I saved my workflow” and “I have complete provenance” is wider than most teams realize. Closing it manually is possible for a solo artist generating a few images per day. For teams producing at scale, memory needs to be built into the infrastructure itself.