BIMINAM AS BUILT INFORMATION MEETING, 13-08-2026
Date: 13 August 2026
Duration: 1 hour 25 minutes 42 seconds
Subject: Definition of As-Built Information and development of the related guidance/document
- Purpose of the Meeting
The meeting focused on refining the definition of As-Built Information, particularly what information a client/asset owner should reasonably expect at handover, how that information should be verified, and how requirements should remain useful throughout the asset's life.
A central issue identified was that designers and contractors can be reluctant to provide As-Built records because of cost, liability and risk-transfer concerns. The group felt that the underlying problem is fundamentally one of trust between clients, contractors, designers and the supply chain.
- Key Discussion Points
A. Define What the Client Actually Needs
The group agreed that the exercise should concentrate on what information is reasonable for the client to require, rather than documenting every aspect of how the project was managed.
The information should ultimately enable the client, building owner and FM/asset-management teams to operate and maintain the building safely and effectively.
There was also discussion that different users need different information. Project teams may need information such as a BIM Execution Plan, while operational teams need information that can be readily understood and used in day-to-day building operation.
B. Trust Between Client and Supply Chain
A major theme was the need to move away from a purely defensive, contractual approach.
The group discussed how excessive emphasis on liability and risk transfer can cause contractors and designers to withhold useful information. A more collaborative, trust-based approach is needed, with clients being reasonable about requirements and the supply chain being transparent about what has actually been delivered.
The group also discussed setting information requirements much earlier in the project lifecycle, potentially even before the traditional project stages begin, so that investors, developers and clients understand the information requirements before appointing contractors.
- Verification and Evidence
One of the strongest areas of agreement was that As-Built information should distinguish between:
- Information that has been verified
- Information that has not been verified
- The evidence supporting verification
The meeting proposed using a structured information delivery plan associated with each asset, specifying the evidence required for verification. This would allow users to see clearly what has and has not been verified.
The group recognised that identifying who is competent and legally responsible for verification is more complicated and should be treated as part of the “how”, rather than allowing it to prevent the definition of the required information itself.
- Responsibility and Competence
The discussion highlighted that legal duties cannot simply be transferred by appointing another consultant or advisor.
For example, where a principal contractor is also acting as principal designer, the legal duty remains with the relevant duty holder even when specialist advisors are appointed. The responsibility therefore includes appointing competent supply-chain partners and ensuring the information supplied is accurate.
The client also has an important role in confirming that the information provided satisfies its requirements.
- Information Quality and Auditability
The group identified a practical problem with specialist subcontractor information: even when templates and procedures exist, information can still contain inconsistencies.
An example discussed was door schedules containing references that do not match the references in drawings.
The group therefore supported having mechanisms to make information easier to audit, potentially using structured information that could be automatically or semi-automatically checked.
However, there was caution against relying entirely on AI for verification. Human/client resources are still required to properly review and sign off information.
- Information Requirements Must Be Controlled Throughout the Project
The group agreed that the project's information requirements should form part of the project records.
Importantly, these requirements can change during the project lifecycle, so there needs to be evidence of the changes and appropriate change control.
The information delivered should therefore be clearly associated with the relevant configuration baseline/version against which it was required.
The group also discussed the need to retain the relationship between:
Requirement → Information → Evidence → Verification
This creates a stronger audit trail and helps demonstrate that the information requested at the start of the project has actually been delivered.
- Commissioning and Evidence
A specific issue was identified with commissioning records.
Commissioning certificates are sometimes placed together in a generic folder without being linked back to the particular systems/assets they relate to. The group felt that commissioning evidence should be linked to the relevant asset/system and ultimately back to the requirement that called for the commissioning activity.
This would provide a clearer chain of evidence and support the concept of the Golden Thread.
- BIM Execution Plan and Handover
The group discussed whether the BIM Execution Plan (BEP) should form part of the handover information.
One view was that the BEP provides useful background because it explains the basis and methodology used to create the information. It could therefore help future teams understand how the asset information was structured.
However, others noted that operational teams may not directly use a construction-phase BEP. The discussion therefore moved towards the idea that information requirements and information-management arrangements should be appropriate to the relevant lifecycle stage, rather than simply handing over all project documentation without considering operational needs.
- Critical Systems and System-Level Information
An important discussion concerned systems rather than individual components.
The group noted that engineering systems, particularly MEP systems, can involve several components and subcontractors working together. Simply recording individual components may not capture the design decisions, assumptions and relationships that make the complete system work.
A concern was raised that if one component is changed, the overall system may need to be reassessed, rather than treating the change as an isolated component change.
The group supported the need for system-level assurance, particularly for critical systems, with changes being reviewed by competent designers where necessary.
The exact categories of critical systems should remain adaptable depending on the type of asset/project.
- Design Rationale and Future Changes
The meeting also highlighted that good As-Built/O&M information should retain relevant design criteria and design rationale.
This is important because future asset managers may need to understand why a particular system, component or specification was selected.
For example, if a valve or other component needs replacing many years later, the asset team needs sufficient information to understand the original requirements and ensure that the replacement continues to satisfy them.
This links directly to change control, where future modifications should be assessed against the original requirements and relevant parties consulted.
- Building Control
The group emphasised that building control approval should not be treated as the same thing as the As-Built record.
Passing through building control does not mean that all required As-Built information has automatically been captured or that building-control approval replaces the client's responsibility for its information requirements.
The As-Built document should remain focused on the information required to demonstrate and support the completed asset, rather than becoming a record of the entire project administration process.
Key Decisions / Agreements
- As-Built requirements should focus on what the client and asset team actually need.
- Verified and unverified information should be distinguishable.
- Verification should be supported by defined evidence requirements.
- Information requirements should be recorded and subject to change control throughout the project lifecycle.
- Information should be traceable back to the relevant requirements and, where applicable, contracts.
- Commissioning evidence should be linked to the relevant asset/system and requirement.
- The methodology should use common language, taxonomies and classifications rather than being specific to one Tier 1 contractor.
- The document should address system-level assurance and critical systems, not only individual assets.
- Relevant design criteria/rationale and change-control information need to remain accessible for future operation and maintenance.
- The document should avoid becoming a description of the entire project-management process; it should remain focused on defining As-Built records.
Actions / Next Steps
| Action | Responsibility |
|---|---|
| Update the As-Built document based on the meeting discussion | Anthony / drafting team |
| Rework the sections dealing with critical systems and system-level assurance | Anthony / drafting team |
| Incorporate the concept of verified vs. unverified information and evidence | Drafting team |
| Consider how information requirements and configuration baselines are recorded and controlled | Drafting team |
| Review the role of the BIM Execution Plan and lifecycle-specific information requirements | Drafting team |
| Redo/supersede the existing graphics that were identified as outdated | Infographic team |
| Review Section 12 of the document and provide comments | All participants |
| Incorporate participant comments into the final revision | George / Anthony |
| Treat absence of comments after circulation as agreement, subject to the stated process | Meeting group |
The meeting concluded with a request for participants to review Section 12, provide comments, and allow those comments to be incorporated into the final revision.
Overall Conclusion
The meeting moved the work beyond simply asking “What documents should be handed over?” toward a more structured question:
What information does the asset owner need, what evidence demonstrates that it is correct, who is responsible for it, and how can that information remain reliable throughout the asset lifecycle?
The strongest themes were trust, clear requirements from the beginning, verification/evidence, structured information, system-level assurance, change control, and practical usability for asset-management teams.