By

Andy Rampton

Last Updated Oct 12, 2026

By

Andy Rampton

This is the first of two articles. This part sets out the considerations: what clean and trusted data actually means, how to measure it, how the two systems most businesses already run fit together and how to work out where your business stands today. Part two will cover the practical steps: the detailed readiness programme, the structuring of your data and the architecture patterns that follow from it.

Across property and construction, Artificial Intelligence is one of the fastest technology adoptions ever. Multiple owners, developers and builders are sensing an era of unprecedented speed and accuracy in their decision-making, but are they ready for it?

AI does not create insight from chaos. It amplifies whatever it is fed and what most of our industry feeds it is a decade of inconsistent cost codes, duplicated documents and project records that were only ever kept for legal compliance. We’ve learnt from what the humans remembered, not what the data told us.

Today, using construction data is not an interesting innovation, it’s a matter of survival. Clean and organised data is what lets a Superintendent understand the reality of project performance, a CFO trust a forecast and a Board make a capital allocation on evidence rather than instinct. It is also the precursor to any credible use of AI.

It seems that we are all ready to embrace AI, but our data is not. The good news is that readiness is not a gate you have to pass before AI is allowed in. It is a sequence, and the first steps on it can start this month.

Why cleanliness is paramount

We all thumb our noses at clichés, yet they exist for a reason. The woes of traditional construction reporting are a case in point. We all know the scenario: we spend a week rekeying data from system to template, we pre-issue the report, then two weeks after we started preparing we end up in a room arguing if the data is correct or up-to-date. Given the same scenario, AI won’t fare much better; it will just speed up the publication of an incorrect report.

Clean data for AI purposes means we have to point our workflows and agents at the right data at the right time. And that data has to be in a format that can be recognised. Duplicates need to be removed, old versions marked as superseded, unique codes used to identify what really matters and numbers that are formatted and not free text. We also need data owners, because data quality without a named owner decays very quickly.

Making “clean and trusted” measurable

“Clean” is a weak target because nobody can say when it has been reached. Data quality must have well-established dimensions.  These four cover most of what matters for AI in construction.

Each dimension can be expressed as a percentage for a given data set, and that percentage can be tracked over time and compared across projects. A business that knows its RFI data is 94 percent complete but only 60 percent timely knows exactly which problem to fix first and which AI use cases that data can support today. Part two will set out a practical scoring method; the point for now is that trust in data should be a number, not a feeling.

Structure decides what the AI reads from

Cleanliness is about the quality of individual records. Structure is about which records the AI has access to.

Generally, every AI tool works the same way: it searches a body of content, selects what looks relevant and reasons over that selection. If the body of content contains work-in-progress drawings alongside issued-for-construction drawings with nothing to distinguish them, the tool has no basis for choosing correctly. Things like status, revision, discipline and location are not bureaucratic metadata, they are the essential filters that keep an AI focussed on the right answer.

Insist on traceability

A poorly designed AI tool will give you a very good, yet incorrect, answer and give no clue that it has done so. A well-designed one shows its working: which document it read, which revision, what status that document held and when it was last changed. Citations and provenance are not a nice-to-have. They are the mechanism by which a Superintendent or a Commercial Manager can check an answer in seconds rather than take it on faith.

When evaluating products, ask to see the citation behaviour on your own documents, including a deliberately superseded one. A tool that cannot tell you which version it relied on is a tool that will eventually be trusted with something it should not have been.

Two data systems, two jobs, two kinds of AI input

Most businesses already run the two systems that matter for AI readiness. They are often confused with each other and the confusion can be expensive.

Common Data Environment (CDE)

The single shared workspace for working project information, from design through to handover. It holds the live working artefacts, including: models, drawings, specifications, RFIs, submittals, change orders, schedules, cost plans, inspections and site diaries. Its job is to control the built form: to define what gets built and how that is done. For the purposes of AI, the CDE is where asset intelligence lives and allows the supply chain to clarify the design, respond to a RFI, check a submittal against the contract.

Data Warehouse (DW)

An analytical store. It pulls structured data out of the CDE, and everything else the business runs (ERP, payroll, estimating, procurement, safety, CRM), and reshapes it so questions can be asked across projects and across time. It doesn’t hold the drawings; it holds the fact that the drawing was revised four times and issued eleven days late, alongside the cost estimate those changes impacted and the subcontractor involved. For AI, the DW is where forecasting, risk analysis and pattern detection live.

Does every business need both?

Every business in construction needs a CDE, or at least needs to be connected to someone else’s. A warehouse is a different matter. It earns its keep only when there is something to compare, and three conditions decide whether that is true.

• Portfolio scale.

  A warehouse finds patterns across projects. A business running two or three projects at a time has too few data points for most of the questions a warehouse is built to answer, and project-level reporting from the CDE will serve it better for now.

• Repeatable project types.

   Pattern detection needs patterns. A builder delivering the same product on the same contract form, year after year, will learn far more from a warehouse than a business whose every project is a one-off.

• Ownership of data capture.

  A warehouse is only as good as the systems feeding it. A contractor working inside a client-mandated CDE, or a developer relying on each contractor’s own systems, does not control how data is captured and will find the warehouse reflects that. Where capture is owned, a warehouse multiplies its value. Where it is not, fixing capture comes first.

A business that meets all three conditions should treat the warehouse as core infrastructure. A business that meets one or none should put its effort into the CDE and revisit the question as the portfolio grows.

Using a CDE and a data warehouse together

Where both systems are justified, the way they are joined matters more than the function of either. Whilst the architecture will differ from business to business, the considerations below hold regardless:

• The CDE remains the system of record. The warehouse never overwrites the system of record. Data flows from CDE to warehouse through APIs or integrations, is reshaped for analysis and stays there. If an analytical finding needs to change a project record, a person changes it in the CDE, with the audit trail that implies.
• Common keys are the joining layer. Project, WBS, cost code, trade partner, location and date are what allow a fact in the warehouse to be traced back to a document in the CDE and joined to a line in the ERP. Agreeing those keys and owning them as master data is the single highest-value piece of structuring work a business can do.
• Each kind of AI reads from the right place. Asset intelligence (clarifying the design, drafting an RFI response, checking a submittal) reads from the CDE and inherits its version and status controls. Analytical intelligence (forecasting, risk, rework patterns) reads from the warehouse and inherits its keys. Pointing an analytical tool at raw CDE exports, or a document tool at the warehouse, produces plausible answers with no provenance.
• Access rules travel with the data. A permission model that works in the CDE must be carried into the warehouse, not rebuilt from memory. Commercial correspondence that a site engineer cannot open in the CDE should not become visible through a dashboard or an AI assistant that reads the warehouse.
• The business should own the analytical layer. Vendor intelligence layers work well on that vendor’s data and poorly on anyone else’s. A business running several systems needs a store it controls, or its analytics will be shaped by whichever vendor holds the most data.
• Owners and developers carry an extra boundary. The handover from project CDE to the systems that operate the asset is where most portfolio value is either captured or lost. Deciding who owns asset information after practical completion is an architecture decision, not a close-out task.
• Latency should match the decision. A nightly feed is fine for a monthly cost review. It may not be fine for a safety dashboard relating to a high risk activity. Decide what each consumer of the warehouse needs before deciding how often it is refreshed.

What goes wrong when we prioritise AI over data-readiness

Over many years we’ve observed the disinclination of humans to persevere with construction technologies if they don’t work perfectly the first time. To avoid this with AI, we need to be aware of the possible pitfalls:

• Confident answers from superseded documents: eg a QA checklist prepared from an outdated specification allows a defect to go unnoticed. Traceability is the defence: a tool that cites its source lets the error be caught before the work is installed.
• Patterns that do not exist: eg cost data coded inconsistently across projects produces correlations that are artefacts of the coding, not of the money being spent. The forecast looks rigorous but is wrong in a way no-one can trace.
• Permission leakage: eg a junior project manager releases commercial correspondence to people who should never have seen it. The AI did not break confidentiality, it just exposed that it hadn’t been put in place.
• Bad process at machine speed: eg automating a variation claim workflow that draws from the wrong contract version produces wrong claims faster and generates unnecessary management effort.
• Trust burnt on the first contact: eg a project senior who catches one wrong answer stops using the tool and tells the project team. Adoption takes years to recover. Over time, this could be the most expensive failure.
• Retrofit cost: eg cleaning data after AI has been deployed against it means re-validating every output the AI has already produced. Cleaning it first means only doing the work once.

None of these is an argument for waiting. Each is an argument for matching the use case to the data that exists today, which is what the sequenced approach below is for.

How far to go: the case for and against heavy data structuring

Every business that takes data-readiness seriously reaches the same question: do we adopt a formal information management standard, such as ISO 19650, with its naming conventions, status codes, container structures and defined roles? Or, do we standardise the handful of fields that matter to us and let the AI do the rest?

The right answer depends on the company and the way it works, but there are a few things worth considering:

The variables that tend to decide whether or not to pursue heavy data structuring include portfolio size, project complexity, client requirements, workforce maturity and which AI use cases the business actually intends to pursue first. A tier-one contractor delivering government infrastructure faces a different calculation from a residential builder running twenty houses a year. Both can be data- and AI-ready but they will not get there by the same route.

What comes next

None of this is glamorous and none of it will appear in a tech demonstration that promises the dream of process efficiency and decision accuracy. However, getting your data to be AI-ready is one of the most important aspects of your AI journey today. The businesses that get AI right will not be the ones that bought it first. They will be the ones that got ready while they were using it, one use case at a time.

Part Two will turn these considerations into a programme: how to assign and support data owners, how to score the four quality dimensions and set targets, how to make the structuring decision for your business, how to carry permissions through to AI tools, and the architecture patterns that follow once a warehouse is justified.

Written by

Andy Rampton

Field COO (International) | Procore

11 articles

As the APAC Industry Transformation Lead for Procore, Andy Rampton utilises his 30+ years' global experience in engineering, construction and property development to influence industry change and help create a pathway towards the long-awaited digital transformation of construction. Having sat in the industry and experienced the evolution of technology as a user, procurer and strategist, Andy saw first-hand the challenges that companies have in defining and sustaining meaningful technology- and data-enabled change in the face of overwhelming technology choices. He joined Procore with the intent to both promote the benefits of technology and data and also to improve the relationship between tech provider and customer such that the transition to the future of construction becomes a lot easier to navigate.

View profile