Insights6 February 2025Updated 25 October 20264 min read

Data Architecture in Construction Projects: Control the Information Handover

Building a solid foundation data architecture in construction projects infographic showing cost overrun reduction and offline data validation

Construction data architecture starts with the workflow, not the database purchase. The UK BIM Framework's common data environment guidance puts the workflow before the technology selected to support it. For a construction team, we recommend starting with a specific handover: who creates an inspection record, who checks it and which version another team may use.

Our recommendation is to design that handover before choosing a new platform. Describe the record, its owner and the decision it supports. Then test whether the proposed software preserves those details when information moves between the site and the office.

Define what each record means

Start with a record that people already need. An installation inspection is a useful example. Write down the building or asset it concerns, the location, the observation and the evidence needed to review it. Name the person responsible for checking it. Treat this as a project design exercise, not a universal inspection template.

Agree the meaning of each field before importing existing records. If one contractor identifies rooms by number and another by a drawing reference, document how the two identifiers relate. Keep an unresolved reference visible for review rather than guessing a match during migration.

This is our suggested implementation of a broader information-management principle. The 2021 Building Regulations Advisory Committee golden thread report describes information that is accurate, structured and verified. It also calls for clear responsibilities for updating and checking it. We would turn that into a named record owner and an explicit review step, rather than assume that entering data makes it trustworthy.

Separate revision from permission to use

The UK BIM Framework guidance distinguishes revision, status and classification metadata. These describe different things: which revision the information is at, what it may be used for and how it is classified. Do not collapse them into a single label called current.

For our inspection example, we recommend keeping the observation and its review state separate. A newly uploaded photograph should not, by itself, mark the installation as accepted. Define who can make that decision and what evidence they need. Show the review state wherever another person would otherwise assume the record is ready to use.

Keep the previous record when correcting an entry, with a link to the correction and its reason. Decide which changes require another review. These are proposed controls for the example, not a claim that a particular application or naming scheme satisfies every project's obligations.

Test the transfer, including its metadata

Do not assume that moving a document also preserves its meaning. The UK BIM Framework guidance asks teams to agree how metadata survives transfer between systems. Use that as an acceptance test for the handover, rather than treating a successful file upload as the end of the integration.

We suggest transferring an example inspection through the actual proposed route. Open it as the receiving team and check its asset reference, evidence and review state against the original. Include a corrected record in the test. Ask the receiving team to identify what changed without a separate explanatory email.

Choose the authoritative system for each record type and document how other systems refer to it. Where an export cannot carry a required field, resolve that gap before using the export operationally. Do not describe a collection of connected applications as a single source of truth without specifying which copy governs a decision.

Give offline work a visible state

For a field application, distinguish saving on the device from acceptance by the shared system. The W3C's Indexed Database API 2.0 recommendation defines transactions for database access and changes. That is a storage mechanism, not proof that a remote reviewer has received or approved a site record.

Our proposed interface would show whether an inspection is saved locally, awaiting transfer or accepted by the receiving service. Test those states by disconnecting a device, entering a record, closing the application and reopening it. Then reconnect and inspect the receiving system. Repeat the transfer and check the outcome rather than assuming retries are harmless.

Also test a conflicting office edit made while the device is disconnected. Agree in advance who resolves the difference. Show the user when the device last received reference information, and define which activities must stop when its information is too old for the task. These are acceptance criteria to implement and prove, not capabilities to infer from an offline feature label.

Start with a bounded change

We would begin with the inspection handover and retain its current process until the replacement passes the agreed tests. Record unresolved identifiers and review failures during the pilot. Use those observations to decide what needs changing next, without attaching a promised percentage saving to the architecture.

Ask the eventual recipient to retrieve the evidence and explain why the record is ready to use. If they need the original author to reconstruct the history, revise the handover before expanding it to another record type.

Update, October 2026

For teams adding agents to these workflows, our engineering article on grounding packs and explicit gaps in context describes dated provenance and visible unknowns. Use it when deciding what evidence an agent should receive before proposing a change to the application.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →