A project folder contains one convincing interior image named “lobby-approved.png.” Three weeks later, the client asks for warmer timber and fewer pendants. Dragging the PNG into ComfyUI restores a graph on the original machine. The source viewport is missing, two custom nodes fail on another workstation, nobody knows which depth map was used, and “approved” has no named purpose.
The image retained useful technical information. It did not retain the project decision.
Today's intel sweep found architects still asking for ComfyUI workflows that can enhance renders and preserve architectural control. Community answers point toward depth and edge preprocessors when original passes are unavailable. That advice is about making an image. The next practice problem is keeping enough evidence to inspect, revise, and govern the selected result.
Build a five-file provenance package beside every ComfyUI render that crosses a review boundary.
File one: the selected output
Keep the exact selected image, not a screenshot pasted into a deck. Give it a stable identifier tied to project, view, option, and revision. A name such as “P24-017_lobby-v03_aiopt-b_rev02.png” is dull and useful. Preserve the file that was actually reviewed before resizing or presentation edits.
ComfyUI's official examples state that workflow information can be included in image metadata and that an example image can be downloaded and dragged into ComfyUI to load its workflow. That is a valuable recovery route. Test it on the practice installation. Do not make embedded metadata the only record, because later export, optimization, messaging, or document-production steps may return a different file.
Calculate a file hash when the image is approved and write it into the decision record. The hash is not a quality certificate. It is a compact way to tell whether the approved bytes are the bytes being reviewed later.
File two: the explicit workflow
Export the workflow as a separate JSON file even when it is embedded in the PNG. Name it with the same identifier. Open it once from a clean ComfyUI session and confirm that the visible graph matches the selected result's route.
The workflow should show the positive and negative prompts, sampler, scheduler, step count, guidance, seed, image dimensions, model and encoder selections, control inputs, masks, resize operations, and save route that matter to the result. Add Note nodes for intent and checkpoints. ComfyUI documents Note as a built-in node for workflow annotations. Use those notes to explain why a branch exists, which input is authoritative, and which control must not be changed casually.
Do not tidy the graph into a different workflow after approval. Cosmetic rearrangement is fine if it does not change execution, but replacing nodes or values creates a new revision. The saved graph should describe the route that produced the selected image, not the route the author wishes they had used.
A recoverable graph explains the machine route. A project record also explains the human decision.
File three: the input manifest
Create a short text or CSV manifest listing every non-model input. Include the source render or viewport, depth and edge maps, masks, reference images, material samples, and any intermediate image carried into a later pass. For each, record filename, purpose, source, date, and hash.
| Input | Record | Reason |
|---|---|---|
| Base view | Model file, saved view, revision, export settings | Connects pixels to designed geometry |
| Control map | Type, source or preprocessor, dimensions | Explains structural guidance |
| Mask | Target region and intended edit | Defines the intervention boundary |
| Reference | Origin, rights status, intended influence | Supports provenance and usage review |
| Intermediate | Parent output and manual edits | Preserves the pass sequence |
If a source cannot be retained because of client restrictions or licensing, record a controlled reference to it rather than silently dropping it. The manifest should also identify sensitive inputs that must not travel with a general sample package.
File four: the environment snapshot
A JSON graph can name nodes that are absent or incompatible on another machine. Official ComfyUI documentation lists missing imports, frontend conflicts, Python dependency conflicts, and strict package versions among common custom-node problems. ComfyUI Manager's documented features include missing-node detection and installation snapshots. Use those facilities where appropriate, then keep a human-readable environment record with the project.
Record the ComfyUI version or commit, frontend version where relevant, operating system, GPU class, Python and major framework versions, model filenames with hashes where policy permits, and custom-node repositories with exact revisions. Never put API keys, tokens, account cookies, or other credentials into the package.
The snapshot does not promise future reproduction. Models can be removed, services can change, and hardware behavior can differ. It distinguishes a documented dependency from a mystery. A future operator can decide whether to rebuild the environment, substitute a component, or treat the approved image as a fixed artifact.
File five: the review and use record
Create one concise record that answers what the other four files cannot: why this image was selected, what was checked, who approved it, and where it may be used.
List the approved image hash, date, reviewer, approval scope, known deviations, and superseded images. For architecture, checks should match the purpose. A concept-study check may cover massing, floor count, opening rhythm, major material direction, and obvious artifacts. A client-review check may also cover named design changes, view consistency, people and accessibility cues, signage, and a clear AI-assistance label. A construction or compliance claim cannot be established by visual realism.
Attach a marked comparison when the AI pass changed a model-based view. Identify protected facts and accepted inventions. If planting and atmosphere are interpretive, say so. If a window bay shifted and the reviewer rejected the output, preserve the rejection reason rather than deleting the evidence.
Assemble the package at review gates
Do not package every experiment. Create the five files when an image becomes a shortlist candidate, is sent for formal review, or is approved for a named use. Update all five under a new revision when the workflow or image changes.
Test the package by moving a copy to a clean folder and giving it to a second operator. Ask them to identify the approved image, restore or inspect the graph, locate every input, state the dependency risks, and explain the approval scope. They do not need to reproduce identical pixels for the package to be useful. They do need to find every missing assumption.
This is distinct from a portability test. Portability asks whether the graph runs elsewhere. Provenance asks whether the practice can connect a selected image to its technical route, source material, environment, review, and permitted use even when rerunning is impossible.
Our take: metadata starts the record
ComfyUI's image-embedded workflow is unusually helpful. It makes a generated image more inspectable than a flattened output whose recipe lives only in a creator's memory. The official examples demonstrate the basic recovery pattern, and the Manager documentation acknowledges the dependency work that can follow.
Architecture practice adds the layer the graph cannot know: which model view was authoritative, which changes were acceptable, which source rights apply, who checked the image, and what “approved” means. Keep that layer small, explicit, and beside the file.
A PNG can carry a graph. Make the folder carry the decision.
Editorial basis: the 18 September 2026 ArchiGen AI intel sweep; ComfyUI's official workflow example documenting workflow information in image metadata; the official ComfyUI Manager overview; the official custom-node troubleshooting guide; and the official Note node documentation. The five-file package, review gates, and architectural checks are editorial recommendations. This article does not claim hands-on testing.