How to Build a Single Source of Truth for Construction Data

A single source of truth for construction data is a governed information environment in which each data domain has a defined authoritative source, shared identifiers and controlled workflows. It is built around a Common Data Environment (CDE), aligned with ISO 19650, and connected to the systems used for design, construction, procurement, finance and operations. The objective is not to put every file in one application. It is to ensure that project teams and owners make decisions from current, approved and traceable information.

What How To Build A Single Source Of Truth For Construction Data Means in Practice

The formal reference point is ISO 19650. It defines a CDE as an “agreed source of information for any given project or asset” used to collect, manage and disseminate information containers through a managed process. UK BIM Framework Guidance Part 2, version 4, published in 2021, explains how those processes support project delivery.

That definition is more demanding than a shared drive or a folder labelled “final”. A functioning CDE controls information states, permissions, revisions, approvals, metadata and the route by which information becomes available to others. It also makes accountability visible: someone owns the data, someone checks it and someone approves its use.

In practice, construction organisations usually have several authoritative systems. The ERP may be authoritative for accounting transactions; a procurement platform for vendor and tender records; a CDE for drawings, models and project correspondence; and an asset system for operational records. The SSOT is the governed architecture connecting those domains, not necessarily one monolithic tool.

A useful way to define the domains is:

• Design and model truth: drawings, models, specifications and revisions.
• Commercial truth: contracts, commitments, budgets, variations and payment status.
• Site truth: daily reports, inspections, quality observations, safety events and installed quantities.
• Asset truth: as-builts, equipment records, operation and maintenance information and handover data.

Common project IDs, asset IDs, location breakdown structures and cost codes link those domains. Without shared keys, a snag cannot reliably connect to a room, a model element, a cost item or an asset register entry.

A CDE is therefore related to, but not identical to, a “single pane of glass”. The CDE governs the information and its lifecycle. A dashboard may present selected information from several systems to an executive. The dashboard is a view; the governed data architecture is the source.

Why This Matters for Digital Transformation Leaders & Innovation Directors

Digital transformation programmes in construction often begin with a specific use case: BIM, automated reporting, predictive risk, field mobility or a digital twin. Each depends on information that is structured, current and connected. If the underlying records remain fragmented, the programme creates another dashboard or pilot without creating a dependable decision layer.

The productivity case is material. McKinsey Global Institute estimated in February 2017 that global construction labour productivity grew by approximately 1% per year over the previous 20 years, compared with 2.8% for the total world economy and 3.6% for manufacturing. Better information management is not a complete answer to that gap, but it addresses one recurring source of avoidable work.

FMI and PlanGrid reported in Construction Disconnected (2018) that 48% of rework in US construction was attributable to poor data and miscommunication, with an estimated annual cost of $31.3 billion. The same research found that construction professionals spent 35% of their time—more than 14 hours each week—on non-productive activities such as searching for information, resolving conflicts and dealing with rework. Searching for project data alone accounted for 13% of working hours.

Owners see the consequence at portfolio level. KPMG’s Global Construction Survey 2023 found that 69% of owners said their organisations lacked integrated systems for project and portfolio management, while 61% said they did not have a single integrated view of project performance in real time. A transformation leader cannot govern a portfolio effectively if every project team defines progress, exposure and forecast differently.

AI introduces another dependency. Deloitte’s 2023 Engineering and Construction Industry Outlook described growing investment in AI and machine learning for project controls, risk analytics and safety monitoring, while warning that data silos and inconsistent structures limit the value AI can deliver. The question is not only whether an organisation has an AI tool. It is whether the tool can access traceable records with consistent dates, roles, locations, classifications and relationships.

For an owner or developer, the practical test is decision latency. How long does it take to answer: which projects have unresolved design exposure, what is the current commitment against budget, which variations are awaiting approval, or which asset information is missing before handover? An SSOT reduces the work required to establish the facts before a decision is made.

The Traditional/Manual Approach — and Where It Breaks Down

The traditional arrangement is usually an accumulation of reasonable local choices. Designers work in authoring and document tools. Contractors maintain spreadsheets, PDFs and field applications. Subcontractors send updates by email or messaging services. Procurement and finance operate in ERP or accounting systems. The owner’s team consolidates progress into monthly reports, often by requesting extracts from each party.

That arrangement breaks at the handoffs. A drawing is downloaded, renamed and circulated. An RFI response sits in an inbox but not against the relevant drawing revision. A variation is recorded in a commercial spreadsheet without a linked site instruction. A daily report contains a location description that does not match the cost plan or asset register. By the time the information reaches a board pack, the source, date and approval status may be unclear.

The result is duplication rather than control. Teams spend time checking which version is current, reconciling different identifiers and re-entering the same facts. The FMI/PlanGrid finding that 13% of working hours were spent looking for project data gives a measurable baseline for this problem.

It also affects claims and governance. If notices, instructions, approvals and evidence are spread across email, shared folders and disconnected registers, establishing the authoritative record becomes a manual investigation. The issue is not simply storage. It is the absence of a managed relationship between the record, its context and the decision it supports.

Manual reporting creates a similar failure. Project managers may maintain their own definitions of committed cost, forecast cost, progress and risk. Portfolio teams then reconcile those definitions rather than analysing exposure. KPMG’s 2023 finding that 61% of owners lacked a real-time integrated view reflects this executive visibility gap.

AI projects stall for the same reason. An algorithm cannot reliably link a document to a package, location, vendor or cost code when those relationships are absent or inconsistent. The organisation may have a large volume of data, but volume is not the same as usable information.

Step-by-Step Framework

Step 1 — Assess current state

Start with an inventory, not a software shortlist. Map the systems used across design, construction, procurement, contracts, finance, quality, safety, risk and operations. Record where each data object is created, copied, approved, changed and consumed.

For each domain, identify the current owner and the current authoritative source. Include project IDs, asset IDs, location codes, WBS and cost codes, vendor records, drawings, RFIs, submittals, inspections, variations, invoices and handover information. Then document where people re-enter data or export it into spreadsheets.

Three deliverables make the assessment actionable:

• System landscape map: the tools, owners and interfaces in use.
• Data-flow diagrams: the movement of information between roles and systems.
• Pain-point matrix: each issue ranked by frequency, decision impact and root cause.

Interview the people who produce and use the information: project directors, commercial managers, planners, document controllers, site managers, consultants, procurement teams, finance and asset operators. Ask where the latest approved record is found, how long a monthly report takes to compile and which fields are routinely missing.

Choose one or two high-value opportunities for the first release. For example, connect RFIs to drawings and approvals, or standardise site reporting and risk escalation. A bounded starting point produces a baseline and exposes governance issues before the programme expands.

Step 2 — Define standards, templates & governance

Define the information rules before configuring workflows. ISO 19650-1:2018 and ISO 19650-2:2018 place information requirements, roles, processes and CDE use at the centre of information management. The UK BIM Framework provides practical guidance on managed information states, including work in progress, shared, published and archived information.

Set the authority for each domain in a data ownership register. A simple version should state the data object, authoritative system, accountable role, required fields, approval route, update frequency and downstream users. For example, the commercial manager may own contract and variation status, while the information manager governs document metadata and revision status.

Create a master data dictionary covering project naming, locations, systems, components, vendors, cost codes, WBS and asset types. Use classifications such as Uniclass, OmniClass, Uniformat or IFC property sets where they fit the organisation’s delivery requirements. The choice matters less than consistent application across forms, templates and integrations.

Write the Information Management Plan and align it with appointments and contracts. Exchange Information Requirements, delivery milestones, naming conventions, approvals, security and handover expectations should not be optional instructions issued after mobilisation. If the CDE is not specified in consultant and contractor appointments, external adoption can remain partial.

Define the minimum viable record for each workflow. An RFI might require project ID, package, location, drawing or specification reference, responsible role, due date, response, approval status and revision. A site inspection may require location, category, responsible party, evidence, status and closure date. Required fields should support a decision, not create administrative volume without purpose.

Step 3 — Select & implement supporting technology

Technology should implement the operating model rather than substitute for it. A supporting platform needs permission-controlled information, revision history, workflow automation, audit trails, integrations and usable exports. It should support the organisation’s information standards and, where relevant, ISO 19650 and openBIM approaches.

Design for an ecosystem. BuildingSMART’s openBIM resources emphasise interoperable data models, while ISO 19650 recognises that a CDE can involve a combination of technical solutions when the managed processes are clear. The aim is to establish a reliable spine across systems, not to force every use case into one application.

Prioritise the objects that drive decisions: project and asset IDs, locations, cost codes, vendors, documents, RFIs, submittals, changes, risks, inspections and payments. Define whether each integration is real time or scheduled, which system is authoritative and what happens when records conflict.

Test the design with real records rather than demonstrations. Take a drawing revision, an RFI, a site observation, a variation and an invoice through the proposed model. Confirm that a user can find the current record, understand its status, trace its history and see the related commercial or operational context.

For owners, the technology selection should also address lifecycle continuity. ISO 19650-3 extends information management into the operational phase. Define the Asset Information Requirements at the start and specify the format, identifiers and acceptance criteria for machine-readable handover data, including any required COBie, IFC or asset-register schemas.

Step 4 — Roll out, train and monitor adoption

Roll out by workflow and audience, not by feature catalogue. A pilot might cover one region, business unit or project and focus on RFIs, site diaries or change control. Set a mobilisation date, nominate process owners and publish the minimum required behaviours.

Training should use the roles and records people handle every day. Show a document controller how to manage revisions, a site manager how to submit an inspection, a commercial manager how to link a change to evidence and an executive how to verify the source behind a dashboard.

Track adoption from the first week. Useful measures include the percentage of subcontractors onboarded before site mobilisation, the percentage of RFIs and change orders initiated through the platform, the percentage of inspections logged within 24 hours and the number of off-system documents found during audits.

Contract terms and management routines reinforce the process. Define which communications, notices, approvals and records must be in the CDE. Run weekly feedback sessions during the early rollout, remove unnecessary fields and publish changes to templates. The objective is a workflow people can complete correctly under site conditions, not a theoretically complete data model that drives shadow systems.

Step 5 — Measure impact against baseline KPIs

Measure before implementation, during adoption and after the workflow stabilises. Operational KPIs should include RFI turnaround time and the percentage answered within SLA, change-order frequency and value as a percentage of contract value, rework cost as a percentage of project cost, incident closure time and hours spent compiling reports.

FMI/PlanGrid reported that rework can represent 5–10% of project costs on typical projects, while its 2018 research attributed 48% of US construction rework to poor data and miscommunication. Treat those figures as research context, not a universal benchmark for every project.

For information quality, measure completeness, consistency and timeliness. Examples include the percentage of required fields populated, the percentage of incidents logged within 24 hours, the proportion of records with valid project and location IDs, and the percentage of published information using the required revision and naming conventions.

For executive value, measure the time to produce a portfolio dashboard and the time to answer a defined question, such as current variation exposure by project or missing asset information at handover. Track the percentage of projects meeting approved time and budget targets, but retain the definitions and source records behind those measures.

There is no reliable industry-wide ROI percentage for SSOT or CDE initiatives in the research available. Build the business case from your baseline: hours removed from manual reporting, faster RFI decisions, fewer duplicate records, more complete handover information and better traceability for commercial decisions.

Common Mistakes to Avoid

Buying a tool and assuming the SSOT exists. A platform without data ownership, shared IDs, workflows and adoption rules creates another repository. Confirm the operating model before configuration.

Ignoring contracts and external stakeholders. Consultants, contractors, vendors and operators need clear obligations for information delivery, metadata, approvals and handover. Internal guidance cannot compensate for an appointment that makes the process optional.

Over-engineering the first release. Complex forms and taxonomies that site teams cannot maintain encourage email, spreadsheets and informal messaging. Start with the records needed for the priority decisions, then extend the model.

Leaving ownership ambiguous. If no role is accountable for vendor data, cost codes, document revisions or asset records, quality issues persist across every integration.

Stopping at practical completion. A project CDE that does not deliver structured asset information leaves the owner to rebuild the asset record for operations. Define the information required beyond the project at the beginning.

Measuring logins instead of outcomes. A user can log in without submitting the required record or using the approved workflow. Pair adoption measures with RFI SLA performance, data completeness, reporting time and off-system audit findings.

Trying to do everything at once. Prioritise a small number of workflows, establish evidence of improvement and use the results to secure the next stage of sponsorship. A transformation programme needs a sequence, not an unlimited feature list.

How AI-Native Platforms Like Zepth Change This Workflow

Once the information environment is governed, AI can help maintain and use it. The distinction matters: AI does not replace information requirements, ownership or approval. It reduces the manual effort involved in structuring records and helps teams find relationships across them. Consequential actions still require human review and sign-off.

Zepth is an example of a platform approach organised around a common data environment rather than a collection of isolated point workflows. Zepth Core provides the unified project record across documents, quality and safety, site operations, project controls and risk management. Zepth Vector connects procurement and commercial workflows, including tendering, contracts, vendors and three-way invoice matching. Zepth Edge links asset and financial management across CapEx, budgets and management reporting.

Zepth AI is the intelligence layer across those domains. It reviews submittals and RFIs against drawings and specifications, provides a confidence score, drafts RFI responses with cited references, compares tender bids line by line, three-way-matches invoices before payment and flags risk early. A human remains responsible for sign-off on consequential decisions.

That architecture addresses two separate requirements. First, project and asset records need shared context: the document, package, location, responsible role, commercial impact and approval state should be connected. Second, teams need a practical way to use that context. AI can support entity linking, document classification, summaries, queries and risk signals without asking every user to build a report or manually cross-reference multiple registers.

The owner-side test remains operational. Can a programme director see the evidence behind a risk? Can a commercial manager trace a payment to the contract, invoice and receipt? Can an information manager identify missing metadata before handover? Can a project team review an RFI against the relevant drawing and specification rather than search separate folders? Those are the decisions an AI-native CDE should help the team work through.

The wider principle is supported by the research. Deloitte’s 2023 outlook warns that inconsistent structures limit AI value, while the Centre for Digital Built Britain’s 2018 Gemini Principles connect digital-twin ambitions with consistent, high-quality, shared data models. AI is therefore most useful when it is grounded in governed project information, transparent references and human accountability.

To put the framework into operation, use a checklist that records each domain, owner, identifier, workflow, integration, adoption measure and KPI baseline. Review it at every stage gate and at handover, rather than treating the SSOT as a one-time technology implementation. To discuss how this could apply to an owner or PMC portfolio, schedule a walkthrough.

FAQ