Developing an Industry Oriented Implementation Framework for Integrating Blockchain and Building Information Modelling (BIM) in UK Construction Projects: Enhancing Project Delivery, Commercial Governance, Risk Management and Whole-Life Asset and Sustainability

Developing an Industry Oriented Implementation Framework for Integrating Blockchain and Building Information Modelling (BIM) in UK Construction Projects: Enhancing Project Delivery, Commercial Governance, Risk Management and Whole-Life Asset and Sustainability

(1) Abdul Aziz, (2) Sayed Erfan Kazem, (3) Sohrab Donyavi

MSc – Construction Engineering Management, Department of Engineering & Construction, Lecturer, Construction Engineering Management, Department of Engineering & Construction,

Associate Professor cum Cluster Leader, Department of Engineering & Construction, School of Architecture, Computing and Engineering, University of East London, United Kingdom

Abstract- Construction projects depend on information produced by organisations with different contractual responsibilities, commercial interests and technical systems. Building Information Modelling (BIM) can structure this information, but the acceptance, provenance and subsequent use of project records remain difficult to govern across organisational boundaries. This paper develops a proposed implementation framework in which a permissioned blockchain supplements, rather than replaces, a BIM-enabled common data environment (CDE). The framework addresses four practical requirements: controlled project information exchange, accountable commercial decisions, traceable risk evidence, and reliable whole-life asset information. A design-oriented method is used to connect documented UK information-management practice with a technically specified implementation proposal. UK case studies, including the HS2 Euston rebar chain-of-custody trial, Crossrail BIM practice, the Cardiff University A556 bridge BIM, blockchain research and Centre for Digital Built Britain supply-chain research, are used to ground the framework in UK delivery conditions. A proposed concerns a hypothetical £30 million public-sector building project, with defined participants, data structures, approval rules, evaluation measures and stop/go criteria. The paper argues that blockchain should be considered only where independently controlled organisations require a shared, verifiable record and where a conventional database cannot meet that requirement more economically. Claimed improvements in payment, programme performance or sustainability must be demonstrated through comparative evaluation rather than assumed from technology.

Keywords- Building Information Modelling, blockchain integration, commercial governance, risk mitigation, asset management, whole-life carbon, common data environment, UK construction, project management.

1. Introduction

   The practical purpose of digital construction is not to accumulate more data. It is to make reliable information available to the people who must design, procure, construct, certify, operate and maintain an asset. The Royal Institution of Chartered Surveyors (RICS) describes the development of UK BIM practice towards whole-life information management under the BS EN ISO 19650 series, rather than a narrow emphasis on three- dimensional models. This paper addresses a specific implementation problem: how can separate project organisations establish what information was submitted, which version was reviewed, who accepted it, and what commercial or operational consequences followed.

   A project may already possess a capable common data environment (CDE). Nevertheless, contractual decisions can remain dispersed across formal communication portals, valuation spreadsheets, inspection systems and supplier portals. The resulting difficulty is not necessarily a lack of information; it is uncertainty over the status, authority and evidential connection of that information.

   The proposed solution is deliberately limited. Model files, drawings, inspection photographs and commercial documents remain in controlled repositories. A permissioned ledger records selected events, cryptographic references and approvals. It does not become a second document-management system. The research questions are framed to examine how a shared ledger can be used selectively and responsibly alongside an established Common Data Environment (CDE), rather than as a replacement for routine project record-keeping. Investigates project events such as approvals, contractual decisions, changes, claims or responsibility transfers- justify being recorded on a shared ledger, while routine information handling remains within ordinary CDE audit logging. Consideration of model information, supporting evidence and contractual decisions can be linked through identifiers, hashes, metadata and controlled references, without transferring professional judgement or decision-making authority to the software. Identification of the governance, security and commercial controls required for a workable UK project, including access permissions, data protection, accountability, contractual allocation of responsibilities and integration with existing assurance processes. Assesses of the benefits, costs and whole-life outcomes of a shared-ledger approach can be evaluated against a credible non-blockchain alternative, ensuring that any added complexity is justified by demonstrable improvements in traceability, verification and project governance. This selective approach is consistent with research indicating that CDEs should retain high-volume project information while a ledger anchors only critical metadata and evidence for provenance, authorisation and accountability.

2. Research Method and Boundaries

   1. Research Design

      The design proposal combines with limited review of publicly available professional and project material with engineering

      analysis of an implementation architecture. The development process comprises five steps: identify information-governance requirements, define project events suitable for shared recording, allocate responsibilities between people, contractual procedures and software, specify a controlled and establish measures capable of testing whether the proposal adds value.

   2. Evidence Classification and Limitation

      Table 1. Evidence classification

      Category	Material used	Interpretation
      Documented UK practice	ICE, RICS guidance on BIM and information management	Establishes professional context, not blockchain performance
      Documented project	Government account of Crossrail digital delivery	Establishes a relevant digital- construction example, not a blockchain case study
      UK research	Cardiff University A556 bridge BIM-blockchain research, CDBB supply- chain research	Indicates a related UK research direction and implementation issues
      Original framework	Architecture, governance and workflows	Proposed contribution requiring validation
      Hypothetical	Project value, quantities, timetable and thresholds	Test parameters, not observed project results

      The evidence review is not systematic or exhaustive. It cannot establish the prevalence of blockchain adoption across UK construction, nor support a causal estimate of its effect on payment, disputes or carbon performance. This distinction is material. A technically plausible framework is not equivalent to an economically justified deployment.

   3. Crossrail Evidence and Information Management Framework – UK Industry Context

      A UK government account identifies Crossrails use of BIM, modelling and digital asset representations in project delivery. Crossrail is relevant here because it demonstrates the importance of coordinating digital information across a complex asset lifecycle. The additional blockchain layer discussed below is this papers proposal; no Crossrail blockchain implementation or resulting saving is claimed. A related research preprint proposes linking BIM, distributed ledgers and maintenance processes, while identifying practitioner validation and simulation as subsequent work. That distinction supports the research position adopted here: practical implementation requires testing the governance and evidence chain, not merely demonstrating that software can write a transaction.

      RICS places BIM within a collaborative, whole-life information-management framework and explains the move away from older BIM level terminology towards ISO-based processes. The proposed framework therefore begins with information requirements, responsibilities and acceptance procedures. It should not begin with purchasing a blockchain platform. For each proposed ledger event, the project must first answer: what decision does this information support, who is authorised to make that decision, what evidence must exist, which information version applies, and what happens when the record is disputed or corrected?

   4. Framework Design Principles

      The CDE is to be retained as the primary information repository, with large files and sensitive documents not being replicated across ledger nodes. Decisions are to be recorded selectively, as routine model editing does not require a blockchain transaction, while events are to be recorded when responsibility, acceptance, provenance or a consequential change is established. Evidence and entitlement are to be separated, since evidence that work exists does not, by itself, establish that payment is contractually due. Accountable human authority is to be preserved, with software permitted to check completeness and route approvals, but not to independently decide disputed contractual matters.

      Figure 1. Proposed BIMblockchain implementation architecture.

      The system is to be designed for correction, so that an accepted record which is later found to be inaccurate can be superseded or challenged without concealing the original sequence. Sensitive information is to be minimised, with personal details, pricing breakdowns and security-sensitive asset information remaining outside the shared ledger wherever practicable.

      Finally, the simpler alternative is to be tested, as sufficient assurance may be provided by a well-managed database with digital signatures and independent backups at a lower cost. Passive constructions are commonly used in formal writing to focus on the action or outcome rather than the actor.

   5. Technical Architecture

      Table 2. Layered arrangement

      Layer	Function	Proposed implementation rule
      Information requirements	Defines required deliverables and acceptance criteria	Agree before system configuration
      CDE and model repositories	Stores models, drawings and evidence	Maintain revision and access controls

      Integration service	Connects project systems	Use documented APIs and controlled event mappings
      Identity service	Establishes user and organisation authority	Separate authentication from approval authority
      Permissioned ledger	Records selected shared events	Admit only governed participants
      Workflow service	Applies completeness and routing rules	Require human approval for consequential decisions
      Reporting and export	Supports audit and handover	Provide usable exports independent of the supplier

      accepted evidence. The commercial team reviews the relevant application and contractual position. The authorised certifier makes the payment decision. Subsequent corrections are recorded as linked events. The ledger supports traceability across these stages. It does not make them interchangeable.

      Table 3. Practical workflow: automation and safeguards

      Activity	Proposed automation	Required safeguard
      Missing-document check	Automatic	Allow documented exceptions
      Revision consistency check	Automatic	Resolve conflicting source identifiers
      Inspection routing	Automatic	Confirm current delegation
      Technical acceptance	Human decision	Record reviewer and scope
      Valuation recommendation	Assisted calculation	Quantity surveyor review
      Contractual notice	Controlled workflow	Verify form, timing and authority
      Payment instruction	Separate authorisation	No direct trigger from model status
      Disputed change	Human determination	Preserve dispute and escalation routes

      Figure 2. Proposed industry-oriented BIMblockchain implementation framework (original conceptual design).

   6. Minimum event structure, Integrity and Availability

      A record should be sufficiently specific to support independent review without exposing the underlying document unnecessarily. An illustrative event structure is shown below. These are illustrative field names. Final identifiers and status values must be mapped to the projects actual information conventions.

      For a document D, a digest can be calculated as h = H(D). Comparing a later digest with the recorded digest can identify whether the retrieved file differs from the referenced file. However, matching digests do not establish that the original inspection was competent, the information was factually correct, or the approver had contractual authority. The architecture must therefore preserve three separate controls: content integrity, information availability and decision authority.

      1. Project Delivery and Commercial Governance

         1. Practical workflow and Smart-contract boundaries

            Consider a fabricated steel package. The supplier submits component identifiers, inspection documentation and delivery evidence. The integration service checks required fields and references model objects. The authorised inspection team records its decision. The ledger records the decision and references the

            Before a live, the projects legal and commercial advisers should map these workflows to the chosen contract and applicable jurisdiction. The framework is not a substitute for that exercise.

         2. Change control, Risk and Assurance

            A proposed change should connect the initiating instruction, affected information, programme assessment, commercial assessment and final decision. The event history should distinguish a request from an instruction, a quotation from an agreed valuation, technical acceptance from commercial agreement, a revised forecast from an accepted programme, and a complete submission from an approved submission. These distinctions are essential to prevent a technically convenient status label from acquiring an unintended contractual meaning.

            Table 4. Principal risks and failure testing

            Risk

            Practical consequence

            Proposed control

            Accountable owner

            Incorrect source evidence

            Reliable record of an unreliable statement

            Independent checks and sampling

            Quality manager

            Compromised credentials

            Unauthorised approval

            Strong authentication and rapid revocation

            Security lead

            Missing off- ledger file

            Digest cannot support document retrieval

            Retention, backup and restoration tests

            Information manager

            Integration error

            Wrong asset or revision linked

            Reconciliation and exception reporting

            Integration lead

            Supplier withdrawal

            Loss of continuity

            Export and transition provisions

            Client sponsor

            Incorrect workflow rule	Approval routed or applied wrongly	Versioned rules and controlled release	Commercial lead
            Excessive disclosure	Commercial or personal information exposed	Data minimisation and permission review	Data- governance lead

            sustainability credentials and carbon-related data. The platform also provided a dashboard for project managers and contractors to review delivered quantities, product conformity and certification status.

            Event	Submitted by	Blockchain record
            Mill batch created	Steel producer or certified data provider	Batch identity, mill reference, product specification and certificate hash
            Fabrication completed	Fabricator	Fabrication date, fabrication facility, drawing reference and quality record hash
            Delivery accepted	Site logistics or receiving team	Delivery date, quantity, location, receiving person and inspection status
            Material approved for installation	Site engineer or quality manager	Approval decision, BIM object reference and inspection record hash
            Product substitution approved	Designer or contractor	Original specification, proposed substitute, approval basis and approver identity
            Carbon evidence submitted	Supplier or sustainability lead	EPD reference, carbon factor source, quantity and assessment method reference

            Table 5. HS2 Euston: blockchain event record

            It should test operational failure, not just successful transactions. Proposed tests include a revoked user attempting approval, a duplicate event, unavailable CDE evidence, a mismatched model reference, a failed validator node and a contested inspection. Acceptance requires evidence that the system can detect the condition, preserve the appropriate record and restore a workable process. Security classification should precede event design. Where asset identifiers or document references disclose sensitive locations or functions, the project should reconsider whether they belong in a shared record at all.

      2. Whole-Life Assets and Sustainability – Asset information, Carbon evidence and Net sustainability effect

      An operational asset record should connect the installed component to its accepted documentation, commissioning evidence, maintenance requirements and subsequent replacement history. The proposed ledger records the sequence of relevant decisions. The asset information system remains responsible for presenting usable information to maintainers. A material record could reference product and manufacturer identity, installed quantity and measurement basis; environmental declaration reference, declared unit and relevant assessment boundary, transport and site assumptions, replacement assumptions, and reviewer and acceptance status. These fields support traceability, they do not guarantee comparability between environmental declarations. Blockchain is not inherently a carbon-reduction measure. The evaluation should compare any improvement in material decisions or record quality with additional hosting, integration and administrative burdens. A useful distinction is between better carbon evidence and lower carbon impact. The former may enable the latter but does not demonstrate it.

3. Case Studies

   1. HS2 Euston station: digital chain of custody for steel reinforcement

      The HS2 Euston station project, delivered by the Mace Dragados Joint Venture (MDJV), trialled the CARES Cloud digital chain-of-custody system for steel reinforcement. The work was carried out with CARES, the UK Certification Authority for Reinforcing Steels, and Digital Construction Solutions. The trial tracked batches of reinforcing steel from the steel mill, through off-site fabrication, to delivery at the Euston station site. This makes it one of the most relevant UK examples for the proposed framework because it addresses a clear practical problem: proving where a critical construction material came from, whether it met the required specification, and what assurance evidence supported its use. CARES Cloud provided a digital record of each rebar batch, including origin of the steel, fabrication and processing history, delivery to site, product conformity information, quality assurance evidence, certification and approval status,

      The HS2 case demonstrates that traceability is most valuable when it is tied to a physical product batch and a defined quality or compliance requirement. It also shows that the data must be usable by project teams, not simply stored in a technical ledger. The HS2 trial specifically reported improved assurance evidence, reliable product information and connectivity to project BIM models through APIs. The practical lesson is that blockchain should sit behind a usable interface. Site teams should not be expected to interact directly with a distributed ledger. They should continue using familiar mobile forms, QR codes, delivery systems or quality-management applications, while selected events are written to the blockchain automatically.

   2. Crossrail / Elizabeth Line: BIM as an enterprise information environment

      Crossrail, now operating as the Elizabeth Line, developed its main programme information environment between 2008 and 2012. This environment included many of the elements now associated with BIM, including structured project information, design coordination and construction progress information. The Crossrail Learning Legacy describes how BIM was used across design and construction, including the use of augmented reality to capture construction progress against a 3D model and feed that information back into a 4D planning environment.

      Table 6. Crossrail: BIM and blockchain roles

      Process	BIM role	Blockchain role
      Interface approval	Identifies the affected assets, systems and responsible parties	Records approval, approver identity, timestamp and approved model version
      Construction progress	Links field-captured progress to the 4D model	Records verified completion of a defined work package

      Quality assurance	Links inspection records to asset or component identifiers	Records inspection outcome, defects and closure evidence
      Handover	Structures asset data for operational use	Records acceptance of asset data and commissioning evidence

      The Crossrail experience supports the view that BIM should be treated as an information-management system, not simply a modelling exercise. It also shows why blockchains should be selective. On a programme of this scale, recording every transaction would be impractical and expensive. The framework should therefore target events with a clear governance consequence. For example, an interface between tunnelling, utilities, track, signalling and station systems may require formal acceptance by multiple parties. That is a stronger candidate for blockchain verification than a routine internal design comment.

   3. Highways England A556 bridge project: BIM and blockchain trial

      A Cardiff University research project developed and tested a framework for integrating blockchain and BIM on a real UK highway project: the construction of a new bridge on the A556, with data and processes provided by Costain. The study applied BIM and blockchain to a multi-disciplinary construction project and examined how the technologies could support data and document sharing between stakeholders. The research specifically explored a blockchain-based BIM provenance model to improve traceability, transparency and accountability of BIM data.

      The Centre for Digital Built Britain (CDBB) sponsored research into blockchain-enabled construction supply chains, led by Dr Algan Tezel at the University of Huddersfield. The project examined the potential, requirements and implementation parameters for blockchain in architecture, engineering and construction supply chains. The research involved 33 interviews with subject experts, identified application opportunities and implementation issues, and developed three demonstration models: project bank accounts and payments, reverse auctions, and asset tokenisation. The project also gathered feedback from contractors, clients, blockchain developers and academics through focus groups and an industry workshop involving 28 participants.

      Table 8. CDBB: blockchain applications and cautions

      Application area	Potential use in UK projects	Implementation caution
      Project bank accounts and payments	Record payment applications, certifications and settlement events	Does not replace contractual certification, retention or insolvency rules
      Reverse auctions	Record bid submissions, award decisions and contract formation	Requires procurement-law and confidentiality review
      Asset tokenisation	Represent ownership, maintenance rights or carbon claims	Requires legal and regulatory advice
      Supply-chain traceability	Link product batches to delivery and installation records	Requires reliable source data and supplier participation
      Information management	Record approvals, revisions and evidence references	Must not duplicate the CDE
      Governance and assurance	Record decisions and delegated authority	Requires clear role definitions

      BIM event	Blockchain verification event	Commercial or delivery value
      Model revision issued	Records version, author, timestamp and document hash	Establishes which model version was current
      Design review completed	Records reviewer, decision and comments reference	Reduces uncertainty over approval status
      Change request raised	Records requester, affected objects and supporting evidence	Creates a reliable change history
      Change approved	Records approver, approval basis and commercial impact reference	Links design change to commercial governance
      Construction information issued	Records issued-for-construction status and approval	Reduces disputes over what was authorised for build
      Asset data accepted	Records acceptance of asset data against requirements	Improves handover assurance

      Table 7. A556: BIM events and blockchain verification

      The A556 study shows that blockchain is most credible when it addresses a specific weakness in BIM governance: proving the origin, sequence and approval history of model information. It also confirms that the technology should be integrated with real project processes rather than tested only in a laboratory environment.

   4. Centre for Digital Built Britain: blockchain-enabled construction supply chains

      The CDBB work suggests that blockchain s should begin with a narrow commercial process where the rules are already clear. Payment certification is a good example, provided the system is designed as an evidence and workflow layer rather than an autonomous decisionmaker.

   5. Manchester Town Hall and Cookham Wood: BIM value evidence

      Two earlier UK public-sector examples are useful for framing the business case for BIM-led digital delivery. The Manchester Town Hall project was described as a government BIM that demonstrated value during preconstruction and production delivery. It reportedly avoided unnecessary temporary works and saved nine months on the programme. The Ministry of Justices Cookham Wood prison project, valued at £20 million, reportedly achieved an 18% saving through effective use of BIM in design and procurement.

      These examples are not blockchain case studies. Their value is that they show the type of benefit a BIMblockchain framework should protect and extend: better information, earlier decisions, reduced waste and improved asset readiness. A blockchain layer would be relevant where the project needs to prove that a design decision, material substitution, approval or commercial instruction was properly authorised. For example, if a design

      change avoids temporary works, the framework should preserve the evidence linking the change request, technical approval, cost impact, programme impact and authorised instruction. The lesson is that digital tools must be connected to a business decision. A blockchain record has little value if it is not linked to cost saving, risk reduction, compliance requirement or asset-management benefit.

4. Proposed Parameters

   1. Selection Criteria and Pilot Profile

      Table 9. Selection criteria

      Criterion	Minimum requirement
      Business problem	There is a defined cost, time, quality, compliance or asset- data problem
      BIM maturity	The project already uses CDE and has structured models or asset data
      Contractual clarity	Roles, approvals, notices and payment processes are clearly defined
      Participant willingness	At least three key parties are willing to share defined data
      Data quality	Source data can be verified and linked to a stable identifier
      Measurable outcome	Baseline data and agreed success measures
      Controlled scope	Can be limited to one package, system or work area
      Exit route	The project can revert to conventional processes if fails

      Parameter	Recommened setting
      Duration	12 weeks
      Preparation period	4 weeks before live use
      Scope	One work package, building zone or infrastructure section
      Participants	Client or asset owner, principal contractor, one designer, one key subcontractor and one supplier
      BIM scope	One coordinated model area and its associated documents and asset data
      Blockchain type	Permissioned network with controlled participant access
      Data stored on-chain	Event metadata, hashes, approvals and references only
      Data stored off-chain	Models, drawings, certificates, photographs, contracts and large files
      Integration	CDE, quality-management system and finance or procurement system
      Governance	Blockchain participation agreement, responsibility matrix and approval rules
      Review point	Fortnightly steering-group review
      Success threshold	At least 80% of required events recorded with complete mandatory metadata

      Table 10. Recommended pilot profile

      Figure 3. Twelve-week proof-of-value sequence.

      Figure 4. Proposed twelve-month implementation sequence (for a fuller deployment; the 12-week proof of value is a subset).

   2. Use case: critical material provenance

      This is the strongest first because it has clear commercial, quality and sustainability rationale. Selection of one high-value material package, such as reinforcement steel, structural steel, precast concrete units, fire-rated doors or compartmentation products, cladding or façade components, low-carbon concrete or ementitious materials, or mechanical and electrical equipment with warranty and maintenance requirements.

      Table 11. Material provenance: participant roles

      Participant	Role in
      Client or asset owner	Defines assurance and carbon-reporting requirements
      Principal contractor	Manages delivery, acceptance and installation records
      Designer	Approves product substitution and technical compliance
      Supplier or manufacturer	Provides product, batch, certification and carbon data
      Quality manager	Confirms inspection and acceptance
      Commercial team	Links approved material data to procurement and payment records
      Blockchain administrator	Manages access, permissions and technical operation

      Table 12. Material provenance: measures

      Measure	Baseline	Target
      Percentage of deliveries with complete provenance data	Establish during first two weeks	At least 90%
      Percentage of critical materials linked to BIM object	Establish during first two weeks	At least 85%
      Time to locate product certificate or compliance evidence	Establish current average	At least 30% reduction
      Number of product substitutions without a complete approval record	Establish current number	0 unrecorded substitutions

      Percentage of carbon evidence linked to approved source data	Establish current position	At least 80%
      User satisfaction with recording process	Survey after	At least 70% positive

      Table 14. Work-package completion and payment assurance: measures

      Measure	Baseline	Target
      Time from application to certification	Establish current average	At least 20% reduction
      Percentage of applications with complete supporting evidence	Establish current position	At least 95%
      Number of payment queries caused by missing evidence	Establish current number	At least 30% reduction
      Percentage of certified values traceable to approved progress evidence	Establish current position	At least 95%
      Disputes over progress or completion status	Establish current number	At least 25% reduction

      Figure 5. Material-provenance use case: performance targets.

   3. Use case: design approval and change provenance

      This is suitable where design coordination, change control or design responsibility is a known problem. Selection on one design discipline or a defined construction zone, such as structural steelwork, facade, mechanical, electrical and public-health services, rail systems interface, tunnel or utilities interface, or a refurbishment package with multiple existing-condition constraints.

      Table 13. Design approval and change provenance: measures

      Measure	Baseline	Target
      Percentage of changes with complete approval history	Establish current position	At least 95%
      Time to identify current approved model version	Establish current average	At least 40% reduction
      Number of changes with unclear approval responsibility	Establish current number	Zero
      Percentage of changes linked to cost and programme impact	Establish current position	At least 90%
      Disputes relating to design status	Establish current number	No increase; target reduction in repeat queries

   4. Use case: work-package completion and payment assurance

      This is suitable where payment applications, progress records or subcontractor certification are disputed or slow. Selection of one measurable subcontract package, such as groundworks, structural frame, drylining, mechanical installation, electrical containment and installation, facade installation, rail systems installation, or highway structures package.

      Figure 6. Material approval and payment-assurance workflow.

   5. Use case: handover and asset-data assurance

      This is suitable where the client has a clear operational need for reliable asset information. Selection of one operational system or building zone, such as heating, ventilation and air conditioning, fire detection and alarm, lifts and escalators, electrical distribution, water and drainage, track, signalling or communications systems, or a single building floor or station zone.

      Table 15. Handover and asset-data assurance: measures

      Measure	Baseline	Target
      Percentage of assets with complete required data	Establish current position	At least 90%
      Time to locate an asset record during operation	Establish current average	At least 40% reduction
      Percentage of commissioning results linked to asset identifier	Establish current position	At least 95%
      Number of handover information gaps	Establish current number	At least 50% reduction
      Asset-owner acceptance rate at first submission	Establish current position	At least 80%

      1. Governance and Data Rules

         1. Blockchain participation agreement, Data minimization, access control and assurance arrangements

            Before the begins, each participating organisation should sign a short participation agreement covering: purpose and scope of the, named users and authorised roles, data that may be submitted, data that must not be submitted, approval and certification rules, access rights and confidentiality, data retention and deletion, cyber-security obligations, liability and indemnity, exit arrangements, and intellectual property and data ownership.

            It should follow a strict data-minimisation approach. The blockchain should contain only: event type, timestamp, participant identity, project and package reference, BIM object or asset identifier, hash of the supporting document or data set, approval status, and relevant contractual or process reference. It should not contain: full models, drawings, contract documents, cost build-ups, personal data, commercially sensitive pricing, large photographic files, or complete supplier records.

            Table 16. Data minimisation, access control and assurance arrangements

            Role	Read access	Write access	Approval access
            Client representative	Yes	Limited	For client acceptance events
            Project director	Yes	No	For strategic approvals
            Commercial lead	Yes,subject to confidentiality	Yes	For commercial events
            Design lead	Yes	Yes	For design approvals
            Site manager	Limited to relevant package	Yes	For site progress events
            Quality manager	Yes	Yes	For inspection and acceptance events
            Supplier	Limited to own products and deliveries	Yes	For supplier- submitted events
            Auditor	Yes, read-only	No	No
            System administrator	Technical access only	Technical configuration only	No commercial approval rights

            Figure 7. Access based people involvement in a project

            Figure 8. Governance: access and approval rights by role.

            It should include independent assurance at three points: before go-live, review of governance, permissions, data standards and cyber-security controls; mid-, review of data quality, user adoption and process compliance; and after, review of benefits, costs, risks and scalability. The assurance review should consider whether the blockchain record would be useful if there were a dispute, audit, insurance claim, regulatory inquiry or asset- refurbishment project in five years time.

         2. Evaluation and Business Case

            Table 17. Outcome measures

            Measure	Definition	Interpretation
            Evidence assembly time	Staff minutes per complete assessment package	Administrative efficiency
            Approval cycle	Time between complete submission and decision	Decision responsiveness
            Revision mismatches	Incorrect references per reviewed sample	Information- control quality
            Retrieval success	Required evidence retrieved within agreed time	Record usability
            Completeness	Accepted required fields divided by required fields	Handover readiness
            Disputed-event frequency	Challenged decisions per comparable event class	Governance signal
            Total operating cost	Hosting, integration, support and staff effort	Economic burden

            Figure 9. Outcome measures and desired direction of change

            Payment timing should be analysed separately from evidence assembly and approval time. Otherwise, changes in cash flow may be incorrectly attributed to the ledger.

         3. Comparative analysis and economic threshold

            Where suitable comparison packages exist, an exploratory difference-in-differences estimate could be calculated: Interpretation would remain limited by package differences, small samples and non-random allocation. If the packages are not sufficiently comparable, the study should report descriptive findings rather than imply causal attribution.

            An illustrative break-even calculation is: N = C / (t × s), where C is incremental annual cost, t- is time saved per event and s- is the relevant staff cost per hour. For an assumed £24,000 annual incremental cost, 0.5 hours saved per event and £60 per staff hour, break-even requires 800 events annually. This example excludes

            financing effects, tax and unverified dispute savings; it is not a forecast.

            Figure 10. Annual Staff-Time Savings vs. Incremental Cost: Break-Even

            Analysis

         4. Stop/go criteria

      The stop or go criteria should be applied where the required evidence cannot be reliably retrieved, where unauthorised approvals may be possible, where the export cannot support independent review, where supplier participation would create a disproportionate administrative burden, or where the comparator provides equivalent assurance at a lower whole-life cost. Continuation should depend on measured performance and agreed tolerances, not a general commitment to blockchain adoption.

5. Discussion

   The proposed contribution is a bounded governance architecture rather than a claim that construction requires decentralisation everywhere. Its strongest potential application is a recurring decision process shared by organisations that need independently verifiable records. Its weakest application is an internal workflow already controlled effectively by one accountable organisation. The central implementation difficulty is likely to be agreement over meaning: what constitutes complete evidence, who can accept it, and how a disputed decision is corrected. A ledger can preserve the answers adopted by the project; it cannot negotiate those answers.

   For smaller suppliers, the interface should remain simple. A supplier should not need specialist blockchain knowledge to upload evidence, review its status or challenge an incorrect record. Whole-life value also depends on continuity. A record that cannot be interpreted or retrieved after the construction team demobilises is not a successful handover, however securely its digest was recorded.

6. Conclusions and Further Research

This paper proposes integrating a permissioned ledger with existing BIM-enabled information management, rather than replacing established repositories or contractual procedures. The proposed tests three propositions: whether shared event records improve evidence traceability, whether the improvement is operationally usable, and whether it justifies the additional cost. Further research should include practitioner review, contract-

specific legal assessment, prototype testing, supplier usability testing and independent conomic evaluation. Until those stages are completed, the framework should be treated as a reasoned implementation proposal rather than a validated industry solution.

References

1. Tezel, A. (2026) Toward Blockchain-enabled construction supply chains: Potential, requirements and implementation. Centre for Digital Built Britain, University of Cambridge.

2. Royal Institution of Chartered Surveyors (2023) The future of BIM: Digital transformation in the UK construction and infrastructure sector. 1st edn. RICS Practice Information. London: RICS.

3. Yaga, D., Mell, P., Roby, N. and Scarfone, K. (2018) Blockchain technology overview. NIST Interagency/Internal Report 8202. Gaithersburg, MD: National Institute of Standards and Technology.

4. Li, J. and Kassem, M. (2021) ‘Applications of distributed ledger technology (DLT) and Blockchain-enabled smart contracts in construction’, Automation in Construction, 132, article 103955.

5. British Standards Institution (2018a) BS EN ISO 19650- 1:2018: Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) – Information management using building information modelling – Part 1: Concepts and principles. London: BSI.

6. British Standards Institution (2018b) BS EN ISO 19650- 2:2018: Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) – Information management using building information modelling – Part 2: Delivery phase of the assets. London: BSI.

7. Celik, Y. (2024) A novel framework for integrating blockchain and building information modelling in construction projects. PhD thesis. Cardiff University.

8. Abdul Aziz, A. and Donyavi, S. (n.d.) ‘A comparison between SMEs and large companies to run a construction project in the UK: Project management practices, challenges, and outcomes’.

9. British Standards Institution (2020) BS EN ISO 19650- 5:2020: Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) – Information management using building information modelling – Part 5: Security-minded approach to information management. London: BSI.

10. Aziz, A. and Farahat, H. (2026) ‘Commercial governance and technical risk mitigation in complex United Kingdom’s rail infrastructure: A critical evaluation of pre-contract procurement strategies and post-contract performance under NEC4 ECC Option C on the Transpennine Route Upgrade’, International Journal of Scientific Research in Engineering & Technology, 6(5), pp. 150-166.

11. Infrastructure and Projects Authority (2023) ‘Data and digitalization – powering the UK’s major government projects’, 6 December.

12. Office for National Statistics (2026) Construction statistics, Great Britain: 2024. 19 February. Newport: Office for National Statistics.

13. Kinsey, A. (2024) ‘Digitising the chain of custody for Rebar: CARES Cloud’, HS2 Learning Legacy, 25 November.

14. Aziz, A. and Donyavi, S. (2026) ‘A performance-based engineering framework for sustainable urban regeneration: Integrating environmental compliance, stakeholder requirements and infrastructure resilience at Millennium Mills, London Docklands’, International Journal of Creative Research Thoughts, 14(10), pp. d10- d22.

15. Reed, D. (2017) ‘Eight-stage guide to implementing BIM on a project’, The Structural Engineer, 95(7), pp. 28-30.

16. BIM Panel (2020) ‘What’s changed in the revised CIC BIM Protocol?’, The Structural Engineer, 98(7), p. 2.

17. Oliveira, T.R. de, Tam, V.W.Y., Chaer, I., Boer, D., Haddad, A. and Najjar, M.K. (2025) ‘Construction informatics and BIM to empower informed decisions in project management’, Proceedings of the Institution of Civil Engineers- Engineering Sustainability, 179(2), pp. 127-142.

18. Aziz, A. and Farahat, H. (2026) ‘Integrating technical innovation, procurement strategies, and engineering leadership in sustainable construction practices: Practical lessons from Bloomberg European HQ, London’.

19. Institution of Civil Engineers (2023) Leveraging the relationship between BIM and Asset Management. London: Institution of Civil Engineers.

20. Low-Macrae, A. (2022) ‘Rebuilding trust with blockchain technology’, The Structural Engineer, 100(2), pp. 30-31.