The Future of Infrastructure Records: Preserving What We Build

We’re seeing enormous investment in fiber, data centers, and digital infrastructure. But as the physical infrastructure around us becomes more sophisticated, an important question is emerging:

Are our infrastructure records keeping pace with what we're building?

We spoke with Vanessa Wells VP of Engineering, OSP veteran of 28 years, and author of Copper & Glass to explore what happens when the digital record of our infrastructure falls behind the physical reality.

From institutional knowledge to reality capture and digital twins, the conversation points toward a larger challenge for the industry: How do we preserve what we've learned while we're building what comes next?

Are our infrastructure records keeping pace with what we're building?

Not consistently.

We have better tools than we've ever had for collecting information about physical infrastructure. Reality capture, GIS, LiDAR, photogrammetry, and increasingly sophisticated network-management systems give us the ability to create extraordinarily detailed records of the environment we're building in.

That is a tremendous improvement over reconstructing field conditions from a handful of photographs, measurements, and notes.

But having the technology to capture good information and maintaining good information throughout the life of an asset are two different problems.

We tend to treat documentation as something that comes out of a construction project rather than as part of the infrastructure we're building. A network gets fielded, designed, permitted, and constructed, and then at some point somebody has to reconcile what was designed with what was actually built and get that information into the system of record.

That's where information starts leaking out of the process.

The physical network and the digital representation of that network should really be treated as two assets being built simultaneously.

Better field capture gives us an increasingly accurate starting point, but that digital asset also needs pathways, ownership, and maintenance just as much as the physical one does.

More importantly, the information can't just arrive somewhere and stop. It has to continue moving through the life of the infrastructure.

Why is it still so difficult to know exactly what infrastructure exists, where it is, and who owns it?

Because we're not dealing with networks that appeared yesterday. We're dealing with layers of infrastructure built by different companies, at different times, under different standards, using different record systems.

Networks are acquired. Companies merge. Routes are rebuilt. Facilities are relocated. Emergency repairs happen. Contractors make field changes. Systems get migrated. Infrastructure gets abandoned without necessarily being removed.

A perfectly good record created twenty years ago may have survived three owners and four software platforms—or it may not have survived the first one. Eventually, infrastructure starts looking a little like archaeology.

You have records from different eras, built under different standards, sometimes contradicting one another, and you're trying to reconstruct what happened from the evidence that survived. Sometimes the best surviving evidence is a map. Sometimes it's what's physically in the ground. And sometimes it's Dave, who remembers what they did in 1998.

You can have a drawing that says one thing, a GIS record that says another, something different in the field, and Dave telling you what actually happened. And all four pieces of information may contain some truth. That's one reason the ability to go back to physical reality is so valuable.

Reality capture doesn't magically resolve decades of ownership history or institutional knowledge, but it can give us something enormously important: an observable record of what was actually there at a particular point in time. The stronger the connection between that field evidence and the GIS, engineering, and operational systems built on top of it, the less archaeology the next person has to do.

What does incomplete or inaccurate infrastructure data actually cost the industry?

Uncertainty has a price. If I can't trust the existing information, I have to buy certainty again. That might mean another field visit, another survey, additional locates, redesign, permit revisions, or additional engineering. During construction, it can become delays, change orders, and crews waiting while somebody figures out what they're actually looking at.

And sometimes the consequence is much larger: damaged infrastructure, an outage, or a safety event. The interesting thing about bad infrastructure data is that the cost rarely appears on a line item called “Bad Records.”

Instead, it spreads.

One missing or unreliable piece of information becomes another field visit. That delays engineering. Engineering can't finish the design. Permitting can't submit the package. Construction can't release something downstream. A relatively small information problem suddenly has an expensive entourage.

Those costs get distributed across engineering, permitting, construction, operations, and maintenance. This is where better field data has value far beyond the initial survey. If an engineer can revisit a detailed capture of the site instead of immediately sending someone back into the field, that information can potentially answer questions for design, permitting, construction, and eventually operations.

The value isn't simply that we collected more data. It's that the same reliable information can keep creating value downstream.

An organization can spend a tremendous amount of money compensating for poor information without ever identifying poor information as the underlying expense. Conversely, improving the quality and accessibility of information early in the process can prevent costs that otherwise wouldn't appear until much later.

How much infrastructure knowledge still lives with individual people rather than in reliable systems and records?

An uncomfortable amount.

There are things a map can tell you, and there are things somebody who has worked a network for twenty-five years knows.

A database might tell you where a route is supposed to be. A person might know why it takes that strange turn.

Maybe an easement couldn't be obtained there twenty years ago. Maybe a conduit everyone assumes is usable hasn't been passable in fifteen years. Maybe the drawing says one thing but everybody who has actually worked the facility knows something different.

That's institutional knowledge, and historically the industry has been surprisingly comfortable allowing enormous amounts of it to live inside individual people's heads. We design redundancy into telecommunications networks constantly.

Then we allow critical knowledge about those networks to have a single point of failure: a person.

Technology can help us tremendously here, but technology doesn't replace expertise. A detailed image, point cloud, model, or GIS layer can preserve things that previously might have disappeared. But someone still has to understand what they're looking at, recognize what matters, and know when the information doesn't make sense. The best information systems don't eliminate experienced people.

They make more of what those people know available to everyone else.

As experienced professionals leave the industry, what happens to that institutional knowledge?

A lot of it simply disappears. You can transfer files. You can migrate databases. You can't export thirty years of context from someone's brain on their last Friday afternoon.

And the loss isn't always obvious immediately. Six months later someone encounters something strange in the field and says, “Why did we do this?” The person who knew isn't there anymore.

That's why preserving institutional knowledge can't simply mean asking experienced people to document everything they know before retirement. That's an impossible assignment. We need systems that capture context as work happens: why a decision was made, what changed in the field, what assumption proved wrong, what was verified, and what wasn't.

Some of that can increasingly be captured visually and spatially rather than depending entirely on somebody writing it down. That's important. A rich field record can preserve context that nobody realized would matter five years later. But then that information needs somewhere useful to go.

Capturing knowledge without creating a path for that knowledge to move through the organization just gives us another repository nobody looks at. The goal isn't to document every thought someone has ever had. It's to stop throwing away the reasoning and evidence behind consequential infrastructure decisions.

What should we be doing differently today so the networks we're building don't become tomorrow's inaccurate or incomplete records?

I don't think the answer is simply collecting more data. We collect enormous amounts of data already.

The problem is building systems that keep useful information moving. Every stage of an infrastructure asset's life creates information about that asset. The question is whether that information reaches the people and systems that need it—or dies in an email, a closeout package, a contractor's files, or someone's head.

A healthy infrastructure information system should behave like a feedback loop.

The existing record informs field verification. Field verification—and increasingly detailed reality capture—provides the foundation for design. Design feeds permitting. What we learn during permitting needs to come back into design. Construction discovers things neither group knew. Those discoveries need to make their way into the as-built record and into operations.

Maintenance then creates new field truth, which should update the record that eventually becomes the starting point for the next project. So rather than thinking of this as: design → build → closeout

I'd think of it as:

existing record → field capture and verification → GIS and design → permitting → construction → as-built verification → operations → maintenance → updated record → field verification...

And there are smaller feedback loops throughout that larger cycle. Construction shouldn't have to wait until closeout to tell engineering that reality disagreed with the design. A permitting discovery shouldn't disappear into somebody's email. Maintenance shouldn't change the physical network without the information system eventually learning that the physical network changed.

And field data shouldn't have to be collected from scratch by every department that needs to understand the same location. That's where I think the combination of reality capture, GIS integration, and network design becomes particularly powerful.

When those things are treated as connected parts of the same information system rather than separate deliverables, information collected for one purpose can continue providing value throughout the asset's lifecycle.

But capture alone doesn't solve the problem. Neither does GIS. Neither does a beautiful digital model.

The record shouldn't be the end product of the process. It should be part of the process.

If we get that right, maybe the next generation of engineers won't have to spend quite so much time being archaeologists.

If the industry gets this right, what should infrastructure information look like 10 years from now?

I'd like the question “Where is the fiber?” to be considered an extremely primitive question ten years from now.

I want to know:

• What is there?

• Where is it?

• Who owns it?

• What does it connect to?

• What is around it?

• When was that information collected?

• How was it collected?

• When was it last verified?

• What has changed since then?

And one thing I think is especially important:

How confident are we that this information is correct?

We sometimes treat infrastructure records as binary. Either we have the record or we don't. But there's a tremendous difference between an asset documented through recent, high-quality field capture and a line digitized from a twenty-year-old drawing whose original source nobody can identify.

A useful infrastructure-information system should preserve that distinction. And it should be alive.

The goal shouldn't be to create a spectacularly accurate digital representation of the network on Tuesday and then watch the physical network slowly diverge from it for the next ten years. Reality capture can tell us what exists. GIS can organize and relate that spatial information. Modeling can help us understand it. Engineering can use it to design what comes next.

But the real power comes when information can move between those functions and then cycle back again as the physical environment changes. I don't think the goal should be pretending we're ever going to achieve a perfect digital representation of every physical asset. The goal should be creating records that are current, traceable, continually improving, and honest about their own level of certainty.

That's when digital twins and increasingly sophisticated infrastructure models become truly useful—not because the visualization is impressive, but because people can trust the information underneath it.

About Vanessa Wells

I've spent approximately 28 years in telecommunications, with much of my career centered around outside plant infrastructure and the systems and processes required to get networks from an idea to something that can actually be constructed.

My work has crossed engineering, permitting and right-of-way, construction coordination, project and contract management, vendor management, and infrastructure strategy. I've worked from both the owner and contractor sides of the industry, which has given me the opportunity to see how information changes—and sometimes gets lost—as a project moves between organizations and disciplines.

More recently, my work has shifted toward consulting and education, particularly around the dependencies that make infrastructure projects succeed or fail.

I'm also the co-author of Copper & Glass, which looks at telecommunications infrastructure through both its technical development and the people who built it, and I'm developing The Wells Method, an educational program focused on practical OSP knowledge, permitting, design, and project management.

A lot of what interests me now comes back to the same question we're discussing here: How do we preserve what this industry has learned while we're building what comes next?