When Buildings Become Databases: Construction Data Knows What It Describes. It Rarely Knows Where It Belongs.

By MARET THATCHER

For the past 40 years, construction has invested billions – trillions? – of dollars in digitization.

We have Building Information Models describing every hangar, conduit and threaded anchor bolt before they are installed. We capture laser scans with millimeter precision, fly drones daily, stream live video from jobsites, attach sensors to equipment and record every inspection, checklist, RFI, markup and schedule update. By almost any measure, construction has become an extraordinarily data-rich industry.

Yet anyone who has spent time on a jobsite knows that information still feels surprisingly difficult to use when you’re in the field.

This isn’t because we lack software. It’s because we’ve digitized almost everything except the one thing all of that information depends upon: place.

Construction data knows what it describes. It rarely knows where it belongs.

That distinction sounds subtle, but it explains an enormous amount about how projects are managed today.

Consider a routine quality inspection. A coordinator begins with the BIM and produces a drawing with dimensions and annotations. The field team carries that sheet into the building and, tape measure in hand, mentally reconstructs a three-dimensional design from a two-dimensional document. Success depends less on the information itself than on the experience of the person interpreting it. Once the inspection is complete, the notes return to the office, are entered into another system and the photos are uploaded somewhere else.

Weeks later, if a discrepancy is discovered, the investigation begins. Teams sift through drawings, photographs, checklists and inspection reports attempting to reconstruct what happened in one specific corner of a building on one specific day. Fancy teams are doing this a little bit faster with scans processed at some point and BIM overlays analyzed back in the office.

The information exists. It simply has no common spatial language. The difference? Days of delay. Weeks of construction before a fix. We need something real-time that works in the flow of construction, not against it.

That observation became the foundation of Argyle.

We set out to solve what I believe is the missing layer of construction software: a persistent spatial relationship between digital information and the physical world. AR just happens to be a great interface for space.

Once data knows where it belongs, something interesting happens.

A checklist is no longer just a checklist. It becomes attached to the valve, duct or anchor it documents. A photograph becomes more than an image; it becomes evidence tied to an exact location, a specific building element, the worker performing the task and the point in time when it was captured. BIM stops being something we see on screen or imagine from paper and instead becomes part of the environment itself.

The implications extend well beyond visualization.

When every transaction, document, image and sensor reading shares the same spatial reference, the building itself becomes the organizing structure for project information. You stop searching for folders and begin querying the physical asset.

“Show me every inspection performed on this wall. Every photograph of this embed before concrete pour. Every issue associated with this section of mechanical work.”

The building becomes the database.

The next generation of construction software will not ask workers to translate information into the field. It will understand where the work is happening and deliver information in its proper context. Eventually, the distinction between “the project” and “the software” begins to disappear because the software understands the project spatially.

That’s the future we’re building at Argyle.

Construction happens in the real world. It’s time our data did, too.

Maret Thatcher is CEO at Argyle USA.