A file scheme that survives the revision round

The situation it prevents

Three weeks after delivery, a client asks for frame seven with the warmer grade “like you showed us the first time”. Your folder contains hero_final.png, hero_final_v2.png, hero_FINAL_new.png, hero7.png, hero7 copy.png and Untitled-3.xcf. Finding the right one takes forty minutes and you are not certain when you stop.

This is entirely avoidable and the fix takes no discipline once it is a habit.

A scheme that works

<project>-<frame>-<stage>-v<nn>[-<status>].<ext>

spring26-07-gen-v01.png          raw generation, metadata intact
spring26-07-gen-v02.png          second base render
spring26-07-repair-v01.xcf       layered repair file
spring26-07-final-v03-APPROVED.jpg
spring26-07-final-v04.jpg

Four rules make it work:

1. Never overwrite. New version, new number. Disk is cheaper than your time.
2. Never use the word “final” without a version number. It is the most broken word in creative work.
3. Mark approval in the filename. APPROVED is searchable across the whole disk in one command.
4. Date the folder, not every file. 2026-03-spring-campaign/ puts the date where it is useful.

The folder structure

spring26/
  brief.md                    the spec, with its change log
  ENVIRONMENT.txt             interface commit, package versions
  models.txt                  every model with its hash
  system.md                   the five constants
  refs/                       the labelled reference pack
  product/                    photographed cut-outs
  gen/                        raw generations, never edited
  work/                       layered editor files
  deliver/                    only files actually sent

Two rules make it survive: gen/ is read-only in practice, and deliver/ contains only what was delivered. If those hold, the folder answers any question anybody asks later.

The seed log

Alongside it, one plain text file per project:

frame 07  courtyard
  base      spring26-07-gen-v02   seed 418 / dpmpp_2m karras / 26 / cfg 5.5
            model realvis-xl-v5 (a1b2c3d4)
            lora  char-meera-e06 @ 0.75
  repair    hands x2, doorway, bangle
  grade     warm curve + grain preset "campaign-a"
  sent      v03 on 18 Mar, APPROVED 19 Mar
  note      client preferred warmer grade over v02

Ten lines per frame. Written as you go, it costs about a minute; reconstructed later, it costs an afternoon and is usually impossible.

That last line is the one that pays off most. Three weeks later, “client preferred warmer grade” is exactly the fact you need and exactly the fact nobody remembers.

What to keep and what to delete

Keep: every approved file, every layered work file, the raw generation behind every approved image, the brief, the system, the logs, the environment and model files, and any community model a delivered image depended on.

Delete without hesitation: the other 400 exploration renders, superseded versions more than two rounds old, intermediate upscales. These are recoverable from the seed log if you ever need them, which you will not.

A hero image project typically leaves 200 to 400 MB worth keeping, once the exploration is cleared. That fits any backup.

The honest limit

None of this survives if it is not automatic, and a scheme that requires thought at every save will be abandoned by Thursday. Make it mechanical: set the interface’s output template once so generations are named correctly without you doing anything, and keep the folder structure as a template you copy at the start of each job.

The measure of whether it works is a single question: can you find the approved file for frame seven in under thirty seconds, six months from now? If yes, the scheme is adequate however untidy it looks. If no, no amount of elegance in the naming convention is helping you.

Setting the output template once

Most interfaces let you control how generated files are named, and configuring it is a five-minute job that removes the problem at source.

In A1111 and Forge the setting is under output filename patterns, and something like this is useful:

[datetime<%Y%m%d>]-[seed]-[model_name]

In ComfyUI the Save Image node takes a filename prefix, so set it per project (spring26-07) and every render from that graph is already labelled with the frame it belongs to.

The point is that a filename produced automatically is always correct, and one you type at save time is correct until the afternoon you are tired.

Version numbers the client can use

Use the same version number in the filename and in the message you send. “Attached: v03” and a file called spring26-07-final-v03.jpg means their reply of “v03 is approved, but can we see v02’s grade again” is unambiguous.

Clients will otherwise say “the second one you sent”, which is a description of your outbox rather than of a file, and reconstructing what that was takes longer than it should.

Two further habits that cost nothing. Never reuse a version number, even for a file you sent and immediately replaced: go to v04. And never send a file with copy or a space-number suffix in its name, because whatever you send is what they will quote back at you.