Plan reality capture backward from operations

Most reality capture programs start with a tool: a drone, a 360-degree camera, a tripod scanner, a SLAM device, a robot, a point cloud or a BIM model.

Those tools can all create value. But if the program starts with technology instead of the operational problem, the owner can end up with impressive data that very few people use.

That is how point clouds end up on hard drives, project photos become impossible to find, expensive scans become design relics and turnover packages become data graveyards rather than working facility resources.

A better approach is to plan reality capture backward from operations.

Most reality capture programs start with a tool: a drone, a 360-degree camera, a tripod scanner, a SLAM device, a robot, a point cloud or a BIM model.

Those tools can all create value. But if the program starts with technology instead of the operational problem, the owner can end up with impressive data that very few people use.

That is how point clouds end up on hard drives, project photos become impossible to find, expensive scans become design relics and turnover packages become data graveyards rather than working facility resources.

A better approach is to plan reality capture backward from operations.

The business problem: technology-first capture creates unusable data

Reality capture is easy to start and hard to scale. 

A project team can capture thousands of photos. A VDC team can create a detailed scan. A drone provider can deliver maps and orthomosaics. A 360-degree camera can document rooms quickly. A LiDAR scanner can create accurate geometry. A SLAM scanner can cover large spaces at speed.

But capture alone does not create operational value. The value appears when the right person can find the right visual evidence at the right moment and use it to make a better decision.

That means the real questions are not only technical questions. They are business questions.

If a capture does not support a real decision, it may not be worth the effort. When these questions are skipped, the technology may work perfectly, and the program may still fail.

The point is to capture what will help people make better decisions later.

Different stakeholders see the same building differently

A superintendent, VDC manager, facility manager, commissioning agent, security director, electrical engineer, reliability leader and maintenance planner all see the same building through different responsibilities.

A drone map that is valuable to a project executive may not help a technician trying to find a valve behind a wall. A detailed point cloud may not help a maintenance planner if it is difficult to navigate or is not organized by floor, room, system, asset and date. A 360-degree photo is useful, but it becomes much more valuable when it is pinned to a floor plan, time-tamped, tied to an asset, related to documents and searchable later.

For a security team, the priority may be doors, cameras, access control, communication rooms, sight lines, risk zones and emergency response. For a maintenance team, the priority may be assets, access, isolation points, labels, flow direction, spare parts, clearances and work planning. For a commissioning team, the priority may be functional testing, design intent, installed conditions, live telemetry, virtual control tests and evidence that systems perform as expected.

One capture program can serve these groups, but only if the program is designed with their use cases in mind.

Use top-level ontology as the organizing lens

The ontology should remain simple enough for project teams to use but strong enough to prepare the data for operational systems, AI search and agentic workflows.

Before choosing the capture method, the owner should define what each milestone needs to support. The eight top-level ontology items provide a practical checklist; space, asset, system, party, service, intent, event, contract.

Build a searchable data fabric

A reality capture data fabric is an organized, time-based, phase-based evidence layer that can be searched, compared, measured, shared and connected to other operational systems.

Space and capture event date are the foundation, but operations teams also need system, asset, access, system relationship, party, service, contract and intent context. They also need to understand the decision the evidence is intended to support.

Without this structure, reality capture becomes a collection of files. With structure, it becomes an operational memory layer.

The change management requirement

A successful program is more than a capture initiative; it is also a change-management program. Owners, contractors, designers and operators need to agree on what will be captured, when it will be captured, how accurate it needs to be, where it will live, how it will be updated and who will use it after construction.

1. Define the business problems: repeated site visits, poor closeout data, future dig risk, difficult access, warranty claims, renovation uncertainty, commissioning gaps or safety concerns.
2. Map the stakeholders: construction, operations, maintenance, reliability, security, safety, IT, engineering, commissioning and leadership.
3. Prioritize the use cases: start with high-risk, high-cost, hard-to-access, high-criticality systems and spaces.
4. Set capture service and contract requirements: method, frequency, accuracy, visual resolution, metadata, naming, security, acceptance and turnover format.
5. Connect to operational systems: BIM, GIS, CMMS/EAM, asset registries, commissioning records, document repositories, work orders and digital twin platforms.
6. Measure adoption and value: track whether teams use the data to reduce site visits, improve planning, execute work safely, resolve issues faster or avoid rework.

What owners should write into requirements

If owners want reality capture to survive beyond construction, they need to define expectations before construction starts.

At minimum, owner requirements should address:

• Required capture milestones before concealment.
• Required systems and asset categories.
• Top-level ontology and required metadata.
• Naming conventions by building, floor, room, system and asset.
• Required geolocation, floor plan alignment or survey control.
• Required integration or link strategy to BIM, GIS, CMMS/EAM, commissioning systems, document repositories or asset registries.
• Required photo, 360-degree, scan, drone and extracted-data deliverables.
• Required turnover structure, access controls, long-term ownership, retention, refresh frequency and update requirements.
• The operational interface required for each use case and stakeholder.

What to do next

Create a one-page capture requirements table for your next project using the eight ontology items. For each milestone, define the space, asset, system, party, intent, service, event, contract and final consumption interface.

Take a deep dive into data center construction in our recent playbook: 

Key takeaways

• The best reality capture programs start with operational use cases rather than devices.
• A consulting-led approach helps identify stakeholders, business problems, critical systems, adoption barriers and measurable value.
• Space and event date are important, but operations teams also need system, asset, party, service, contract, intent and evidence context.
• A reality capture data fabric should connect visual evidence to the systems people already use, including BIM, GIS, CMMS/EAM, commissioning records and asset registries.
• The best capture strategy is the one people keep using after the project is finished.
• Owner requirements should be written before construction or scanning starts so the data survives handover.

Part of the five-part series Reality Capture as Operational Memory. Read the other articles:

• Don't let reality capture die at handover
• Capture it before it disappears (Coming soon) 
• From visual evidence to better work management (Coming soon) 
• From a reality capture data fabric to an operational digital twin (Coming soon) 

About the author

Kelly Watt is a digital transformation leader specializing in digital twin technology for aviation, data centers, smart cities, oil and gas and critical infrastructure.

Kelly is the Co-Founder of Digital Twin Consulting. The firm delivers strategic master planning and the proprietary DTAP assessment process to digital transformation projects worldwide.

A frequent collaborator with Georgia Institute of Technology, University of Texas at Dallas and Mohawk College, Kelly focuses on practical digital transformation: strategy before technology, value before complexity and adoption before dashboards.

‍