Project folder structure and file names: order before technology

A search finds documents only if they sit where you expect them and are recognisably named. That is true of the Windows search and equally of an AI knowledge base. Identical folders, file names with date, content and drawing revision, and one valid version per document therefore achieve more than any tool. How a knowledge base works technically is explained in the article Making your project files searchable. This one is about what has to happen before that.

What search and a knowledge base get from the file name

Every hit in a knowledge base shows which document it comes from, on which page it appears and what date the document has. The file name is therefore part of the source reference that you check later. “Scan_0042.pdf” tells you nothing. “2026-03-12_Musterstr_Grundriss-EG_Index-C.pdf” tells you what it is about before you open it. The example is invented.

There is a second point. If the old and the new version of a drawing sit side by side, the search can quote the old one. Only if the date and the drawing revision appear in the name or the path can you see at a glance which version is meant.

What the standard says, and what it does not

ISO 19650-1 describes concepts and principles for information management about buildings and civil engineering works using building information modelling (BIM). According to the standard-setter’s page, it gives recommendations for a framework in which information is exchanged, recorded, versioned and organised for all parties, and it applies to the whole life cycle of a built asset.

As of November 2026: the ISO edition dates from December 2018, was confirmed in 2024 and, according to ISO, is to be replaced by a revision (draft ISO/DIS 19650-1). In Germany the edition DIN EN ISO 19650-1:2019-08 applies, shown as current by DIN Media. DIN Media also lists a draft, DIN EN ISO 19650-1:2026-04 (issue date 2026-02-27). A revision is therefore coming but is not yet in force. Build your filing scheme on the principles rather than on individual clause numbers of the standard.

Concrete naming rules do not appear in this framework, because the project sets them. One example is the guidance on the UK National Annex, which relates to ISO 19650-2. For information containers, in practice files, it proposes a unique identifier of seven fields: project, originator, volume or system, level, type, discipline and number, separated by hyphens. The permitted values for each field are defined by the project in its information standards. For status the guidance recommends a two-character code linked to a revision note. This is a British example and not an obligation for your office. It shows the principle: a few fixed fields, a fixed order and a list of permitted values.

Whether your client or a contract requires a convention is stated in the project documents. The project lead checks that and, in case of doubt, your legal adviser.

A scheme to begin with

The following scheme is the author’s working assumption, not a standard. It is meant to be small enough that it actually gets used in day-to-day work.

Element	Example	Purpose
Date, year first	2026-03-12	Sorting by date, telling versions apart
Project abbreviation	Musterstr	Allocation, even outside the folder
Content	Grundriss-EG (ground floor plan)	What it is about
Drawing revision or version	Index-C, v02	Which version applies

Three rules apply. First, avoid characters that systems do not accept: according to Microsoft, OneDrive does not allow the characters “ * : < > ? / \ | in file and folder names, nor leading and trailing spaces, and names such as CON, PRN, AUX, NUL or desktop.ini are reserved. Second, avoid umlauts and spaces. This is a precaution by the author, so that exchanging files with other systems does not stall. Third, do not put the names of people in file names, particularly not of tenants or staff, because the file name appears in every hit.

The same folders in every project

The folders belong to the scheme as well. If every project has the same top level, you find your way around every project, and the knowledge base can include or exclude folder areas deliberately.

An example of such a top level (an assumption, adaptable):

• 01 Contracts and agreements
• 02 Drawings
• 03 Meeting minutes
• 04 Correspondence
• 05 Costs and invoices
• 06 Handover and documentation

Three to four levels of depth are usually enough. The deeper the filing, the more often something ends up in the wrong place.

Versions: one valid version

For each document, decide where the valid version lives, and move older ones to an archive folder. For drawings, the revision comes from the title block, you do not invent it. Names such as “final_new_2” are hard enough for people to interpret and worthless for a search.

What the knowledge base gains

From a clean name and path you can read the project, date, document type and drawing revision. These become filters: only meeting minutes, only one project, only the valid versions. The access concept follows the folders as well, because each person should see only hits from documents they could open in the filing system anyway.

1. FoldersSame structure in every project
2. File namesDate, project, content, revision
3. VersionsOne valid version, old ones archived
4. SearchHits with document, page, date
5. Knowledge baseAnswer with source, a person checks

Text version of the graphic

• Layer 1 from the bottom: Folders, Same structure in every project
• Layer 2 from the bottom: File names, Date, project, content, revision
• Layer 3 from the bottom: Versions, One valid version, old ones archived
• Layer 4 from the bottom: Search, Hits with document, page, date
• Layer 5 from the bottom: Knowledge base, Answer with source, a person checks

Questions without hits show where the filing has gaps. That list belongs with the person who looks after the filing. The AI prepares and finds, the person checks and decides.

Changing over without a big operation

Do not rename the whole archive at once. Set a cut-off date after which new documents are named according to the scheme. You deal with older projects when they are needed. A program can suggest names once it has read the content. Before renaming, a person confirms the suggestion, because references in drawings, contracts and spreadsheets can depend on the file name.

What order does not replace

Good names do not prove that the content is right. A neatly named document can be out of date or wrong, so the check against the original remains. Personal data does not belong in file names. Which folders may go into a shared search at all is for your data protection officer to clarify.

What you can do now

1. Open three project folders and note how their top levels differ.
2. Decide on the four elements every file name should contain, and write one example on a single page.
3. Set a cut-off date and name one person who briefly checks that new documents follow it.
4. Set up an archive folder in every project for superseded versions.