The filename report-final-final2 tells you that a decision happened, but not what the decision was. Was the second file approved, corrected after approval, or simply copied to another computer? A version convention should answer the questions that matter in your work without forcing every small edit into a complicated numbering system.
First establish the main working document. If a shared editor keeps version history, a stable filename may be preferable to saving a new file after every paragraph. Agree on who may edit it and where the authoritative link lives. Version history is useful only when participants are working on the same document and can access that history.
Name the milestones that leave your hands
An exported file sent for review needs a recognizable identity. A name such as kitchen-plan-v03-review.pdf makes the project, version, and purpose visible. Use the same version label for the editable source and its export when they represent the same milestone. Avoid silently replacing an already sent export with revised contents under an identical name.
Dates are helpful when work is issued on a schedule. Use one unambiguous order, such as year-month-day, and decide what the date represents: creation, review, or release. Mixing these meanings makes sorting misleading. A date and a short version number can coexist when several releases occur on the same day.
Approval is a separate fact from recency. A newer draft does not automatically supersede the version a customer approved. Keep an approval note that identifies the file or shared version, who approved it, and when. Do not use the word approved merely because the writer considers the document finished.
Handle changes after release explicitly
When a correction affects a delivered file, create a new identifiable release and explain the change. A brief note such as corrected delivery date on page two is more useful than a vague updated label. If the correction affects decisions others made, make the revised file easy to distinguish from the previous one.
Archive superseded versions in a consistent place rather than mixing them into the active working view. Preserve versions needed to explain commitments or recover prior work, following your organization's retention rules where applicable.
The convention should fit the scale of collaboration. A solo grocery list needs little ceremony; a proposal moving between several reviewers needs more. Write two or three examples of valid filenames in the project instructions so a new participant can follow the same pattern immediately.
A review sequence in practice
Imagine sending plan-v02-review.pdf to a colleague on Tuesday. They return comments, you revise the editable source, and the next review export becomes plan-v03-review.pdf. If version three is approved, record that approval against version three rather than renaming every copy to final. A subsequent correction should be identifiable as a new release, with its own explanation. The earlier approved file remains understandable as a historical record. This convention also prevents an old email attachment called final from appearing more authoritative than a later, correctly numbered revision.
