Insights / Running drone inspection as a system, not a skill
A skill held by one person is a single point of failure
The first wall an organisation hits after adopting drones for inspection is rarely the aircraft. It is that the operation has attached itself to one person. How the permissions were filed, how a go/no-go call gets made on site, which conditions are worth scrubbing for — all of it lives in one head. A transfer or a resignation stops the work.
Aviation answered this a long time ago with checklists and standard operating procedures. Move the judgement out of memory and into a document, so the output holds steady regardless of who is on duty. Nothing about that answer is specific to aircraft.
Three layers worth documenting
When you turn an operation into a system, the material sorts into three layers. Working from the front is the realistic order.
| Layer | What it covers | What happens if you skip it |
|---|---|---|
| Regulatory | Aircraft registration, flight permissions, airspace eligibility | You arrive on site and cannot legally fly. Exposure to enforcement |
| Procedural | Day-before prep, pre-departure checks, pre-flight confirmation, in-flight monitoring | Quality swings by operator. Incident lessons never stick |
| Automation | Route planning for autonomous flight, monitoring, intervention when something goes wrong | Nobody is ready to take control at the moment it is needed |
Rules differ by country — registration thresholds, permission categories and airspace classes are all national. The layers do not.
Checklists beat knowing
Pre-flight confirmation runs off a list, not off recall. This is the same reason a flight crew reads a checklist aloud before departure when they have flown the type for years: knowing something and having verified it today are different states, and only one of them is evidence.
Splitting items by when they happen — the day before, before leaving, before take-off, during flight — is what makes the list survive contact with a real schedule. A single long list gets skipped; four short ones get read.
Automation moves the work, it does not remove it
Once flights run on pre-planned routes, the human job shifts from flying to monitoring. The thing to design at that point is not the autonomous flight — it is who takes it back, and how, when something goes wrong. Redundancy is the relevant idea: no single component, and no single person, should be able to stop the operation.
This is the same principle that keeps a twin-engine aircraft flying on one engine. It is cheap to design in at the start and expensive to retrofit after the first incident.
What this is for
None of this is procedure for its own sake. The point is that an inspection programme should still run next quarter, with different people, at the same quality. That is the difference between a capability and a demonstration.
The operational tooling we build around this — inspection, fleet monitoring and rostering — is what Airffic World is for.