Drone Inspection Data: Fix the Flow Before BVLOS Multiplies Your Flights

---

Overview

01

What the CAA roadmap actually changes

In its Future of Flight BVLOS Roadmap, published as CAP3182, the UK Civil Aviation Authority sets out how it intends to enable routine beyond visual line of sight drone operations by 2027.

The roadmap splits that work into three pathways. Atypical Air Environments come first, then low-level urban operations, then fully integrated BVLOS.

An Atypical Air Environment is a volume of airspace the CAA accepts is very rarely, or never, used by other aviation traffic. In practice that means the air close to fixed infrastructure: railway corridors, power lines, wind farms, industrial sites. The CAA publishes separate distance thresholds for linear structures and for buildings, and those thresholds are what an operator works to.

For asset owners the point is simple. The kind of inspection flying that needed a spotter every few hundred metres is on a path to becoming ordinary work.

---

Economics

02

Cheaper surveys do not stay rare surveys

Every conversation about BVLOS starts with cost per flight. That is the wrong number to plan around.

When a survey stops needing a crew walking the line, the cost of one survey drops. What follows is predictable. Inspection intervals shorten. Areas that were surveyed once a year get surveyed quarterly. Assets that were never surveyed at all get added because the marginal cost is now small.

So the volume of footage, thermal frames and telemetry arriving at the office goes up, and it goes up faster than headcount.

A two-person team processing one flight a week by hand copes fine. Nobody notices the process, because the process is a person with a folder and a good memory. The same two people at ten flights a week are the bottleneck, and the flying savings are now being spent on overtime in the reporting queue.

---

Fixes

03

Four things to fix before the volume arrives

All four are cheap to do at one flight a week. All four are a migration project at ten.

1. Give every frame an asset identity. A frame that belongs to Tower 14, Blade B, at a known height and heading is a record. A frame that belongs to a folder named by site and date is a file. Retrofitting identity across two years of archived footage is the project nobody budgets for, and it is the one that blocks any later attempt at change detection between surveys.
2. Keep raw data apart from conclusions. The footage is evidence. The finding is a judgement made about that evidence by a person or a model. Stored in the same place, they drift into each other, and when a client challenges a finding there is no clean way to show what the inspector actually saw versus what was concluded from it.
3. Set a filter threshold, and write down what it discards. Most frames show nothing. Deciding automatically which frames a human never opens is what keeps review hours flat while flight hours climb. The threshold has to be recorded, because the first question after a missed defect is what the system chose not to show anybody.
4. Put a deadline on the human review step. An unreviewed finding is not a finding. If a detection can sit in a queue for three weeks, the flight got cheaper and the answer got slower, which is the opposite of the business case that paid for the drone.

---

Data model

04

What a survey record has to carry

Most inspection software was built around a person with a phone and a checklist. A drone survey produces types of data that model has no slot for.

Data type	Where it has to land	What breaks without a slot
High resolution stills and video	Against a specific asset and position	No comparison between this survey and the last one
Thermal frames	Same record, with the temperature scale kept	A hotspot cannot be re-read months later
Point cloud or 3D scan output	Linked to the asset, stored outside the report	Files sit on a shared drive and nobody opens them again
Flight log and telemetry	Attached to the survey, not the aircraft	No way to show where the aircraft was when a frame was taken
Model output and confidence	Beside the frame, marked as a suggestion	A machine guess reads like a human finding in the report

A record that carries all five is auditable a year later. One that carries photographs and a comment box is not, and the gap only shows up when somebody disputes a report.

This is the same problem we cover in modern inspection system architecture, arriving from a different direction. The aircraft is new. The data problem underneath is the one inspection teams already know.

---

Review

05

The step that decides whether any of it pays back

Automated detection changes where a person spends attention. It does not remove the person.

A model flags 240 candidate defects across a wind farm survey. Someone decides which of those become work orders, which get watched, and which were rust stains on a bolt head. That decision is the product. Everything before it is input.

So the review step needs three things that rarely get designed: a queue with an owner, a service level for how long a finding can wait, and a record of what the reviewer changed. The third one matters most. When a model suggested a crack and a human downgraded it, that edit is the audit trail, and it is what stands behind the certificate.

We argue the same case for AI visual inspection: the model earns its place when a person can explain and defend what it produced, not when it produces the most detections.

---

Build

06

Where off-the-shelf stops

Flight planning software is mature. Photogrammetry and thermal processing tools are mature. The layer that is usually missing sits between the processed output and the maintenance system that actually schedules work.

That layer is specific to how an operator runs: the asset hierarchy, the naming, the thresholds for what becomes a job, the approval chain, the format an auditor expects. It rarely matches what a generic platform offers, and it is where teams end up with a person re-keying findings into a CMMS by hand.

Dev Station builds that layer as custom digital inspection software when the off-the-shelf route runs out: integration into an existing ERP or CMMS, an asset model that matches the estate rather than a template from a vendor, and evidence handling built for the inspection record an auditor will ask for. If a drone programme is coming and the reporting side is still manual, send us your current reporting flow and we will tell you which parts survive a tenfold increase in surveys.

---

FAQ

07

Questions asset managers ask

Does any of this need BVLOS approval first? No. Asset identity, evidence separation, filter thresholds and review deadlines are software and process work. They are easier to do before the volume arrives, which is the argument for doing them now.

What if we outsource the flying to a survey contractor? Then the data handover format becomes the contract term that matters most. Ask what identity each frame carries when it reaches you, and whether the raw capture comes with it or stays with the contractor.

Where do most programmes stall? At the second site. The first pilot works because one engineer processes the data by hand each evening. There is no such person at site two, and nothing in the process was written down. That is a process failure, not a technology failure.

Do we need AI detection on day one? No. A filter that discards obviously empty frames is worth more early on than a detection model nobody has calibrated. Detection becomes useful once there is a review queue and a record structure for it to write into.