Drawing Numbering and File Naming – Including ISO 19650

Every architectural project generates hundreds, sometimes thousands, of documents. Drawings, models, specifications, reports, schedules – each one needs to be identified, tracked, and communicated clearly to every member of the project team.

Without a consistent system for naming and numbering those files, projects begin to unravel. The wrong drawing gets issued to a contractor.

A revised model overwrites an approved one. Information gets duplicated, lost, or misread. These are not hypothetical risks – they are among the most common causes of costly errors on live projects.

Here we explain how drawing numbering and file naming conventions work in architecture, from the traditional approaches used by practices for decades to the internationally recognised ISO 19650 standard that now governs information management on major projects worldwide.

Why Drawing Numbering and File Naming Matter

Good naming conventions are not administrative formality. They are the backbone of clear communication between architects, engineers, contractors, and clients throughout the life of a project.

When everyone on a project team can identify a document’s origin, content, status, and revision at a glance, coordination becomes faster and more reliable. When they cannot, problems accumulate quietly until they become expensive.

The Cost of Inconsistency

The consequences of poor naming are practical and immediate. A contractor working from a superseded drawing because the revision code was unclear or missing is one of the most avoidable errors in construction – and one of the most common.

Files named informally, such as “Final Drawing v3 REVISED USE THIS ONE”, offer no reliable information about content, authorship, or status. When a project folder contains dozens of files named this way, no one can be confident they are working from the correct version.

Duplication is another significant problem. Without a structured naming convention, team members create parallel sets of documents that diverge over time. By the time the discrepancy is discovered, rework may already be underway on site.

Handover is where poor naming causes some of its most lasting damage. An asset owner receiving an unstructured archive of project documents at practical completion faces significant difficulty understanding what they have inherited and how to manage it.

Benefits of a Standardised Approach

A well-implemented naming convention does more than prevent errors. It creates a shared language across the project team, regardless of which organisation each party belongs to.

Standardised naming enables automated workflows in document management platforms, reduces the time spent searching for files, and makes audit trails straightforward during disputes or post-occupancy reviews.

For practices developing their architecture design process, embedding consistent naming from the outset of each project is one of the simplest and highest-value professional habits to establish early in a career.

Traditional Drawing Numbering Systems

Before formal standards existed, architecture practices developed their own internal conventions for organising project drawings. These varied between firms but shared common structural logic, grouping documents by discipline, type, and sequence.

Many practices still use adapted versions of these traditional systems, particularly on smaller projects where full ISO 19650 compliance is not required by the client.

Common Components of a Drawing Number

A traditional drawing number typically contains several identifiable components read in sequence. Each segment communicates a specific piece of information about the document.

A typical structure might look like this: 2024-001-A-GA-001

Breaking this down: the year or project code (2024-001) identifies the project; the discipline code (A) indicates architecture as distinct from structural (S) or mechanical (M); the drawing type (GA) specifies a general arrangement; and the sheet number (001) places it in sequence.

Some practices also include the originating office or team member code, particularly in larger firms working across multiple studios. The key principle is that every segment of the number carries meaning that can be read independently without needing to open the file.

Understanding how drawing numbers connect to the broader set of working drawings on a project helps students appreciate why each field in the number must be consistent and deliberate.

Scale and Sheet Size Conventions

Traditional systems often embedded sheet size or scale references within the drawing title block rather than the file name itself. A drawing at 1:100 on an A1 sheet might be noted in the title block as such, with the file name remaining consistent regardless of plotted scale.

This distinction matters because a single drawing file may be printed at multiple scales for different purposes. Encoding scale into the file name creates ambiguity when the same file is used at different output sizes.

Sheet size references, where included in file names, typically used standard ISO paper size codes: A0, A1, A2, A3, A4. Understanding architectural paper sizes and how they relate to drawing content helps clarify why these conventions developed as they did.

Introduction to ISO 19650

ISO 19650 is the international standard for organising and digitising information about buildings and civil engineering works. It provides a framework for managing information across the entire life cycle of a built asset, from initial briefing through design and construction to operation and eventual demolition.

For architects and technologists, its most immediate practical application is in how project files are named, structured, and shared. Understanding ISO 19650 is no longer optional for anyone working on projects above a modest scale in the UK or internationally.

What ISO 19650 Is and Why It Was Introduced

ISO 19650 grew directly from the UK’s earlier standards: BS 1192:2007, which established conventions for collaborative production of architectural, engineering, and construction information, and the PAS 1192 series, which extended those principles into a BIM-aligned framework.

The international standards body ISO adopted and expanded these UK standards into ISO 19650, publishing Part 1 and Part 2 in 2018 and subsequent parts covering security and asset management thereafter. The UK simultaneously published its National Annex, making ISO 19650 the successor to the PAS 1192 suite.

The driving motivation was the global shift toward Building Information Modelling (BIM) and the recognition that information – not just geometry – is the core deliverable of a modern construction project. Without standardised naming and classification, the potential benefits of BIM cannot be realised.

Key Terminology in ISO 19650

ISO 19650 introduces specific terminology that all practitioners working within its framework need to understand. These terms have precise definitions that differ from their informal usage.

A Container is any named and managed set of information – this includes drawing files, model files, specifications, and reports. The term replaces the informal word “document” to reflect that containers can hold many types of information.

A Common Data Environment (CDE) is the agreed-upon source of information for a given project. It is not a single piece of software but a workflow and environment – though in practice it is usually implemented through a cloud-based document management platform.

Status Codes indicate the suitability of a container for its intended purpose at any given moment – for example, whether a drawing is suitable for coordination, for construction, or for information only. Revision Codes track the sequential development of a container through its production lifecycle.

ISO 19650 and BIM Level 2

BIM Level 2 – the UK government’s mandated requirement for centrally procured public projects since 2016 – requires that project teams produce, share, and manage information in a structured, collaborative way. ISO 19650 is the standard that defines how this is done.

It is important to understand that ISO 19650 is about information management, not software. A practice can comply with ISO 19650 principles using relatively simple tools, provided the naming conventions, workflows, and responsibilities are clearly established and consistently followed.

The ISO 19650 File Naming Convention Explained

The ISO 19650 file naming convention is one of the most tangible and immediately applicable parts of the standard. It defines a structured string of fields, separated by hyphens, that together provide a complete and machine-readable description of every project container.

Once understood, the convention is logical and easy to apply. The challenge is consistency – every member of the project team must apply the same convention in the same way, every time.

The Full Naming String Structure

A fully compliant ISO 19650 file name follows this structure:

Project – Originator – Volume/System – Level/Location – Type – Role – Number

Each field is separated by a hyphen-minus character. Spaces are not permitted anywhere within the file name. The total string, including the file extension, should remain practical for use within common operating systems and document management platforms.

An example of a compliant file name might be:

PRJ001-ABC-ZZ-00-DR-A-00001

Each segment of that string carries specific, standardised meaning, which the following section breaks down in detail.

Field-by-Field Breakdown

The Project field is a unique identifier for the project, typically assigned by the client or lead appointed party. It is usually a short alphanumeric code – for example, PRJ001 or a client reference number.

The Originator field identifies the organisation that created the container. This is typically a three-to-six character code agreed across the project team at the outset – for example, ABC for an architecture practice or ENG for a structural engineering firm.

The Volume/System field describes the spatial volume or building system to which the container relates. For building projects this might reference a specific building within a masterplan (such as BLD-A or BLD-B), or ZZ where the container applies to the whole project.

The Level/Location field identifies the storey, zone, or location within the building. Ground floor might be coded 00, first floor 01, basement B1, and so on. Where the container covers all levels, the code is typically ZZ or FL-XX.

The Type field indicates the nature of the container. Drawing files use DR. 3D models use M3. Specifications use SP. The full list of type codes is defined in the standard and should be applied consistently.

The Role field identifies the discipline responsible. Architecture is typically A. Structural engineering is S. Mechanical and electrical engineering use M and E respectively. Civil engineering uses C.

The Number field is a sequential five-digit number that uniquely identifies the container within its field combination. Starting from 00001 and incrementing upward, this field ensures that no two containers in the same project share an identical name.

Status Codes and Revision Codes

Status codes and revision codes are appended to the file name to indicate where a container sits within the production and approval workflow. They appear after the main naming string, either within the file name itself or in a metadata field within the CDE.

Revision codes take the format P01, P02, P03 (for work in progress revisions) and C01, C02, C03 (for authorised revisions issued for construction or other suitability). P indicates a preliminary revision still under development; C indicates a container that has passed through authorisation.

Status codes describe suitability. S0 indicates a container that is work in progress and not yet suitable for any external use. S1 is suitable for coordination. S2 is suitable for information. S3 is suitable for review and comment. S4 is suitable for stage approval. S5 is suitable for manufacture or construction. S6 and above cover operation, maintenance, and handover purposes.

These codes give every recipient of a drawing or file immediate, unambiguous information about what it can and cannot be used for – a simple but powerful safeguard against using unverified information on site.

Applying the Convention to Different File Types

One of the strengths of the ISO 19650 naming convention is that the same structural logic applies across all container types. A drawing file, a Revit model, a specification document, and a site analysis report all follow the same field sequence.

Only the Type field changes to reflect the nature of the content. This means that once the convention is understood, it can be applied consistently regardless of what kind of file is being named – removing the need for separate naming rules for different document types within a practice.

For those working on architectural diagrams or analysis documents as part of a larger project submission, applying the same naming convention to these files keeps the full project archive structured and searchable.

Setting Up a File Naming System in Practice

Understanding the ISO 19650 naming convention in theory is one thing. Implementing it consistently across a project team – often one that includes multiple organisations with different internal habits – requires deliberate setup and clear governance from the start of a project.

Creating a Project Information Standard (PIS)

A Project Information Standard (PIS) is the document that defines the specific conventions to be used on a given project. It translates the general principles of ISO 19650 into project-specific decisions – which originator codes each party will use, what volume and level codes apply to this particular building, which status codes are relevant at each stage.

The PIS is typically prepared by the lead appointed party – usually the lead architect or principal designer – and agreed with all other appointed parties and the appointing party (the client) at the outset of the project. Once agreed, it becomes the reference document for all naming decisions throughout the project.

A well-drafted PIS removes ambiguity and prevents individual team members from improvising their own interpretations of the convention. It should be concise, clearly written, and distributed to everyone who will be producing or managing project information.

Using a Common Data Environment (CDE)

A CDE is the shared platform through which project information is published, reviewed, approved, and archived. Common platforms used in UK practice include Autodesk Construction Cloud (formerly BIM 360), Oracle Aconex, Bentley ProjectWise, and Trimble Connect, among others.

These platforms enforce the ISO 19650 workflow by requiring files to pass through defined states – work in progress, shared, published – before they can be accessed by other parties. The naming convention works in conjunction with this workflow: a file named correctly can be processed automatically by the platform without manual intervention.

Even practices that are not yet using enterprise-level CDE platforms can implement the naming convention principles within a structured shared folder system on cloud storage such as SharePoint or Google Drive, provided the folder structure and workflow rules are clearly defined and followed.

Responsibility and Team Coordination

ISO 19650 assigns specific information management responsibilities across the project team. The Information Manager is responsible for setting up and managing the CDE, developing the Project Information Standard, and monitoring compliance with naming conventions throughout the project.

In practice on many projects, particularly those without a dedicated BIM manager, these responsibilities fall to the lead architect or a senior technologist within the lead appointed party’s organisation. Document controllers within each organisation then take responsibility for ensuring that their own team’s output complies with the agreed standard before files are issued.

Clear lines of responsibility prevent the common situation where naming conventions begin well at project start but drift as the project becomes busier and pressure increases. Naming discipline under programme pressure is a professional habit worth developing early.

Practical Guidance – Implementing Drawing Numbering Day to Day

Theory and standards only deliver value when translated into consistent daily practice. The following guidance addresses the practical routines that keep a project’s drawing and file management system functioning reliably from inception through to handover.

Building Your Drawing Register

A drawing register is a master list of all containers produced on a project. It records each file’s name, title, current revision, status code, date of last issue, and the parties to whom it has been issued. It is updated every time a new drawing is created or an existing one is revised.

In its simplest form, a drawing register is a spreadsheet. In more sophisticated project environments, it is generated automatically by the CDE platform, pulling metadata from each container’s file name and properties.

Whether simple or automated, the drawing register serves as the single source of truth for what exists on a project at any given time. Without it, tracking the current status of dozens or hundreds of drawings becomes unreliable. It is one of the most important documents on any project and should be started on day one.

The drawing register connects directly to the broader set of construction details and technical drawings that accumulate through the design development and technical design stages, providing a clear audit trail of how the project information evolved.

Handling Revisions and Superseded Drawings

Every revision to a drawing must be recorded clearly. The revision code increments, the reason for revision is noted in the title block and drawing register, and the superseded version is archived – never deleted.

Superseded drawings should be moved to a clearly marked archive folder within the CDE or project file structure. They must remain accessible for reference and legal purposes but must not be visible to contractors or subcontractors as live documents.

A common and effective practice is to include a revision history table within the drawing title block, listing each revision code, the date it was issued, the description of changes made, and the name of the person who authorised the revision. This information stays with the drawing throughout its life.

Understanding how revision management connects to the overall RIBA work stages helps clarify when revisions are expected as part of normal design development and when they represent a change to an authorised baseline, which may have programme and cost implications.

File Naming for Small Practices Without BIM

Not every project requires full ISO 19650 compliance. A small practice working on a domestic extension or a minor conversion project is unlikely to be operating within a formal CDE or working to a BIM Execution Plan.

That does not mean naming conventions can be ignored. Even on modest projects, a simplified but consistent naming system prevents confusion, speeds up file retrieval, and protects the practice in the event of a dispute over which drawing was current at a given point.

A practical approach for small practices is to adopt the core ISO 19650 field structure but simplify it to the fields that are relevant. For a residential project, a name like 2024-001-ABC-00-DR-A-00001-P01 captures the project, originator, level, type, discipline, number, and revision without requiring specialist software or a complex CDE setup.

The key discipline is consistency. Whichever system a practice uses, it should be applied the same way on every project, by every person in the team, from the first drawing to the last.

Real-World Case Studies

Abstract standards become meaningful when examined through real projects. The following case studies illustrate how drawing numbering and file naming conventions have been applied – and why they mattered – across a range of project scales and types.

Case Study 1 – Crossrail (Elizabeth Line), UK

Crossrail – now known as the Elizabeth Line – is one of Europe’s most complex infrastructure projects, involving hundreds of contractors and consultants producing information across dozens of stations, tunnels, and surface works simultaneously.

From an early stage, the project adopted BS 1192 and the PAS 1192 principles that would later underpin ISO 19650. The scale of the information challenge was significant: at its peak, Crossrail was managing over three million individual documents.

The structured naming convention allowed automated processing of documents through the project’s CDE, enabling version control and distribution to be managed at a scale that would have been impossible with informal naming. The project is now widely cited as a foundational example of large-scale BIM information management in the UK infrastructure sector.

Case Study 2 – Barangaroo South, Sydney, Australia

Barangaroo South is a major mixed-use waterfront development in Sydney, designed by a consortium including Rogers Stirk Harbour + Partners and delivered by Lendlease. The project involved a large international team of architects, engineers, and specialist consultants working across multiple buildings simultaneously.

A structured CDE and consistent file naming convention were essential to coordinating information across time zones and organisations. The project adopted naming conventions aligned with international BIM standards, demonstrating that ISO 19650-aligned principles have relevance beyond the UK context in which the standard originated.

Barangaroo is a useful precedent for understanding how structured information management supports complex building typology coordination across mixed-use programmes with multiple stakeholders.

Case Study 3 – UK Government Soft Landings and ISO 19650 Adoption

Following the UK government’s 2016 BIM Level 2 mandate, all centrally procured public projects – including schools, hospitals, and government offices – have been required to comply with the standards that are now formalised as ISO 19650.

This mandate drove widespread adoption of structured naming conventions across the supply chain. Practices that had never previously considered formal document control found themselves required to comply in order to work on public sector commissions.

The UK Government Soft Landings (GSL) framework, which accompanies this requirement, reinforces the importance of structured information at handover – ensuring that asset owners receive a coherent, navigable information archive rather than an unstructured collection of files.

Case Study 4 – Small Practice Implementation, Residential Project

A small UK architecture practice with four staff members was commissioned to design a two-storey rear extension and loft conversion for a private residential client. The project did not require BIM compliance, but the practice chose to apply a simplified ISO 19650-aligned naming convention across all project documents.

Using a shared cloud folder as their CDE equivalent, the team assigned originator codes, used consistent type and discipline codes, and applied revision codes to every drawing issued. When the project later became subject to a planning appeal, the practice was able to produce a clear, chronological record of every document issued and the revision history of each drawing.

The time invested in setting up the naming system at project start was modest. The value it delivered during the appeal process – in credibility, clarity, and time saved – was significant.

Case Study 5 – HS2, UK

HS2 – the high-speed rail programme connecting London, Birmingham, and the north of England – represents one of the most demanding information management challenges in contemporary UK construction. The programme involves hundreds of appointed parties producing information across a programme that will span decades.

HS2 Ltd developed an organisation-wide information standard requiring strict ISO 19650 file naming compliance from every appointed party across the programme. All containers – from preliminary design drawings to environmental assessments to construction method statements – are required to follow the same naming convention.

The HS2 information standard has become a reference point for other major infrastructure programmes, demonstrating how ISO 19650 can be scaled to operate across a multi-decade, multi-organisation programme without losing coherence.

Common Mistakes to Avoid

Even practitioners who understand the principles of ISO 19650 naming make errors in practice. The following mistakes are among the most frequently encountered and the most preventable.

Using Spaces, Special Characters, and Ambiguous Codes

Spaces within file names cause failures in automated workflows. Many CDE platforms and scripting tools interpret a space as a delimiter, breaking the file name into separate strings. The ISO 19650 convention explicitly requires hyphens as separators and prohibits spaces.

Special characters – including forward slashes, ampersands, parentheses, and quotation marks – cause similar problems and must be avoided entirely. Characters that appear harmless in Windows File Explorer may cause errors when files are processed through web-based platforms or transferred between operating systems.

Ambiguous codes are equally problematic. Using A for both Architecture and Approved within the same project creates contradictions that undermine the entire naming system. All codes must be defined in the Project Information Standard and applied consistently without improvisation.

Skipping the Project Information Standard

The single most common reason for naming convention failure on multi-party projects is the absence of an agreed Project Information Standard at the outset. Without it, each organisation defaults to its own internal conventions, and the result is a project archive with multiple incompatible naming systems.

Establishing the PIS during the pre-appointment or mobilisation phase – before any information is produced – is far easier than attempting to retrospectively impose a naming convention on a project already underway. The later the PIS is introduced, the more resistance it will encounter and the less likely it is to be adopted consistently.

Connecting the PIS to the broader architecture design brief and project setup process ensures it is treated as a substantive project deliverable rather than an optional administrative task.

Inconsistent Revision Management

Revision codes mean nothing if they are applied inconsistently. Common errors include resetting the revision counter after a planning submission (creating duplicate revision codes), applying C-series revision codes to drawings that have not been through a formal authorisation process, and failing to update the drawing register when revisions are issued.

These inconsistencies erode confidence in the document control system. Once a project team cannot trust that revision codes are meaningful, they begin to rely on informal communication – email, telephone, site conversations – to determine which drawing is current. At that point, the risk of error rises sharply.

Consistent revision management is ultimately a matter of discipline and shared professional commitment. It requires every team member to follow the agreed process every time, including under programme pressure when shortcuts are most tempting.

Conclusion

Drawing numbering and file naming are among the most unglamorous aspects of architectural practice. They rarely appear in portfolios or feature in design critiques. But they underpin the reliability of every technical decision made on a project, and their absence is felt acutely when coordination fails, disputes arise, or handover goes wrong.

ISO 19650 provides a robust, internationally recognised framework for managing project information in a way that is structured, transparent, and scalable. Understanding its conventions – from the field-by-field naming string to the status and revision codes that govern document workflows – is now a baseline professional competence for architects and technologists working on projects of any significant scale.

For students and early-career architects, the most important takeaway is this: establish the system at the start. A Project Information Standard agreed in week one costs almost nothing. The same conversation in week twenty, when confusion has already taken root, costs considerably more. Good information management is not separate from good design – it is what allows good design to be built.