1.0 Project Template - Revit 2022
v.22.2.1
A consistent naming strategy is critical for productivity when working in Revit
Every view, sheet, filter, family, and parameter becomes part of a living dataset. Without clear, predictable naming conventions, you end up with a lot of confusion and wasted time!
This is why with permission of Gavin Crump, I used his naming convention as a base for all parameters in the project template. Its not just a copy of Gavin’s Shared Parameters, but rather evolved version of his idea, adapted to suit electrical discipline.
1.1 Project Dashboard
Open the model and the first thing you’ll see is the Project Dashboard.
It ships with dummy data so you can see the wiring; swap the placeholders for your own project details and you’re ready to roll.
Table 1 Project Dashboard
| Zone | What it’s for | How to edit |
|---|---|---|
| Notice Board | One-liners, site memos, alerts. | Click into the text note and overwrite the sample copy. Keep it short; the board isn’t a novel. |
| Originator Information | Your company name, address, logo if you fancy. | Edit the text fields (or replace the logo image). |
| Project & Model Details | Live read-outs of Project Information parameters (number, name, stage, etc.). | Do not touch the dashboard text; go to Manage ▶ Project Information and update the parameters once—changes ripple to sheets and tags automatically. |
| Model-Health Gauge | Real-time “traffic-light” of warnings, links, view count, etc. | Powered by the family PD_GAN_ModelHealth-Gauge plus the free pyRevit “PD” extension. Install the extension to unlock the automated checks; otherwise the gauge will sit there looking pretty but static. |
| Model Revision Table | Tracks every formal issue of the model or sheets. | Uses Revit’s built-in revision system (View ▶ Revisions). We’ve pre-loaded three naming tracks: C0x — Published (C01, C02…) P0x — Shared (P01, P02…) x.01 — WIP (x.01, x.02…) |
Need a refresher on status & suitability codes?
See our cheat sheet: Table 36 – Status and Suitability
1.2 Start-up checklist
- Update Project Information parameters.
- Replace the Originator details.
- Clear the sample Notice-Board text and add your first real memo.
- Install the pyRevit PD extension if you want the gauge to light up.
- Confirm the revision sequence (C, P, or WIP) before you issue anything.
Five minutes and your dashboard will look like it was built for this project—because, well, it now is.
1.3 Pre-loaded Electrical Content
This template isn’t just a blank shell—you’re getting a turnkey starter kit that would normally cost a small fortune in add-ons. Everything listed below is wired-in, QA-checked, and ready to drop into real projects.
Table 2 Premium Families (gift-wrapped)
| Family & Version | Normal List Price | What it gives you | Where it’s used |
|---|---|---|---|
| PD_ELE_Electrical-Equipment_DistributionBoards | £ 24.90 | Parametric DB enclosure, spare-way logic, DIN-rail calc | Drives the sample Distribution-Board schedules |
| PD_ELF_Electrical-Fixture_Socket_v22.2.1 | £ 49.90 | UK twin & single sockets, data, USB, | Lighting/Small-Power legends & schedules |
| PD_LTF_Lighting-Fixture_Luminaire-Rectangular_v22.1.3 | £ 49.90 | Recessed/Surface, parametric, any size | Lighting plan, BREEAM sample notes |
Why the price tags?
We’re not being cheeky, just honest. You’re getting around £125 worth of kit, already tested. If that earns the template a second look when the next spec drops… job done.
2.0 pyREVIT
What it is
pyRevit is a free, open-source Python framework that bolts hundreds of automation, QA, and data-mining commands onto Autodesk Revit. Think Dynamo speed–but–with–Python, wrapped in a tidy ribbon tab.
Why you need it here
Several features in the PD template—the Model-Health Gauge, the one-click QA schedules launcher, and assorted right-click utilities—light up only when the PDtool pyRevit extension is present.
How to get up and running (≈ 3 minutes)
Table 3 PDtool.extension
| Step | Action |
|---|---|
| 1 | Visit https://pyrevitlabs.notion.site and grab the pyRevit installer (template tested on v 5.1.0). |
| 2 | Run the installer – it adds a “pyRevit” tab to Revit and a little gear-wheel in the Windows tray. |
| 3 | Log in to https://projectdesign.io/account/downloads/ and download PDtool.extension.zip. |
| 4 | Make a home for extensions – e.g. C:\pyRevit – and unzip the file so you end up with: C:\pyRevit\PDtool.extension\ |
| 5 | Launch (or restart) Revit – pyRevit performs an auto-scan and the new pyRevit tab appears. |
| 6 | go to pyRevit TAB >pyRevit>Settings >Add Folder> Add Paf to your pyRevit folder (as on screenshot) > Reload pyRevit |
| 7 | Open a model based on this template; the Model-Health Gauge should animate and the PD ribbon will list the QA and productivity tools. |
Follow these six steps
That’s it—automation unlocked, no code required.
3. MEP SETTINGS
3.1 Conduit Systems — sizes, lookup tables
Three conduit systems in the template, LTG-PWR (steel), LTG-PWR (PVC),and Rigid Non-metallic Conduit RNC twin-wall PVC, have been pre-set so that:
- only the pre-set diameters appear in MEP Settings ▶ Electrical ▶ Conduit Settings;
- Every elbow, automatically pulls its true outside diameter and bend geometry from an embedded CSV lookup table;
- Each elbow exposes a yes/no parameter ‘UseMinimumRadius’ so you can flip between the manufacturer’s long sweep and the BS 7671 minimum[1]≥ 2.5 × outside diameter (OD)
without the need for a second family.
Table 4 Conduit families & type codes
| System | Family/type prefix | Size catalogue (mm OD) | Bend radius table follows “long” & “min” |
|---|---|---|---|
| Steel conduit (lighting & power) | PD-703010_CNT_Conduit_LTG-PWR_steel | 20 – 63 | PD_Conduit_Elbow_Metric_Steel_v25.1.1.csv |
| Steel conduit (lighting & power) | PD-703010_CNT_Conduit_LTG-PWR_pvc | 20 – 63 | PD_Conduit_Elbow_Metric_PVC_v25.1.1.csv |
| Twin-wall PVC RNC | PD-703010_CNT_Conduit_RNC | 20 – 178 | PD_Conduit_Elbow_Metric_RNC_v25.1.1 |
Each system ships with a full set of fittings already mapped to the relevant lookup table and placed in the two view templates PD_703010-10_Containment_(working) and …(published). No type-creation required – just model.
- How the elbow decides its bend radius
Bend Radius =
IF(UseMinimumRadius,size_lookup(Conduit Size Lookup, “BRad_Min”, 2.5 * OutsideDiameter, OutsideDiameter),size_lookup(Conduit Size Lookup, “BRad_Long”, 2.5 * OutsideDiameter, OutsideDiameter))
Conduit Size Lookup points to the embedded table (PD_Conduit Elbow – Steel, …PVC, …RNC).
- Column BRad_Min stores the BS 7671 minimum; BRad_Long stores the manufacturer’s long sweep.
- If a size is missing the formula falls back to 5 × OD—still code-compliant.
What you need to remember
- Pick the correct system type (LTG-PWR, RNC) before routing.
- Tap UseMinimumRadius on when you need the tightest legal bend (e.g. congested risers).
- Filters in the Containment view templates will colour the run automatically
- Never add ad-hoc diameters: add them once in Conduit Settings and as a new row in the CSV, then reload the family.
Lookup tables in the download pack
For the tweakers among us, the three CSV files that drive those elbows are included in the template bundle:
- PD_Conduit Elbow_Metric_Steel_v1.csv
- PD_Conduit Elbow_Metric_PVC_v1.csv
- PD_Conduit Elbow_Metric_RNC_TwinWall_v1.csv[2]
They’re already embedded in the elbow family, so the system works out-of-the-box; the loose files are there purely for curiosity, audit, or future expansion (add a new size, re-import, job done).
If you don’t plan on editing bend data, feel free to ignore them—and definitely don’t delete the embedded copy, or Revit will fall back to the 2.5 × OD safety net, and your sweeps will look suspiciously tight.
PD-703010_CNT_Conduit Coupling
A single “Standard Conduit Coupling” family is assigned to every conduit type. Its only real job is to keep Revit’s Slice tool happy; we’re not interested in counting couplers, only total conduit length. In other words, modelling three-metre conduit lengths is pointless, so let’s leave the auto-couplers in place for slicing, but don’t waste time manually adding them.
PD-703010_CNT_ConduitBox_STOP_END
The template includes a standard UK Stop-End conduit box for finishing dead-end runs. Revit will not drop this fitting automatically, so add it manually when a conduit terminates.
Systems ▶ Conduit Fitting ▶ PD-703010_CNT_ConduitBox_STOP_END.
Place only where the run genuinely stops.
3.2 Pre-Loaded Electrical Toolkit
Below is an inventory of the content you just gained. Keep it handy; if it’s not on this list, you probably don’t need it.
Containment fittings (CNT- prefix)
All snap automatically onto tray, ladder, or conduit runs.
Table 5a Conduit Fittings
| Family Name | Use |
|---|---|
| PD-703010_CNT_Conduit Coupling | Auto-inserted by Slice; maintains run continuity |
| PD-703010_CNT_ConduitBox_CROSS / _TEE / _STOP_END | UK conduit boxes for cross-overs, tees, dead-ends |
| PD-703010_CNT_Conduit_ELBOW | Elbow that reads the steel/PVC/RNC lookup tables |
Table 5b Tray & Ladder Fittings
| Family Name | Use |
|---|---|
| PD_703010_Fitting_Horizontal Bend / Cross / Tee | Standard tray bends & junctions |
| PD_703010_Fitting_Vertical Inside Bend / Outside Bend | Vertical sweeps for tray runs |
| PD_703010_Fitting_Reducer / Union | Width transitions & joiners |
| PD_703010_Fitting_Ladder … (same set as above) | Ladder versions, plus Vertical Inside/Outside bends |
No hand-rotating, no “pick family” pop-ups—draw, and let Revit drop the right node.
Schematic symbols (ANS-SH- prefix)
Table 6 For Drafting Views & LV one-line diagrams.
| Symbol | Description |
|---|---|
| PD_ANS_SH_MCC | Motor-control centre |
| PD_ANS_SH_Switchboard | Main LV switchboard |
| PD_ANS_SH_Main_Earth_Terminal & …_Risers | MET symbols |
| PD_ANS_SH_Meter | kWh / sub-meter |
| PD_ANS_SH_Protective Device (vertical & horizontal) | Fuse/MCB/RCBO block |
| PD_ANS_SH_Switch Disconnector | Isolator symbol |
| PD_ANS_SH_ATS | Automatic Transfer Switch |
| PD_ANS_SH_GEN_Symbol | Standby generator |
| PD_ANS_SH_Cable_ID | Bubble for cable tag |
| PD_ANS_SH_Distribution_Box | Sub-DB bubble |
| PD_ANS_SH_EPO | Emergency-power off |
| PV suite: _PV_Array / _PV_Inverter / _PV_Isolator | Complete PV feed-in set |
All symbols use the template text style (IBM Plex Sans 2.5 mm) and respect view scale.
Annotation tags (PD_TAG- prefix)
Every tag below is already loaded and colour-matched to the text-style palette.
Table 7 Annotation tags
| Tag Family | Drops On | Key Parameters Shown |
|---|---|---|
| PD_TAG-Room | Rooms | Name, number |
| PD_TAG_Space / _Zone / _Area | Spaces / Zones | Name, number, conditioning |
| PD_TAG_Wall / _Door / _Ceiling / _Floor-Ffl-Ssl | Architectural | Type & mark data |
| Containment Tags | ||
| PD_TAG_CableTray-Size | Tray/Ladder | Width × height |
| PD_TAG_CableTray-Size-SystemServed | Tray/Ladder | Size + service |
| PD_TAG_CableTray-Size-SystemServed-InvertLevel | Tray/Ladder | Size + service + invert level |
| PD_TAG_CableTrayFitting-Size | Tray/Ladder fittings | Size |
| PD_TAG_Conduit-Size | Conduits | OD/ND |
| Electrical Equipment & Devices | ||
| PD_TAG_ElectricalEquipment_PanelName | Boards | Panel name, kVA |
| PD_TAG_LightingFixture_Type | Luminaires | Type mark, emergency flag |
| PD_TAG_FireAlarmDevice | FA devices | Address / type |
| PD_TAG_Wire_1.8 mm_CircuitReference | ||
| PD_TAG_Wire_2.5 mm_CircuitReference | Wires | Circuit ref in chosen text height |
| PD_TAG_Keynote / _Revision / _MC-FamilyDetails / _MechanicalEquipment_Type / _JoineryUnit | Misc. | Self-explanatory |
Sample drafting views
Table 8 Sample drafting views
| View Name | What it shows |
|---|---|
| Security Schematic | CCTV, ACS, intruder loops with PD_ANS_SH_ symbols |
| Typical Desk Layout Detail | Power, data, USB-C & AV outlets + clearance dims |
Both live on Sheet 00010—duplicate for new projects.
All symbols use the template text style (IBM Plex Sans 2.5 mm) and respect view scale.
3.3 Pre-configured MEP Settings
- Load Classifications – pre-populated, ready for use .
- Electrical Distribution Systems – Single Phase 230V and Three Phase 400V systems created
- Voltage Definitions – matches the UK regs tables, so panel schedules pull the correct kVA.
- Conduit & Cable-Ladder Sizes – steel EMT/IMC/RMC plus RNC twin-wall (110 mm & 150 mm).
- Wiring Types – PVC/LSF singles, MICC, FP200, etc. All wired into the Distribution-Board schedule for circuit makeup.
3.4 Panel-Schedule Templates
Table 9 Panel-Schedule Templates
| Template Name | Column Layout | Typical Use |
|---|---|---|
| PD_UK_DB_(manual + load) | One bank, With calc columns (Ib, In, kVA, demand-factor) | Design WIP to check load an dcircuit lenght |
| PD_UK_DB_(manual) (Default) | One bank, No load columns | Used for Publication |
Select the board, or hit Edit Panel Schedule Template, pick the flavour you need – job done.
3.5 Legend & Note Sheets
Table 10 Legend & Note Sheets
| Sheet ID | Size | Contents |
|---|---|---|
| PD_Legend Containment | A1&A0 | Trays, ladders, RNC colours, symbol key |
| PD_Legend Fire Alarm | A1&A0 | Device icons, loop labelling, cable types |
| PD_Legend Lighting | A1&A0 | Luminaire symbols, emergency icons, switching diagram |
| PD_Small-Power | A1&A0 | Device icons, labelling, |
| PD_Nurse-Call | A1&A0 | Device icons, labelling, |
| PD_Security | A1&A0 | Device icons, labelling, |
Feel free to copy-paste these legends to new sheets; the symbols stay live to the families.
3.6 Sample Schedules
- Design Schedules – Circuits, luminaires, small-power, cable ladders, conduit runs.
- QA Schedules – prefixed QA; Run them before sharing the model to manually purge the model
- COBie Drops – Equipment, Spaces, Attributes all mapped to template parameters.
- Containment – Sample containment runs and fittings schedules included in the template.
3.7 Pre-populated Drawing Sheets
Table 11 Pre-populated Drawing Sheets
| Sheet No. | View(s) | Purpose |
|---|---|---|
| E-10111 | Lighting plan L00, legend, notes | Shows how titles, revisions, keyplans link up |
| E-10211 | Small Power Layout | As above |
| E-10311 | Containment Layout | Combines legend, notes, and containment filter |
| DB1 | DB1 Circuit schedule | Demonstrates a panel schedule on sheet |
Swap the model views for your own and the title block.
3.8 Shared Parameters & Custom Fields
All custom parameters listed in PD_Shared Parameters_V1.0.0.csv are already loaded:
- Project parameters – feed the dashboard and drawing list.
- Family parameters – lumen output, socket rating, DB spare ways, conduit bend radius, etc.
You shouldn’t have to add a single extra parameter for a standard UK electrical job—but if you do, keep the naming convention (camelCase for one-offs, group under Electrical – Power).
4.0 NAMING STRATEGY
4.1 Use of CamelCase
What Is CamelCase?
CamelCase means capitalising each “word” in a compound name, with no spaces or underscores.
Like so: ProjectNameSubElementOption1.
It’s called CamelCase because the capital letters form “humps” (someone was feeling poetic in a CS lab).
CamelCase is used for single-entity identifiers where readability and compactness are priorities. It eliminates the need for delimiters in straightforward compound names, making it ideal for parameters, variable names, and succinct file identifiers. For complex hierarchical naming, underscores _ and brackets () or [] are used to maintain clarity and structure.”
Table 12 When to Use CamelCase in Your Naming Strategy
| Scenario | CamelCase is a Good Fit | Why |
|---|---|---|
| Short compound names | ProjectName, ViewFilter, SheetNumber | Easy to read, avoids visual clutter. |
| Internal identifiers / Parameters | FireRatingValue,ExportToIFC, RevitFamilyType | Common in software, scripting, coding standards. |
| When delimiters are unnecessary | NorthWingLayout instead of North_Wing_Layout | When the hierarchy is obvious from context. |
| File names in controlled systems | ClientDeliverableList2025 | Clean for systems that don’t like special characters. |
Table 13 When Not to Use CamelCase
| Bad Fit | Why |
|---|---|
| When you want clear separation of blocks | Use _ or - instead for multi-layered structures. |
| For optional info or annotations | Use (Option1) or [Tag] for clarity. |
| In public file shares or client deliverables | Sometimes underscores are clearer for mixed audiences. |
The Golden Rule of CamelCase
CamelCase is great for naming single “things” — entities, variables, types.
But when you’re defining relationships between “things,” use delimiters.
For example:
ClientProject_LayoutType_(Option1)
- ClientProject — CamelCase block (single entity name)
- _ delimiter for hierarchy
- LayoutType — another CamelCase block
- (Option1) — optional aside in parentheses
This naming strategy works beautifully in BIM, CAD, and structured file naming.
4.2 Use of round parentheses () and square brackets []
In this Revit template, treat round parentheses (…) as human-friendly comments e.g., (Emergency) and square brackets […] as machine-readable tags that pin down hard attributes e.g., [IP65].
Table 14 Use of round parentheses () and square brackets []
| Symbol | Used For | Tone | Example |
|---|---|---|---|
| (…) | Optional info, human-readable notes | Soft, explanatory | LuminaireSchedule_(Preliminary) |
| […] | Defining attributes, technical tags | Formal, machine-readable | FireAlarmPanel_[IP65] |
Table 15 When To Use Which (Rules of Thumb)
| Scenario | Use | Why |
|---|---|---|
| Adding optional, descriptive notes for humans | Round Parentheses (…) | They signal context but not structure |
| Defining a precise category, spec, or hard attribute | Square Brackets […] | They imply a structured, technical modifier |
| Status flags, revisions, phases (informational) | Round Parentheses (…) | Readable, non-intrusive |
| Configuration values, dimensions, controlled tags | Square Brackets […] | Machine-friendly, structured data feel |
Example:
- ContainmentHL_(working) – “Oh, by the way, this is working view.”
- ProtectedCorridor[FR120] — “This is formally part of Protected Escape Route.”
Round brackets are your side comments — they’re for people.
Square brackets are your database columns — they’re for systems.
4.3 Text Annotations on Drawings
General Guidance
- Be Direct, Be Technical, Be Measurable: e.g., 16A commando socket for data cabinet.
- Use correct electrical terminology: e.g., wired in 16mm² LSF cable to DB-01.
- Always specify units & ratings: e.g., 400V, 3-phase, 4-pole.
- Standard symbols & abbreviations: Use Ø for diameters e.g., Ø25mm conduit.
- IP ratings, kW, LUX, VA, etc., as per BS standards.
Tone & Clarity
- Neutral, instructive language: e.g., Provide RCD protection for socket outlets.
- One instruction per annotation.
- Complex notes go in specifications, not drawings
- Repetitive annotations belong to General Notes (e.g., use them in Legend)
Consistent formatting:
- Start with uppercase, no full stops unless more than one sentence.
- Example: Route containment above ceiling level
Table 16 Summary Table — Naming Cheat Sheet
| Element | Naming Format | Example | Purpose |
|---|---|---|---|
| Core Identifiers | camelCase | cableSchedule, smallPowerLayout | Compact, structured |
| Contextual Info | (Round Brackets) | lightingLayout_(Emergency) | Optional, human-readable |
| Attributes / Filters | [Square Brackets] (if used) | ProtectedCorridor[FR120] | Structured tag, for filtered schedules |
| Drawing Annotations | Short, factual technical phrases | Connect lighting circuit to DB-01 | Clear installation instruction |
Quick Note
“camelCase is how we name systems. Brackets are how we tell humans which bit we’re talking about. And text annotations? Those are not for storytelling — they’re for telling exactly what needs to happen – make it idiotproof!”
4.4 Forbidden Characters (and the One Narrow Exception)
Why “/” and “\” Are Radioactive in File Names
Slash / and back-slash \ are reserved path separators in every modern operating system. The moment you slip one into a file name, two bad things happen:
- Windows throws a tantrum – it simply will not save DB/01 schedule.xlsx.
- Cross-platform chaos – scripts, cloud sync, zip archives… they all treat the slash as “make a new folder,” not “that’s part of the name.”
Our naming strategy is meant to be WYSIWYG[1] across drawings, reports, schedules and file names.
Rule: Never use / or \ in any identifier, view, sheet, or exported file name.
The Lone Exception – Circuit Naming
Electrical circuits need to show the “path” from the board to the circuit. We keep that inside Revit parameters only, never in file names.
- Inside Revit (parameter/annotation):
DB-01/1L1 – reads as “board DB-01, circuit 1L1”. - Exported file name:
DB-01_1L1_circuitSchedule.xlsx – underscores instead of slashes.
Table 17 Notice the subtle but crucial tweak
| Context | Allowed Form |
|---|---|
| Circuit parameter/tag | DB-01/1L1 |
| Any file name, view name, sheet name | DB-01_1L1 |
The underscore _ keeps the board ID glued to the circuit ID without upsetting Windows, macOS, SharePoint, or your friendly BIM coordinator.
Why
- Searchability: Same text string appears on the drawing, in the schedule header, and in the file name. Your desktop search works.
- Automation: Batch exports, COBie drops, Dynamo routines – all run without character-encoding hacks.
Table 18 Quick Reference – Character Do’s & Don’ts
| Character | Status | Example | Notes |
|---|---|---|---|
| _ underscore | Primary delimiter | DB-01_1L1_layout | Always safe. |
| () round brackets | Optional info | lightingLayout_(Emergency) | Human-readable. |
| [] square brackets | Structured tags | ProtectedCorridor[FR120] | Use sparingly. |
| / slash | Forbidden in names | DB/01_schedule | Only inside circuit parameters. |
| \ back-slash | Absolutely forbidden | DB\01\schedule | Same reason. |
“Slashes are path separators, not punctuation. Use them in a circuit tag if you must, but never in anything that needs saving, syncing, or emailing. Underscores cost nothing and save hours of forensic file-hunting.”
[1] WYSWIG – what you see is what you get
5.0 SYSTEM CLASSIFICATION
This section explains the six-digit headers that appear at the start of every
- Revit view-template name
- Filter name / graphic-override set
- Project-browser
These headers let anyone sort or isolate content by system in a single click, while still mapping back to full Uniclass codes for data exchange.
Why we drop “Ss_” and underscores
Table 19 - Why we drop “Ss_” and underscores
| Item | Full Uniclass token | Project header | Rationale |
|---|---|---|---|
| Prefix | Ss_ | (removed) | Keeps the code numeric so it sorts naturally in both Revit and Windows Explorer. |
| Delimiters | _ (underscores) | (removed) | Removed to simplify. |
| Content | first three numeric pairs | kept | Retains the hierarchy: Group → Sub-group → Section (e.g. 70 80 33). |
| Children | fourth pair | kept only when needed | Used if two sub-systems would otherwise collide (e.g. Lightning = 70302545). |
Net result: the Uniclass string Ss_70_80_33 becomes the lean, human-friendly header 708033.
We remove nothing that affects traceability; the stripped code still back-maps one-to-one to Uniclass.
Table 20 – System Classification[1]
| Header | Description | Full Uniclass source |
|---|---|---|
| 354000 | Architectural setting-out (gridlines, control points, datums, levels) | Zz_35_40 Gridlines (CAD table) |
| 757054 | Lighting control & monitoring | Ss 75 70 54 10 |
| 708033 | Lighting (general & emergency) | Ss 70 80 33 |
| 703045 | LV distribution (mains, risers, switchgear) | Ss 70 30 45 45 |
| 703080 | Small power and data outlets | Ss 70 30 80 (merged per BEP note) |
| 751021 | Structured cabling – copper & fibre | Ss 75 10 21 |
| 751070 | Audio-visual/public AV systems | Ss 75 10 70 |
| 703010 | Cable containment (tray, ladder, basket) | Ss 70 30 10 |
| 755028 | Fire & smoke detection & alarm | Ss 75 50 28 |
| 754000 | Security (access, CCTV, intruder) – parent bucket | Ss 75 40 |
| 755011 | Nurse call & medical location systems | Ss 75 50 11 57 |
| 703025 | Earthing, bonding & lightning protection | Ss 70 30 25 (children 25/45) |
| 256030 | BWIC – service penetrations & fire-stopping | Ss 25 60 30 (building fabric) |
| 404015 | Combined services - coordination drawings | PM 40 40 15 (Project-Mgmt table) |
| 806800 | PD Standard reserved code! 80=P in ASCII, 68=D in ASCII, 00=NUL | n/a |
[1] Reference: https://uniclass.thenbs.com/
6.0 VIEW TEMPLATES
6.1 View Templates Naming Strategy
Table 21 View Templates Naming Strategy
| PDcode | [5] | SystemClassification | [6] | view series [7] | [5] | Description[8] | [5] | Optional Information in Parentheses () | [5] | version |
|---|---|---|---|---|---|---|---|---|---|---|
| PD | _ | XXXXXX | – | XX | _ | XX | _ | XX | _ | xX |
[5] Delimiter Underscore (U+0332).
[6] Delimiter Hyphen-Minus (U+002D).
[7] See section 2.9.1 Series prefix XX to distinguish layout from sections while maintaining consistency
[8] Use camelCase or hyphens to separate words in View-Description
6.2 Text Styles in the PD Revit Electrical Template — Quick Guide
Structure of a Style Name
Every text style follows the same structure
PD_<Height><mm>_<Colour>_<Weight>_<Background>_<Font Family>
Table 22 Text Style Name
| Token | Meaning | Example |
|---|---|---|
| PD | Template prefix – identifies it as ours | PD_… |
| Height | Printed text height in millimetres | 2.5mm |
| Colour | Output colour (Black or Red) | …_Black_… |
| Weight | Bold or omitted (regular) | …_Bold_… |
| Opaque | Background mask on | …_Opaque_… |
| Font Family | IBM Plex Sans flavour | IBM Plex Sans Condensed |
Rule of thumb: Pick the height first (legibility), then colour/weight for emphasis, then condensed or regular to hit the available space.
Table 23 When to Use Which Size
| Size | Typical Use | Styles Available |
|---|---|---|
| 1.5mm | Tightest dims, leader notes inside symbols | PD_1.5MM_Black |
| 2.0mm | Schedules, tagging in crowded views | PD_2.0mm_Black_Condensed |
| 2.5mm | General notes, keynotes, circuit IDs | Regular / Bold / Condensed / Red Bold / Opaque |
| 3.0mm | Equipment labels, panel titles, sub-headings | Regular / Bold |
| 3.5mm | View titles, section heads | Bold only |
| 5.0mm | Sheet titles, major drawing headings | Regular / Bold |
| 7.5mm | Cover sheet project titles, big disclaimers | Regular / Bold |
Colour & Weight Guidance
- Black Regular – default for everything that isn’t yelling.
- Black Bold – headings, titles, anything that needs hierarchy.
- Red Bold (2.5 mm only) – revision-cloud tags or critical warnings; never for permanent production text.
- Opaque – masks busy backgrounds (e.g., text over hatch) without hacking in white-mask regions.
Font Choice: Regular vs Condensed
- Regular IBM Plex Sans – easier on the eye; use unless space is genuinely tight.
- Condensed – schedules, legends, or switchboard layouts where column width is at a premium.
If you’re thinking of mixing Regular and Condensed in the same note, take a breath, have a coffee, and rethink.
Golden Rules
- Do not create new text styles – these cover every foreseeable need.
- Maintain WYSIWYG – what you see on the drawing should read the same in schedules and exported PDFs.
- Keep annotations short, factual, and technical – the style hierarchy handles emphasis; words needn’t shout.
- Never override colour or weight per instance – choose the correct style instead.
- Background mask? Use the _Opaque style, not manual masking regions.
Cheat Sheet for New Starters
Pick the smallest legible height for your note, default to Black Regular IBM Plex Sans, and escalate through Bold, Condensed, Opaque, or Red only when the layout or spec truly demands it.
Stick to these predefined styles and the entire project, drawings, schedules, PDFs, stays clean, searchable, and coordination-proof.
6.3 Dimension Styles — “Measure Twice, Model Once”
We keep dimension styles lean-and-mean: one text height, two accuracy levels, four geometry types.
If you can’t find the right style in this list, you’re either measuring the wrong thing or inventing work for yourself.
Table 24 Dimension Styles
| Style Name | Dimension Family | Purpose | Units & Rounding | Font |
|---|---|---|---|---|
| PD_DIM_2.5MM_LINEAR_STD_IBM Plex Sans | Linear / Arc length | Published lengths & offsets | Project default | IBM Plex Sans |
| PD_DIM_2.5MM_RADIUS_STD_IBM Plex Sans | Radial | Published radii & bends | Project default | IBM Plex Sans |
| PD_DIM_2.5MM_DIAMETER_STD_IBM Plex Sans | Diameter | Published diameters (luminaires, ducts) | Project default | IBM Plex Sans |
| PD_DIM_2.5MM_ANGLE_STD_IBM Plex Sans Condensed | Angular | Published angles (bracket swings, beam spreads) | Project default | IBM Plex Sans Condensed |
| PD_DIM_2.5MM_LINEAR_ACC_IBM Plex Sans Condensed | Linear / Arc length | Accuracy check — clash tolerances | 5 dp | Condensed |
| PD_DIM_2.5MM_RADIUS_ACC_IBM Plex Sans Condensed | Radial | Accuracy check — tight radii audits | 5 dp | Condensed |
| PD_DIM_2.5MM_DIAMETER_ACC_IBM Plex Sans Condensed | Diameter | Accuracy check — critical bores | 5 dp | Condensed |
| PD_DIM_2.5MM_ANGLE_ACC_IBM Plex Sans Condensed | Angular | Accuracy check — fractional-degree checks | 5 dp | Condensed |
Why the “Condensed” font for ACC styles?
Five-decimal strings are long; Condensed keeps them from trampling your symbols.
Template Rules
- Text height is always 2.5 mm – matches keynotes and general notes.
- STD vs ACC
- STD → project rounding (whole mm or one decimal place).
- ACC → 5 dp — brutal honesty for QA.
- Colour & emphasis
- STD styles print black.
- ACC styles print Red (C15959) and Bold – impossible to ignore.
- Never override per instance – if you’re tempted to click Override Units… you’re fixing the wrong problem; swap to the ACC style.
- Arc-length dimensions pick up the Linear styles. No extra family needed.
- Purge ACC dims before you issue – clients don’t want to read 12.00000 mm.
Naming Strategy
PD_DIM_2.5MM_<TYPE>_<STD/ACC>_<FontFamily>
- PD_DIM Template ID
- 5MM Text height
- <TYPE> LINEAR · RADIUS · DIAMETER · ANGLE
- <STD/ACC> Accuracy level
- <FontFamily> IBM Plex Sans (Condensed where space is tight)
60-second Workflow
- Draw with STD styles.
- Switch to ACC styles for auditing
- Review values; fix the model, not the dimension.
- Delete/hide ACC dimensions.
- Publish – sheets show only clean, rounded STD values.
One button-swap; zero nasty surprises on site.
Cheat Sheet:
“STD to publish, ACC to interrogate. If a number shows five decimals in red, you’re still in the draft.”
6.4 Revision Symbol
The Canonical Snippet
If you ask most designers for “the placeholder text,” they’ll give you the first sentence of that Latin mash-up:
“Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.”
(If you’re curious, a loose English rendering starts “Pain itself is very important to us…” — oddly poetic for boiler-plate Lipsum Hub Blog.)
7.0 DOCUMENT NAMING STRATEGY
All information in the PD Revit Template follows PROJECT DESIGN (IO) standards. the For one-page drawing naming strategy, please refer to Appendix A.
Table 25 - Information Container Identifier
| Project No | [1] | Originator | [1] | Functional Breakdown | [1] | Spatial Breakdown | [1] | Form | [1] | Discipline | [1] | Number | [2] | Title / Description |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| XXXX(XX) | - | XX(X) | - | XX | - | XX | - | X(X) | - | X | - | XXYYY | _ | Drawing |
The XX denotes the minimum number of characters for each field, the additional (XX) denotes the additional number of characters, up to the maximum number, for each field.
Note: Although BS EN ISO 19650-2 does not recommend a specific field length PD strategy follow the maximum field restrictions shown in Table 25
Standard delimiters should be used between fields to ensure correct interpretation of the information container ID by software applications.
- [1] Delimiter Hyphen-Minus (U+002D).
- [2] Delimiter Underscore (U+0332).
7.1 Project Identifier
Table 26 - Project Identifier
| Code | Project |
|---|---|
| E-5113 | ONE |
This is a single common project identifier, defined at the initiation of the project, to be used by all organizations to identify the project.
7.2 Originator
Table 27 - Originator
| Code | Organisation Name |
|---|---|
| PD | PROJECT DESIGN (IO) LTD |
7.3 Project Functional Breakdown
In the UK National Annex to BS EN ISO 19650-2, Functional Breakdown refers to the decomposition of the facility into its primary operational functions—for example, splitting a hospital into departments like A&E, radiology, and maternity. It provides a logical way to organise information and model elements based on how the asset is used, not just how it’s built.
(Think of it as sorting by what things do, not just where they sit.)
Simultaneous Working
The project can be divided by function and space to allow simultaneous working in all interlocked spaces and information containers (models), and to standardise project drawing production.
Table 28 - Functional Breakdown
| Functional ID | Description |
|---|---|
| ZZ | All spaces/areas |
| XX | Space/Area not applicable |
| 99 | Site |
| Enter ID | |
| Add additional spaces/areas as required |
Functional Federation by Discipline
The Functional Breakdown refers to the decomposition of the facility into its primary operational functions, for example, splitting a hospital into departments like A&E, radiology, and maternity. It provides a logical way to organise information and model elements based on how the asset is used, not just how it’s built. The codes representing the Functional Breakdown must be established per project.for more information please download the Information Protocol from: https://projectdesign.io/downloads/information-protocol/
7.4 Project Spatial Breakdown
The task teams shall follow the agreed level identification strategy for the project, the two-character alphanumeric identifiers shown in Table 24 to be used.
Table 29 – Spatial Identifier
Identifier | Space ID |
ZZ | Multiple lecels/locations |
XX | No Level/location/space applicable |
B1 | Basement Level -1 |
00 | Base Level/Ground Floor |
01 | Level 01 |
M1 | Mezzanine between Level 1-2 |
RF | Roof Level |
7.5 Form Identifier (ID)
The Form ID relates to a 2-character alphabetic identifier to identify the type of information held within the information container.
Identifiers defined for the project are shown in Table 25, please note the BS EN ISO 19650-2 NA 2021 Form Identifiers [*] are not used on this project and instead a project specific codes highlighted blue are to be used. The project specific codes are based on Uniclass 2015 FI Tables.
Table 30 - Form Identifier
| ID | Information Container Type |
|---|---|
| D* | Drawing (not used) |
| G* | Diagram (not used) |
| I* | Image (not used) |
| L* | List (not used) |
| M* | Model (not used) |
| T* | Textual (not used) |
| V* | Video/audio (not used) |
| AF | Animation file |
| AF | Animation file |
| AG | Agenda |
| AP | Application |
| BL | Brochure |
| BQ | Bill of quantities |
| CA | Calculations |
| CC | Contract |
| CD | Conversation record |
| CE | Certificate |
| CH | Chart |
| CM | Combined model |
| CO | Correspondence |
| CP | Cost plan |
| CR | Clash rendition |
| CT | Comment |
| DB | Database |
| DE | Diary entry |
| DG | Drawing (not used) |
| DR | Drawing rendition |
| DS | Data set |
| DT | Data sheet |
| DY | Directory |
| EM | |
| ES | Estimate |
| EW | Early warning notice |
| FM | Form |
| FN | File note |
| GU | Guide |
| HS | Health and safety |
| IE | Information exchange file |
| IM | Image |
| IN | Instruction |
| IV | Invoice |
| LF | Leaflet |
| LG | Log |
| LI | List |
| LT | Letter |
| M2 | Model - two-dimensional |
| M3 | Model - three-dimensional |
| MA | Manual |
| ME | Memo |
| MI | Minutes |
| MR | Model rendition |
| MS | Method statement |
| MX | Matrix |
| PC | Procedure |
| PE | Press release |
| PH | Photograph |
| PL | Plan |
| PO | Poster |
| PP | Presentation |
| PR | Programme |
| PS | Proposal |
| PT | Permit |
| PW | Process workflow |
| PY | Policy |
| PZ | Protocol |
| QN | Quotation |
| RD | Room data sheet |
| RG | Register |
| RI | Request |
| RN | Regulation |
| RP | Report |
| RQ | Requisition |
| SA | Schedule of accommodation |
| SC | Schematic |
| SD | Standard |
| SH | Schedule or table |
| SK | Sketch |
| SN | Snagging list |
| SO | Subcontract order |
| SP | Specification |
| ST | Study |
| SU | Survey |
| SW | Scope of works |
| SY | Strategy |
| TE | Template |
| TF | Technology file |
| TG | Training record |
| TL | Transmittal |
| TN | Transfer note |
| TQ | Technical query |
| TR | Test result |
| VA | Variation |
| VL | Valuation |
| VS | Visualization |
7.6 Discipline Identifier (ID)
The task teams shall use Discipline identifiers shown in Table 31.
Table 31 - Discipline Identifier
| ID | Role |
|---|---|
| A | architecture |
| B | building surveying |
| C | civil engineering |
| D | demolition/dismantling |
| E | electrical engineering |
| F | facilities/asset management |
| G | ground engineering |
| H | highways and transport engineering |
| I | Not used |
| K | Not used |
| L | landscape architecture |
| M | mechanical engineering |
| O | other discipline |
| P | public health engineering |
| Q | quantity surveying / cost consultancy |
| R | project management |
| S | structural engineering |
| T | town and country planning and building control |
| W | water engineering |
| X | non-discipline specific or not applicable |
| Y | topographical surveying |
| Z | multiple disciplines |
7.7 Drawing Number - Five-digit number (XXYYY)
The five-digit drawing number appended to every sheet consists of two parts:
- XX – Series prefix identifies the type of view (overall plan, schematic, detail, etc.) and always follows the master table.
- YYY – System sequence is split into Y = system group and YY = running sequence inside that group.
Put together, they create a compact, machine-sortable code—for example “60100”:
- 60 → Schedules & Diagrams (schematic)
- 1 → System group “Lighting & Lighting Control”
- 00 → First schematic in that group
Important: the full code range is 001-999 inside each series; “000” is reserved and must never be used.
With that context in mind, the detailed rules for XX and YYY are set out below.
7.7.1 Series prefix XX
The first two digits[1]:
Table 32 – Series prefix XX
| XX | Sheet type | Typical use in MEP |
|---|---|---|
| 00 | General | Legends, notes, symbols |
| 05 | Large-scale views | Non-detailed plan/elevation/section |
| 10 | Overall plan/layout | Combined-level plans |
| 11 | Part plan | Single-zone plans |
| 12 | Area plan | Zone/sector key plans |
| 15 | Overall RCP | Lighting / services ceilings |
| 16 | Part RCP | Zoned RCPs |
| 20 | Overall elevations | Internal / façade elevations |
| 30 | Overall sections | Building sections |
| 31 | Part sections | Local cut-throughs |
| 40 | User-defined | Spare |
| 50 | Details | Enlarged junctions, schematics if on detail sheets |
| 60 | Schedules & diagrams | All single-line schematics |
| 70 | User-defined | Typical details, mock-ups |
| 80 | User-defined | Reserved – For PD Dashboards, Cover Sheets, Presentations etc, |
| 90 | 3-D | 3-D, perspectives |
Rule – numbering runs 001-999 inside every XX block; 000 is permanently banned.
7.7.2 System digit Y (first digit of YYY)
Table 33 - digit Y (first digit of YYY)
| Y | System group | System cross-reference |
|---|---|---|
| 1 | Lighting & lighting control | 708033 / 757054 |
| 2 | LV power, small power & data | 703045 / 703080 |
| 3 | Cable containment | 703010 |
| 4 | Fire detection & alarm | 755028 |
| 5 | Security (access, CCTV, intruder) | 754000 |
| 6 | Nurse call & medical locations | 755011 |
| 7 | Earthing, bonding & lightning | 703025 |
| 8 | BWIC / service penetrations | 256030 |
| 9 | Combined-services coordination | 403518 |
| 0 | Reserved (not used) | not used |
The six-digit code is stored in Revit parameters and view-template names; it is not embedded in the sheet number, the numbers are based on the Uniclass “Ss” system codes used here without the prefix and delimiters
7.7.3 Sequence YY (second & third digits of YYY)
Table 34 - second & third digits of YYY
| YY range | Usage guideline |
|---|---|
| 00-09 | Schematic drawings |
| 10-29 | Primary layouts (overall or zone) |
| 30-49 | Secondary/alternate layouts (emergency, low-level, etc.) |
| 50-59 | Security-specific schematics |
| 60-69 | Spare |
| 70-79 | Specialist or tertiary layouts |
| 80-89 | Spare |
| 90-99 | Coordination / multidisciplinary views |
If you need more than one drawing in any band, increment by +1 (e.g. 10111, 10112, …).
7.7.4 Worked examples
The shortened Sheet number is shown here only the Discipline ID and Five Digit Number.
For a more detailed one-page drawing naming strategy, please refer to Appendix A.
Table 35 - Worked examples
| PD(Uniclass) system | Sheet number | Title (truncated) | Meaning |
|---|---|---|---|
| 757054_Lighting control | E-60100 | Lighting Control Schematic | Schematic (60) system (1) seq. (00) |
| 708033_Lighting | E-10111 | Lighting Layout L00 | Overall plan (10) system (1) seq. (11) |
| 708033_Emergency lighting | E-10131 | Emergency Lighting Layout | Overall plan (10) system (1) seq. (31) |
| 703045_LV distribution | E-60200 | LV Riser Schematic | Schematic (60) system (2) seq. (00) |
| 703080_Small power & data | E-10211 | Small Power & Data GA | Plan (10) system (2) seq. (11) |
| 703010_Containment – HL | E-10311 | High-Level Containment | Plan (10) system (3) seq. (11) |
| 703025_Lightning protection | E-10731 | Lightning Protection Layout | Plan (10) system (7) seq. (31) |
| 403518 Coordination RCP | E-15931 | Services Coord. RCP L01 | RCP (15) system (9) seq. (31) |
(Full file name example) 8068-PD-XX-GF-DR-E-10111_Lighting layout
7.7.5 Modeller’s checklist
- Assign the correct System cross-reference (six digits) to every view template and Revit view.
- Choose the XX series that matches the view type.
- Pick Y according to the system group
- Assign YY from the sequence bands.
- Never use YYY = 000.
- Underscore separates the drawing code from the human readable title; no other special characters.
Follow the steps above and the drawing list will self-sort, QA scripts will pass, and every stakeholder will know exactly what they’re looking at.
[1] The numbering system is based on Red Sea Global numbering system
8. METADATA
The project template has been set up to allow the use of the status, revision and classification attributes as metadata, the attributes used on this project have been based on Table NA.1 of the BS EN ISO 19650-2:2018.
The codes used on this project are shown in Table 31, revisions should be two integers, prefixed with the letter ‘P’, e.g. P01. Information containers in the ‘work in progress’ state should also have a two-integer suffix to identify the version of the preliminary revision, e.g. P02.05.
All Contractual revisions of information containers should be two integers, prefixed with the letter ‘C’, e.g. C01.
8.1 Status and Suitability
| Status Code | Suitability BS EN ISO 19650-2 2018, NA 02/2021 | Action by |
|---|---|---|
| Information State (at any project stage): Work in progress (WIP) | ||
| S0 | Information developed within a task team | [C], [B] |
| Information State (at any project stage): Shared (non-contractual) | ||
| S1 | coordination | [B], [C] |
| S2 | information/reference | [A], [B], [C] |
| S3 | review and comment | [B] |
| S4 | review and authorization | [B] |
| S5 | review and acceptance | [A] |
| Information State (at handover stage 6): Published [1] (contractual) | ||
| A1, An [2] | authorisation or acceptance | [A], [B] |
| B1, Bn | partial-authorisation or acceptance | [A], [B] |
| Action by: [A] Appointing Party, [B] Lead Appointed Party, [C] Appointed Party | ||
| [1] A published status code indicates sign-off by either the lead appointed party or the appointing party but did not describe why the information container has been issued—the reasons for issue An status code shall be defined in the project's information standard. | ||
| [2] Examples of the use of status code An | ||
| A0 - BS 8536-2 2016 Work Stage 0 - Strategy, or RIBA [3] Stage 0 - Strategic Definition A1 - BS 8536-2 2016 Work Stage 1 - Brief, or RIBA [3] Stage 1 - Preparation and Briefing A2 - BS 8536-2 2016 Work Stage 2 - Concept, or RIBA [3] Stage 2 - Concept Design A3 - BS 8536-2 2016 Work Stage 3 - Definition, or RIBA [3] Stage 3 - Spatial Coordination A4 - BS 8536-2 2016 Work Stage 4 - Design, or RIBA [3] Stage 4 - Technical Design A4 = information container Authorised and Accepted as suitable for construction A5 - BS 8536-2 2016 Work Stage 5 - Construct and commission, or RIBA [3] Stage 5 - Manufacturing and Construction A5 = Authorized and accepted as suitable as a construction record A6 - BS 8536-2 2016 Work Stage 6 - Handover and Closeout, or RIBA [3] Stage 6 - Handover A7 - BS 8536-2 2016 Work Stage 7 - Operation and End of Life, or RIBA [3] Stage 7 - Use | ||
| [3] RIBA Plan of Work 2020 |
9. DESCRIPTION
The descriptive text used to aid information container recognition can be used but shall be kept to a minimum, the description should not include information already defined in the other fields, and it shall remain the same on all revisions. To allow human recognition and ease management of information containers outside of CDE, each shared and published information container shall include status and revision reference at the end of description, the revision shall be separated by an underscore.
