On large projects in Saudi Arabia, the last stage of a BIM contract is often the most demanding. The model has to match what was actually built, follow the client’s naming and data standards on every element, and come with sheets that agree with the client’s as-built drawing set. Taking a Revit model from LOD 400 to LOD 500 is mostly careful, repetitive checking, and on a project with many models and several modelers, small inconsistencies multiply quickly.
We have built our own tools for this work, running inside Revit. The short video below shows the sequence, and this article explains each step.
What LOD 500 means in practice
At LOD 400, elements are modeled with the detail needed for fabrication and installation. LOD 500 is a field-verified, as-built representation: the size, location and orientation of elements are confirmed against what was constructed, and the model carries the information the owner needs to operate the building.
On giga-projects that information is defined by the client: parameter lists, naming rules, room and asset numbering and drawing standards, often running to dozens of fields per element. Getting all of it right, on every element of every model, is where most of the effort goes.
Our workflow, step by step
1. Compare each as-built revision
When the client issues a new revision of the as-built drawings, we compare it with the previous one sheet by sheet and list every change: a partition moved, a room renamed, a dimension updated. The same data is checked against the model, so nothing in a new revision is missed.
2. Rooms from the drawings
Room numbers and names are read from the as-built drawings and door schedules and written into the model exactly as the drawings show them. Rooms that exist on one side only, or carry a different number, are listed for the modeler to resolve.
3. The client’s naming standard
Family types, families and views are renamed to the client’s convention. Where two old types end up with the same name, they are merged and their elements moved to the remaining type. Views placed on sheets keep their printed titles.
4. Client data and schedules
Each client defines the parameters a handover model must carry. Our tools fill them on every element: element IDs, levels, room numbers and names, area classification, and type values learned from models the client has already accepted. Values that only the client can give per model, such as activity IDs and planning zones, are asked once and shared with the whole team, so every model carries the same standard regardless of who modeled it. Duplicate or misspelled parameters are merged into the client’s own, and the schedules follow.
5. MEP clash detection and openings
The MEP models are linked into our model and only read, never changed. Every MEP run is checked against our walls, floors, roofs and ceilings, and each clash is classified:
- Opening needed: the run passes through the element.
- Coordinate: the elements overlap but the run does not pass through, so the position is agreed with the MEP designer.
- Information: an overlap of 15 mm or less, listed only.
For the clashes we approve, openings are placed at the MEP size plus 15 mm clearance on each side, using the project’s void families. Openings that no MEP run passes through any more are found and closed. The status of every clash is kept from one run to the next, so each coordination round starts where the last one ended.
6. Sheets and PDFs
Each sheet is renumbered to the client’s drawing number, and its title block and revision history are filled from the as-built set. The sheets are then exported as PDFs, named like the client’s files, and checked against the client’s drawings before submission.
Why it matters
- Consistency. The rules are written once and applied the same way by every modeler, on every model.
- Time where it counts. Our engineers spend their time on what needs judgment, such as resolving where the drawings and the model disagree, rather than on data entry.
- Ready for the next standard. Each client’s rules are held in one project settings file, so the same tools carry over to a new project with a different standard.
- Fewer surprises at submission. Models, schedules and sheets are checked against the client’s own documents before they are issued.
Where we use it
We are using this workflow on LOD 500 handover models for a resort project on the Red Sea coast, as part of our wider BIM services on Saudi giga-projects. It sits alongside Scan-to-BIM from our own drone LiDAR survey (see drone-based mapping) and our structural and architectural services.
If your team is preparing LOD 500 or handover models, send us the BIM execution plan or the client’s requirements and we will reply with scope, timeline and a price. Contact us.
Dr. Muhammad Fahad is a fantastic technical resource of the subject matter and delivers quality in a timely manner.
He is highly recommended for it.
Spot on! I know firsthand how tedious the jump from LOD 400 to LOD 500 can be on large projects. The way you’ve streamlined this workflow is brilliant.
For anyone looking for top-tier BIM handover support, I genuinely recommend reaching out Masar Albinna Alfani (MAA)—they know this space inside out!
Read through the article and I would like to add that large scale projects have needed a higher level of detail and tagging for not only readability purposes but also for client verification, billing and QA purposes, as well as early detection of bottlenecks and progress tracking. Hoping to see wide applicability of this work across the construction space and a well done to Mbalfani for spearheading this initiative.
Thank you, Muhibullah, Junaid and Ehsaan, for reading and for the kind words.
Ehsaan, you’re right: on large projects the element data does far more than make drawings readable. Clean IDs, room references and activity codes are what make client verification, billing checks and progress tracking possible from the model. That’s a good subject for a follow-up article.
Junaid, the jump from LOD 400 to LOD 500 is where most of the hours go, so it was the obvious place to start.