File Naming for Small Practices: Stop Losing a Week to Version Chaos.

A consultant rings on a Thursday afternoon to say the structural drawings do not match the plan in front of them. You open the project folder. There is a GroundFloor_FINAL.dwg, a GroundFloor_FINAL_v2.dwg and a GroundFloor_FINAL_v2_AH_edit.dwg. Somewhere on the server, on a desktop and in a sent email are three more copies of the same DXF. Nobody is sure which one left the building.

That is where the week goes. A filename convention will not make you a better designer, but it stops you spending two days reconstructing your own history. This article sets out a convention a three-person practice will keep using, a revision and status scheme, a folder skeleton, and a one-page routine to hold it together.

Where the week actually goes

The real cost is rarely one lost file. It is the drawing issued to a consultant from the wrong revision, followed by the two days spent working out which one it was, who received it and what they built their coordination on. Finding a file takes minutes. Untangling a mistaken issue takes days.

The usual culprits are familiar: FINAL, FINAL_v2, FINAL_v2_AH_edit, and the same DXF saved to the desktop, the server and an email attachment. Each copy is a fork. Once two forks are edited independently, there is no longer a single current drawing, only competing candidates.

Three mistakes cause most of the damage:

• Inconsistent date formats. 12-3-24, March12 and 2024_03_12 do not sort together, and 12-3-24 is a different day depending on who reads it.
• Initials nobody can decode. _AH_edit tells you someone touched it. It does not tell you who, why or whether their change was kept.
• The word "final" anywhere in a filename. Nothing is final until the building is handed over, and often not then. Practical document-management guidance specifically advises against labels such as FINAL or NEW in favour of controlled revision tags.

The goal is simple to state. Any person in the practice, including a Part I student on placement, should be able to find the current issue in under a minute without asking anyone. Treat that as a target to test against, not a measured industry statistic.

A five-minute self-audit

Open your most recent project folder and time how long it takes to find the drawing you last sent to planning. Then ask yourself whether you are certain it is the version that was sent, or merely the one that looks latest. If the honest answer involves checking your sent emails, the system is already costing you.

A filename convention a three-person practice will keep using

Build the name in a fixed order: project number, originator, level or zone, drawing type, number, revision. Order matters more than which codes you pick, because a fixed order makes folders sort themselves. Every drawing for a level sits together, every section sits together, and the revision sits at the end so successive versions stack in sequence.

This borrows the logic of BS EN ISO 19650 naming fields without adopting its full bureaucracy. The standard's guidance treats each information container as having a unique, agreed identifier built from defined fields separated by delimiters. A small practice needs that discipline, not the forty-page protocol. Treat what follows as a local convention informed by the principle, not a standard you are required to reproduce.

A worked example

Take a ground floor plan and a site section for the same scheme:

Read left to right, each segment answers one question: which job, who made it, which part of the building, what kind of drawing, which one, which iteration. A new starter can decode it on sight, and a file search for -GF-PL- returns every ground floor plan at every revision.

Rules that survive contact with a deadline

• No spaces and no special characters. Use hyphens as delimiters. Spaces and symbols break scripts, links and some consultants' systems.
• One date format: YYYY-MM-DD. It is the only common format that sorts chronologically as plain text. Use it wherever a date is needed, such as issue folders.
• No free-text descriptors in the filename. _with_new_stair belongs in the drawing's title block or the register, not the filename. Free text is where the convention dies.
• Put the revision last. Nothing after it, ever.

Keep the code list to one page, pinned at the top of the project folder, and cap it. If the list needs a legend to read, nobody will follow it. Ten or twelve drawing type codes and a handful of level codes cover most small projects.

Revisions, status and the end of "final"

Separate revision from status. Revision answers which iteration is this? Status answers what may this information be used for? UK BIM Framework guidance on ISO 19650 assigns these as two distinct pieces of metadata for exactly this reason. A drawing at revision P03 can be "for coordination" on Monday and "for planning" on Friday without changing a single line, provided the practice records that change of status.

Stuffing both into one suffix is how confusion starts. A filename like ..._P03_PLANNING_FINAL carries a revision, a status and a false claim in one string, and all three will drift apart.

Status codes: borrow the idea, not every code

The UK National Annex to ISO 19650 gives concrete status examples: S0 for initial work in progress, S1 suitable for coordination, S2 suitable for information, S3 suitable for review and comment, S4 suitable for stage approval, and S5 withdrawn. Published and contractual states follow as A-series codes. These are project-governance codes, so a three-person practice should treat them as a reference model. Pick the three or four states you genuinely use and define them in one line each.

A simple revision scheme

A practical local convention is P01, P02 and so on for preliminary issues, and C01, C02 for issued for construction. This is common practice rather than an ISO requirement. Whether you use letters or numbers matters far less than one rule: never reuse a revision identifier. If P03 has left the building, there is no second P03.

That single rule saves the most grief. Overwriting an issued file means the drawing the consultant holds and the drawing you hold share a name but not a content, and you will not discover it until something is built or priced wrongly.

The live drawing register

Keep one spreadsheet as the drawing register: drawing number, title, current revision, date, status. Document-control guidance describes the register as a live list of every sheet with its current revision, status and issue information, letting the team see at a glance what is safe to use. Adding an issue to it takes about two minutes, which is an estimate rather than a benchmark. It is also the document you open when a consultant rings.

Working file versus issued export

Contrast a DXF exported for a structural engineer with the working file you keep editing. The working file carries no revision suffix and never leaves the practice. Only frozen exports carry a revision, and only frozen exports are sent. The revision suffix therefore signals one thing reliably: this is a snapshot that has been issued. A file without a suffix is live and private.

Folder structure that matches how a project actually runs

Organise by the stages a scheme moves through (concept, planning, technical, site) rather than by file type, so a folder reads as a timeline. A folder of "all PDFs" mixes a concept sketch with a construction drawing and tells you nothing about either.

Give every project the same skeleton. A workable one has five top-level folders:

1. Incoming: everything received from others, renamed on arrival.
2. Working: live, editable files, never sent as they stand.
3. Issued: frozen exports, read-only.
4. Reference: surveys, precedent, policy documents, site photographs.
5. Correspondence: emails and meeting notes saved against the project.

Consistency beats cleverness when you have eight live jobs. A skeleton you can navigate blind on any project is worth more than a clever one you have to relearn each time.

Split working from issued, firmly

ISO-oriented common data environment guidance separates work-in-progress, shared and published states. For a small practice that translates into something simple: editable working files, read-only issued packages, and an issue register recording what was sent and when. Make Issued read-only and dated, with one sub-folder per issue, for example 2024-03-12_Planning. You can then always reconstruct exactly what a consultant or the planning officer received, which is the evidence you need when a dispute starts.

Handle incoming files on arrival

Rename a consultant's DXF or PDF to your convention the moment it lands, and record their original filename in the register so you can trace it back. Leaving incoming files under their senders' names means your folders fill with five different naming systems and nothing sorts.

Inherited files with many drawings in one model space

A long-running practice file often holds twenty drawings in one model space, all on the same layers. At issue, name and export each drawing as its own sheet-level file. The issued file should be one drawing, not a slice of a shared model. Drawings exported from a shared model space are a common source of accidental over-sharing and mismatched scales.

Naming the files that are not drawings

Renders, site photos, sketches and presentation sheets need the same convention, or the visuals folder becomes the place where order goes to die. The files clients and planning officers see most are often the least controlled.

For render outputs, name by view and lighting condition, plus the model revision the render was taken from. A name like PRJ-ARC-00-XX-RN-010-P03_NW-corner_dusk carries the view and the lighting, and the P03 tells you which design state it depicts. A render should never outlive the design it shows, and the revision in the name is how you know when it has.

Sheets made in Layout, in either Sheet mode for the A1 competition board or Document mode for the Design and Access Statement, should follow the same project and revision scheme. Then the board and the statement sit in the register beside the drawings they draw from, and you can see at a glance whether a board is stale against a plan that has since moved on.

For retouched images, store the layered working file and the flattened export separately. The working file stays in Working. The export is named for where it goes: planning, client or website. A pixel-identical image may be right for the website and wrong for planning if the design has moved on, and the destination in the name makes that visible. In Retouch, edits land on real layers, so the layered file is worth keeping as the master and exporting from.

Name exports at the moment of issue, not after

A short list of exports to name when you make them:

• PDF sets for planning, at true sheet size, named with revision and issue date.
• DXF for consultants, one file per drawing, never a shared model space.
• GLB for a client walkthrough, carrying the model revision it was exported from.

Naming afterwards is where mistakes enter. The export and its name should be created in the same breath.

Making it stick: a one-page routine for the whole practice

Write the convention on a single page and treat it as part of onboarding. A student on placement should be able to follow it on day one without a briefing. If it needs explaining aloud, it is too complicated.

The issue ritual

Set a fixed sequence, in the same order, every time:

1. Freeze: decide the drawing is ready and lock the revision.
2. Name: apply the convention and the next revision identifier.
3. Log: add it to the register with revision, date and status.
4. Send: issue it.
5. File: save the exact sent copy into the dated Issued sub-folder.

Five steps, no variation. The ritual matters because the error almost always occurs when someone skips a step under time pressure, typically logging and filing. Making the order automatic removes the decision.

Tidy at stage close, and name an owner

Schedule a ten-minute tidy at the close of each stage, not each year. Drift is cheapest to fix while the project is still in your head. By year end, nobody remembers why a folder exists.

Decide who owns the register. One named person, not "everyone", or it will be owned by nobody within a month. The owner does not have to fill in every line, but they are the one who notices when it has gone stale.

If your drawings, renders and boards all come through one workspace, the convention is easier to hold. Linea for plans and models, Retouch and Shoot for imagery, Layout for boards and statements, and Projects to keep each scheme's material together mean fewer files are renamed by hand between tools. The convention still does the real work. The tools only reduce the number of places it can be broken.

The test that proves it works

Ask someone who did not work on the job to find the drawing issued to planning on a given date, using only the folder and the register. If they find it in about a minute, the system is doing its job. If they have to ask you, you have found the gap, and you found it before a consultant or a planning officer did.

Fix the order of the filename, never reuse a revision, freeze what leaves the building, and log it while it is fresh. The week you were losing goes back to design.