In this article9 sections
A document numbering convention is the rule that gives each drawing and document on a project or facility one identifier, built from fixed fields: a site or project code, an area or unit, a discipline, a document type and a sequence number, plus a sheet number on multi-sheet drawings. The revision is a separate field, kept beside the number in the title block and the register, so a P&ID keeps one number from first issue to as-built.
The convention is written into a document numbering procedure, usually the owner's, and contractors and suppliers number to it. Two events test it. A management of change (MOC) has to find the current drawing under the number other documents cite, and handover needs the register, the tag-to-document links and the file names to agree on one string per document.
In short
- The number identifies a document. Revision, status, title and originator describe it and belong in the title block and the register.
- A field belongs in the number only if its value holds for the document's life; a project code or an originator usually fails that test on a drawing that outlives its project.
- No single standard fixes the format. ISO 7200 sets the title-block fields, IEC 81355-1 classifies document content, and CFIHOS defers to the owner's numbering specification.
- A multi-sheet P&ID is numbered once per set or once per sheet, and the procedure has to choose.
- Numbering faults surface at MOC and handover, when documents, registers and file names have to resolve to one string.
The fields in a document number
GP-34-P-PID-001-02 is sheet 2 of the first piping and instrumentation diagram for Unit 34 at a gas-processing plant with the site code GP. On the unit it is called PID-001; the register holds the full string, with the revision beside it.
| Field | In GP-34-P-PID-001-02 | What it carries | Where procedures differ |
|---|---|---|---|
| Site or facility | GP | The plant the document belongs to | A project code, in project-numbered schemes |
| Area or unit | 34 | Unit 34 | A system or volume code, with reserved codes for multi-unit documents |
| Discipline | P | Process, the discipline responsible for the content | One or two letters, from the procedure's own list |
| Document type | PID | A piping and instrumentation diagram | Two or three letters, or held only in the register |
| Sequence | 001 | The document's place in its series | Two to six digits in published schemes, issued from the register |
| Sheet | 02 | Sheet 2 of a multi-sheet drawing | A field of the number, or a separate title-block field |
| Revision | Outside the number | The issue the reader is holding | Letters, numbers, or prefixed codes such as P01 and C01 |
Site and unit say where the document belongs, discipline and type say what kind of document it is, and the sequence makes the string unique within that combination.
ISO 7200:2004, the standard for data fields in title blocks and document headers, requires the identification number to be unique at least within the legal owner's organization, and gives the revision index and the sheet number their own fields. It leaves the composition of the number to the owner.
Building projects use the same pattern under ISO 19650, the information management series for BIM. The UK National Annex to ISO 19650-2 names an information container with seven hyphen-separated fields: project, originator, volume or system, level or location, type, role and a sequential number of four to six digits. Status and revision are metadata, added to the name as a suffix only when a file leaves the common data environment without its metadata.
Revision, status and title stay outside the number
ISO 7200 numbers revisions consecutively in their own field, with letters (A to Z, then AA, AB) or figures, and advises against the letters I and O, which are easily confused with 1 and 0. One published owner procedure states that the revision code is not part of the document number and that the number and the title are independent fields.
CFIHOS, the Capital Facilities Information Handover Specification maintained by IOGP, requires a new revision each time an updated document is issued to the owner, with revision coding and reason for issue set by the owner's numbering specification.
A P&ID number is printed on the off-page connectors of neighbouring sheets, on loop diagrams and datasheets, in the instrument index, on transmittals and in MOC records. A revision inside the number mints a new identifier at each issue, so each of those references points at a superseded string the day the drawing changes.
With the revision outside, PID-001 sheet 2 stays PID-001 sheet 2, and the MOC record names the revision it changed, Rev C before and Rev D after. A file that leaves the document system can carry the revision as a file-name suffix, as the ISO 19650 guidance and owner procedures allow, while the register keeps the revision as its own field.
Discipline and document-type codes
The discipline field names the discipline responsible for the document's content. CFIHOS defines discipline that way, and one published owner procedure applies the same test: a motor starter schematic is an electrical document even when it serves process equipment. A P&ID is usually filed under process, the discipline that issues it, although several disciplines add to it. The same procedure gives multi-disciplinary documents a general code.
Document-type codes come from a list in the procedure. Some procedures use three letters, such as PID for a P&ID or GAD for a general arrangement drawing; the ISO 19650 guidance uses two, such as DR for a drawing rendition, SP for a specification and SH for a schedule.
CFIHOS treats type as classification delivered with the document. Each document carries one discipline and one document type from the contract reference data library, the pair (the discipline document type) sets its delivery requirements, and a contractor may not create a new pair without the owner's approval. A type code inside the number has to come from the same list, or the number and the register will disagree.
IEC 61355-1:2008 classified documents by information content, gave each class of document kind a letter code written after an ampersand, and linked that code to the designation of the object a document describes. Its classes were meant as document management metadata.
IEC 81355-1:2024 replaced it in December 2024, classifying information instead of document kinds under an information kind classification code. A plant with its own number format can still record the class in the register.
Sheets on a multi-sheet P&ID
ISO 7200 treats a sheet as a segment of one document. Each sheet shares the identification number, is presented and stored on its own, and carries a sheet number, with the total number of sheets as an optional field.
The CFIHOS 2.0 specification asks the contractor for a separate document number for each sheet of a multi-sheet drawing, names P&IDs as the example, and wants each sheet delivered as a single file.
| Model | How a sheet is identified | Fits |
|---|---|---|
| One number per drawing, sheet in its own field | PID-001, sheet 2 of 3 | Title blocks and drawing lists that treat the set as one document |
| One number per sheet | A different number for each sheet | Registers and handover data with one row per file |
| Sheet as the last field of the number | GP-34-P-PID-001-02 | Both, once the field width is fixed |
The third model gives each sheet a unique string, one per file and per register row, while the shared stem keeps the set together on the drawing list. One published owner procedure uses it, with three rules worth copying: each sheet of a multi-sheet drawing carries the same title, content that needs a different title gets a new document number instead of another sheet, and sheet numbers are not used to bundle documents that should stand alone.
Project numbers and supplier numbers
Supplier drawings, datasheets, certificates and manuals arrive numbered in the supplier's own system. CFIHOS requires the contractor to make sure subcontractor and supplier documents are numbered to the owner's specification and identified in the master document register, and notes that the specification should allow for documentation, such as that of off-the-shelf equipment, that may not benefit from renumbering.
| Project document number | Supplier document number | |
|---|---|---|
| Assigned by | Document control, under the owner's procedure | The supplier, under its own system |
| Identifies | The document in the project or facility register | The document in the supplier's records |
| Revision scheme | The project's revision codes | The supplier's, which can run on a different sequence |
| Used for | Cross-references, MOC records and handover | Correspondence with the supplier about that document |
| In the register | The key the row is filed under | A cross-reference field on the same row |
The master document register is where the two numbers meet: one row per document, filed under the project number, with the supplier's number and the purchase order beside it.
The choice between project numbers and a supplier cross-reference belongs in the supplier document requirements list on the purchase order, because suppliers plan and price their documents against it.
Fields that belong in the number
A scheme can sit anywhere between a plain sequential number and a string that encodes everything about the document. The test is how long each field's value holds: a number is copied into other documents, registers and file names, so a field whose value can change either goes stale inside the number or forces a renumbering.
| Field | Can its value change during the document's life? | Where it belongs |
|---|---|---|
| Site and unit | Rarely, when a unit boundary moves | In the number; a moved boundary is recorded in the register |
| Discipline | Yes, if responsibility moves | In the number as first issued; the register records the current owner |
| Document type | No | In the number, from the register's own type list |
| Sequence | No | In the number |
| Sheet | No | In the number, or in its own title-block field |
| Revision and status | At each issue | Title block and register |
| Project code | Yes, when later projects revise a lifecycle drawing | In the number of project documents only |
| Originator | Yes, when another contractor revises the drawing | Title block and register |
| Title | Yes, when it is corrected | Title block and register |
The project and originator rows separate lifecycle documents from project documents. A progress report or a set of meeting minutes is referenced while the project runs, and a project code in its number costs nothing. A P&ID, a loop diagram or an equipment list stays in service as long as the plant, and later projects revise it.
One published owner procedure therefore numbers lifecycle documents by facility and area, numbers project documents by project, and records the originator in the title block and the register instead of the number. ISO 19650 puts the originator into the name, so a plant that adopts it needs a rule for whose code a drawing carries after another contractor revises it.
Numbering faults at MOC and handover
Duplicates. Two contractors allocate numbers from separate spreadsheets, and two documents end up with one string. ISO 7200 requires uniqueness at least within the legal owner's organization, and the ISO 19650 guidance allows no two information containers to share an identifier. Numbers come from one register, and a contractor that numbers offline works from a reserved block.
Reused numbers. A drawing cancelled at one MOC has its number issued to a new drawing at the next. The transmittals, the earlier MOC record and the tag-to-document links that cited the old drawing now point at the new one, and the register shows nothing wrong. Retire a cancelled number and keep its row with a cancelled or superseded status, the same rule that applies to equipment numbers.
New and deleted drawings under MOC. An MOC that adds content to a drawing takes the next sheet if the title still fits, and a new number if it does not. An MOC that deletes a drawing cancels the number. The MOC documentation then lists each affected document by number and revision.
Renumbering at handover. Moving a contractor's project-numbered drawings into the owner's facility series changes the register in one issue. The continuation flags, loop diagrams and datasheets that print the old numbers change only as each is next revised. Number lifecycle drawings in the owner's series from the first issue, or hand over an old-to-new cross-reference and keep the old number on each register row.
File names that drift from the number. The CFIHOS 2.0 specification requires file names to follow the owner's numbering specification and to contain only letters, digits and the _ character, with _ in place of any slash. A number written with hyphens or slashes therefore needs a stated file-name form, or the file and the register will spell the document two ways.
Broken cross-references. CFIHOS requires the contractor to maintain tag-to-document number cross-references and to check the document numbers in them against the master document register. A link keyed on a superseded or reformatted number fails that check, which is the strongest argument for numbers that stay fixed once issued.
Writing the numbering procedure
CFIHOS calls the controlling document the principal's document numbering specification. Whatever its name, it should cover:
- the format: field order, widths, separators, permitted characters and the file-name form
- the code lists for site, unit or area, discipline and document type, each with one owner and its own revision
- who issues sequence numbers, from which register, and how offline blocks are reserved
- the sheet rule for multi-sheet drawings
- revision codes and reasons for issue, held outside the number
- lifecycle documents and project documents, and the series each takes
- supplier documents, renumbered or kept under the supplier's number with a cross-reference
- retirement of cancelled and superseded numbers
- the cross-references the register carries, tag to document and document to document
For the register these numbers are filed in, see the master document register. For what handover expects of them, see CFIHOS and CFIHOS and ISO 15926 data handover.