Data-Rich, Context-Poor: The Interface Problem in Construction

A project manager described his job during our interview in a single line: “A lot of what we’re doing is ‘firefighting’, and ‘putting out fires’ after they happen.” His quote perfectly captures the reactive nature of construction planning—responding to issues as they happen throughout the construction process.

Earlier this year, the Intelligent Construction (INTC) research team ran a field study with 16 construction professionals across seven general contractor (GC) firms, combining interviews with walkthroughs of active sites. The central finding is that construction planning stays reactive despite heavy upfront  effort.

While construction sites are full of data that are continuously evolving—scans, models, photos, logs, and schedules—there remains a disconnect between raw, multi-modal data and the specific information it provides to enable appropriate actions. GCs are short of ways to access the appropriate data when an issue arises, record the resolution, and update the project record without it becoming another project in itself. This is an interface problem as much as an intelligence problem.

Context

The wider construction technology market has converged on five capabilities: capturing site reality, measuring progress, retrieving project knowledge, operating digital twins, and predicting outcomes. These are well-served, mature market sectors; however, no single one player connects observed site reality → explanation → schedule consequence → action taken and proper documentation.

What we found

Interpretation runs on tacit experience. As one superintendent put it: “You’ll see thousands of [pieces of] information, right? But what do you do with it? How do you interpret the information? That’s the critical part, and only the experience will help.” The scarce resource is not the record. It is the person who knows which part of it matters.

Friction decides what gets recorded. Teams described opening three platforms to handle one problem, then setting aside time to reconcile them. Logging an observation properly is slow enough that people skip it: “I usually take a picture of this, I mark it up with a question mark, and then I take it back and I look at it later. Sometimes I forget.” Capture walks are among the first things dropped when a site gets busy, so many observations get lost before it is resolved.

Conflicting versions induce error. On one project, a structural element was fabricated from a superseded drawing, arrived oversized, and was installed before anyone caught it: “They followed the previous drawing, which is not the updated one.” The resulting non-conformance stayed open for two years. Comparing two revisions of the same drawing was described as taking an unreasonable number of steps. The correct version existed; nothing connected it to the person cutting the piece.

What it meant for us

How to interpret data is the problem. Sites already produce more data than anyone reads. The open question is what can be reasoned from what has already been captured, rather than what else to capture.

Records that already exist are the better starting point. Teams are legally obligated to produce daily logs and progress records and produce them regardless of how useful they are. Working with an obligatory record carries a lower adoption cost than working with something that asks for more records.

Uneven data maturity is a premise. Registered scans, aligned models, and clean schedule data describe a tier most of the sites we visited do not occupy. Any direction that quietly assumes them is assuming its way past the field.

Why it matters

Construction is unforgiving of error. A drawing read wrong becomes a component fabricated wrong, installed, and disputed for years. Schedules carry legal weight; deviations carry cost, and at the extreme, risk to the people on site. Anything introduced into that environment inherits those stakes. Practitioners told us they already use AI to check work rather than to do it. Trust here is earned slowly and spent in a single wrong answer at the wrong moment.

Research is a critical step to de-risking before productization. Understanding how sites actually operate, including where the data is thin, and where the incentives work against recording it, grounds our work in observed realities rather than assumptions.

Every practitioner we spoke with holds hard-won knowledge about why things went wrong, and what we do is to uncover these valuable insights to enrich our research efforts, dedicated to the exact people we speak with.

With thanks to the 16 construction professionals who gave us their time, their sites, and their candor.

Lala Leung is an intern at Autodesk Research pursuing a Master of Information with a concentration in User Experience Design at the University of Toronto