Version chaos: a filename is not a record.

A filename is asked to do a job it cannot do

Naming conventions are the standard defense against version chaos, and they fail predictably. A convention holds while one person applies it. It weakens with each additional person. It breaks the day it has to express something it has no field for.

final_v2 says that something newer than v1 exists. It does not say what changed, whether the change was approved, or whether v2 replaced v1 everywhere v1 was already in use. final_v3_FINAL says that someone lost confidence in the convention itself. Every underscore is a workaround for a fact the name cannot store.

A name is a label. What the team actually needs is a record.

Copies are how storage represents context

In a folder-based library, a copy is the only way to put one asset in two places. When one image belongs to a campaign folder, a partner folder, and an archive, storage answers with three files. From that moment, the three change separately. A retouch is applied to one. A crop is adjusted in another. The third stays untouched.

The library now holds three versions of one image, and nothing in the structure says which one is current. The duplication was not carelessness. It was the only mechanism available for expressing that one asset has more than one context.

The arithmetic compounds quickly. A campaign that ships 40 selected images through three revision rounds produces well over a hundred files before a single copy is made for a second folder. Add the copies, and the library holds several hundred files that represent 40 assets. Every one of them looks equally valid to the file system.

The cost appears as rework and wrong-version use

The visible cost of version chaos is checking. Someone opens two files side by side to spot the difference. Someone asks the channel which one is current. Someone re-exports a version rather than trusting the ones that exist. Each check is small. Across a working library, the checking becomes a task of its own.

The larger cost is quieter. An outdated image runs in a live campaign. A superseded crop goes to a partner. A print order uses a file that was replaced two weeks earlier. Nothing marked the older file as replaced, so nothing stood between it and use.

In most teams, the fallback is a person. One colleague becomes the authority on which version is current, and the library works only when that person is available. The state of the assets exists – as institutional memory, not as structure.

The decision happens where the file cannot record it

Every final version became final through a decision. Someone reviewed, compared, and chose. That moment is real, and it almost always happens away from the file – in a review call, a thread, a meeting. The file is renamed afterwards, or not.

From then on, the file and the decision drift apart. The decision lives in a thread that scrolls out of reach. The file lives in a folder, carrying only its name. When someone later asks what was decided, the answer has to be reconstructed from messages, calls, and memory. A decision that is not recorded on the work has to be rebuilt from everything around it.

This is also why the newest file is not a safe answer. Sorting by date finds the most recent version, not the decided one. A late experiment, an unapproved retouch, or an export made for one specific channel can all be newer than the version the client confirmed. The version that matters is not the newest file. It is the one a decision was made about – and in most libraries, that decision is recorded nowhere the file can show it.

State belongs on the asset, not in the name

Version chaos is the visible symptom of state stored in the wrong place. The instinctive fix is stricter naming. The structural fix is different: the asset itself carries its state, and the system records it.

That standard has three parts. Status is recorded on the asset, so current and superseded are facts, not guesses. One asset can appear in several contexts without being copied, so there is nothing to diverge. Attributes are searchable, so finding the approved version is a search, not an act of recall.

moodcase Visual Asset Management is one example of this standard. On team plans, workflow statuses record where an asset stands, collections show one asset in multiple contexts without duplication, and metadata makes the current version findable by description. The name can go back to being a name.

None of this requires more discipline than a naming convention does. It requires the discipline to live in the structure instead of in the filename.