A file-naming system that actually survives contact with real life

Organization 18 September 2026

The problem isn't that you don't have a system. It's that it doesn't survive contact

Almost everyone has a file-naming system for about the first ten files. Then a client sends a revision, a deadline moves, two people edit the same document, and the system quietly stops being followed, because it was never built for those situations in the first place. A naming system that only works when nothing unexpected happens is not really a system.

The fix isn't more discipline. It's a structure that keeps working exactly when things get messy, because that's the only time a naming system actually earns its keep. Nobody needs help finding a file when there's only one version of it.

Dates go first, and they go in one specific order

YYYY-MM-DD, always, at the very start of the filename. Not because it looks neat, but because it's the only date format that sorts correctly as plain text. “03-04-2026” sorts next to nothing useful and means either March 4th or April 3rd depending on who's reading it. “2026-04-03” sorts chronologically in any file browser with zero effort, and nobody has to guess which country's date convention was used.

This single change fixes more real chaos than any other part of a naming system, because it means the most common thing people actually want — what's the latest version, what happened in what order — is answered automatically by the file browser's default sort, with no folder structure required to back it up.

Version numbers, not “final”

Every shared drive has a file called “proposal_final_FINAL_v2_useTHISone.docx,” and it exists because “final” is a claim, not a fact — there is always a chance something changes after it. Use v1, v2, v3, sequentially, and let the number carry the meaning “final” was trying to. If a version was actually sent to a client or signed, that's worth marking too, since it's a different kind of milestone than an internal draft.

For anything with real back-and-forth — contracts, anything with review cycles — the version number is what lets you say “revert to v3” without ambiguity. “Final” can't do that, because there's no v2 to compare it to in the name itself.

Keep the vocabulary small and pick it once

The actual content of a filename should describe what the document is and who or what it's for, using a small, fixed set of terms decided in advance rather than whatever word feels natural in the moment. If invoices are sometimes “invoice” and sometimes “bill” and sometimes “inv,” searching for one term misses a third of the files that word applies to. It doesn't matter which word wins, only that everyone uses the same one every time.

The same goes for client or project names: pick one short form and reuse it exactly, rather than switching between a full name, an abbreviation, and a nickname depending on who typed the filename that day.

What this looks like put together

2026-04-03_acme-contract_v2.pdf. Date first for sorting, a fixed short name for the client or project, a version number instead of a superlative, and the extension doing what extensions are for. It's not exciting, and that's rather the point — a good filename is boring enough that you stop noticing it, and only notice when a file doesn't follow the pattern.

None of this requires new software. It requires deciding the order once, writing it down somewhere the whole team can see, and treating a filename that breaks the pattern as worth fixing on sight rather than something to clean up later, because later is where naming systems go to die.