Percepto: Engineering Autonomous Inspection Drones for Multi-Regime Regulatory Reality
Percepto builds autonomous drone inspection systems for places where sending a person is expensive, slow, or dangerous: high-voltage transmission lines, oil and gas processing facilities, open-pit mining operations, solar farms measured in square kilometers. Their Sparrow drone launches from a weatherproof ground station, flies a pre-planned inspection route, collects video and sensor data, and returns — without a human pilot in any conventional sense. The operator monitors, not flies.
That description sounds straightforward. The systems engineering behind it is not.
Percepto operates commercial deployments across the United States, Europe, and Australia simultaneously. Each jurisdiction has a distinct regulatory authority — the FAA, EASA, and CASA respectively — and each has developed autonomous/BVLOS (beyond visual line of sight) frameworks on different timelines, with different approval mechanisms, and different documentation expectations. A product designed to work in all three must either architect for regulatory variation from the start or carry enormous compliance debt.
This is a profile of how Percepto approaches that problem, and what it reveals about the systems engineering challenge of building autonomous inspection products for regulated industries.
The Regulatory Geometry Problem
Most hardware products face a single primary regulatory regime with secondary import/export considerations. Percepto faces three primary regimes with genuine operational authority over how their system flies on any given day.
The FAA’s BVLOS framework has evolved through a waiver-and-exemption system that is being replaced by a more structured rulemaking process, but that transition is not complete. Deployments operating under existing waivers have specific operational conditions — altitude limits, airspace restrictions, weather minimums — that are customer-site-specific and FAA-approved individually. There is no single “FAA BVLOS approval” that Percepto holds; there are a portfolio of site-specific authorizations, each with its own conditions.
EASA’s approach under the U-Space framework is more structurally defined. The Specific category, governed by the SORA (Specific Operations Risk Assessment) methodology, creates a risk-scoring process that produces operational conditions from a defined framework rather than negotiated case-by-case. This is more predictable once understood but requires Percepto to map their system’s actual behavior against SORA’s risk model, which was not designed with dock-based autonomous systems as the primary use case.
CASA in Australia has moved relatively quickly on BVLOS approvals for industrial applications and has approved Percepto deployments at mining sites under its ReOC (Remotely Piloted Aircraft Operator’s Certificate) system, with site-specific BVLOS authorizations layered on top.
The geometry problem is this: Percepto cannot build three separate products. The hardware, the core autonomy stack, and the ground station architecture are shared. What varies is the operational envelope — altitude limits, airspace interaction, lost-link behavior, minimum weather conditions — and the documentation that proves the system operates within that envelope. Their requirements engineering challenge is to define a system architecture where operational parameters are configurable inputs, not fixed design choices, while the underlying safety properties hold regardless of which configuration is active.
That is not a software configuration problem. It is a requirements architecture problem.
Flight Safety Requirements: Where the Hard Work Lives
Autonomous BVLOS operations require a safety case. A safety case is not a compliance checklist — it is a structured argument that the system is acceptably safe to operate in a defined environment, supported by evidence. Building a safety case for a piloted aircraft is well-understood. Building one for an aircraft that must make real-time decisions autonomously, in industrial airspace, under variable conditions, is a substantially different exercise.
The core challenge is that piloted aircraft safety standards assume a human pilot as the final authority. The pilot’s judgment is a component of the safety system. When you remove the pilot, you must either replace that judgment with formal logic — encoded in software, with defined inputs and outputs — or you must constrain the operational envelope so tightly that the system never encounters conditions requiring the judgment you’ve removed.
Percepto’s approach, consistent with what is publicly known about their architecture, is a combination of both. Their autonomous mission planning system operates within a defined envelope where formal logic is sufficient. When conditions approach the boundary of that envelope — weather degrading, airspace changing, equipment anomalies — the system initiates a safe state rather than attempting to reason through novel conditions. Safe states include returning to the dock, holding position, or immediate controlled descent, depending on the anomaly type.
This design choice has a direct requirements implication: every boundary condition must be formally specified. What constitutes “weather degrading” must have a precise definition that a sensor can measure, not a qualitative description a pilot would interpret. Wind speed in knots at measured altitude, not “gusty.” Visibility in meters at the operational ceiling, not “poor conditions.” The process of translating qualitative safety concepts into measurable, automatable thresholds is where significant engineering effort concentrates, and it is work that does not end at initial certification. It requires ongoing review as operational data accumulates.
Autonomous Mission Planning: Encoding Judgment as Requirements
A human pilot planning an inspection flight over a transmission line segment makes dozens of real-time decisions: adjusting approach angle for sun angle and shadow, modifying altitude based on observed obstacle proximity, changing speed in response to turbulence. These decisions draw on training, experience, and contextual perception. They are rarely written down in any formal sense because the pilot is the system.
Autonomous mission planning must encode these decisions as formal logic before the mission begins. The inspection route is not just a set of waypoints — it is a specification of the behaviors the system will execute at each point, the conditions under which it will deviate from the planned route, and the priority ordering when multiple deviations are triggered simultaneously.
This is a requirements engineering exercise disguised as a software task. Getting the route planner to produce correct behavior requires knowing what “correct” means precisely enough to implement it. That precision is hard to achieve because the subject matter experts — experienced inspection pilots and industrial inspection personnel — often cannot articulate their decision-making at the level of specificity required. They know good inspection when they see it. They cannot always describe it in terms a system can execute.
Percepto’s operational context adds a layer: the system is not just flying an aircraft, it is performing an inspection. The flight path is defined by the inspection objective — capturing specific asset elements at specific angles, resolutions, and lighting conditions — not by aviation convenience. Mission planning must satisfy two constraint sets simultaneously: safe, regulation-compliant flight, and effective, data-quality-sufficient inspection. When these conflict, which constraint dominates? At what cost to the other?
These are design decisions that must be made explicitly and captured somewhere. They cannot remain implicit in a developer’s implementation choices. In an autonomous system deployed at scale across multiple industrial sites under multiple regulatory regimes, undocumented design decisions accumulate as technical debt with compliance implications.
Industrial Integration: The Other Regulatory Boundary
Percepto’s ground station infrastructure — the dock, the charging system, the data uplink — is installed at industrial facilities that operate under their own safety management systems. An oil and gas processing plant has a Process Safety Management (PSM) framework. A mining site has its own hazardous area classifications and operational procedures. A substation has utility-specific safety protocols.
The drone system must integrate with these frameworks. In practice, this means two things that create distinct requirements challenges.
First, the ground station and any network infrastructure must satisfy the industrial facility’s safety and security standards. This is not primarily an aviation problem — it is an industrial instrumentation and control system problem. The requirements that apply to a networked device installed in a hazardous industrial area come from standards like IEC 62443 for industrial cybersecurity and the facility’s own hazardous area classification requirements under standards like ATEX (for European sites) or NEC 500/505 (for US sites).
Second, the drone’s operational procedures must integrate with the facility’s permit-to-work systems and operational boundaries. A facility conducting a maintenance shutdown will have changed ground conditions, unusual equipment configurations, and altered airspace considerations. The drone system’s mission planning cannot operate in isolation from the facility’s operational state. Some integration with the facility’s safety management system — even if only a manual check-in process — is operationally necessary.
This creates a boundary between what Percepto owns and what the facility owns. That boundary must be explicitly specified: what information flows across it, in which direction, at what frequency, with what latency requirements. These are system-of-systems requirements, and they are harder to validate than single-system requirements because testing requires coordinating with the facility’s own processes.
Replacing Human Inspectors: The Liability Architecture Shift
Industrial inspection by human workers carries a well-understood risk allocation. The worker is exposed to hazard. Regulations, procedures, and training reduce that hazard. When something goes wrong, the liability is distributed across the employer, the procedure author, and potentially the individual.
Autonomous drone inspection shifts the exposure pattern. The human inspector is no longer at risk from the inspection task — but the drone is now operating unattended in an industrial environment. If the drone strikes a worker, or triggers a process upset by disturbing an area, or causes a fire from an electrical fault in the dock, the liability now traces back through the product to the manufacturer.
This shift matters for how the safety case must be structured. The argument changes from “the system protects the operator” to “the system does not create new hazards for third parties.” These are different arguments requiring different evidence.
There is also a subtler implication: because autonomous drone inspection can access areas that are too dangerous for routine human entry, it may enable more frequent inspection of assets that were previously inspected rarely. More frequent inspection of assets in hazardous states creates exposure scenarios that human inspection frequency made statistically rare. A drone performing weekly inspection of active high-voltage equipment encounters scenarios that human inspectors performing quarterly inspection would encounter at a fraction of the rate. The system’s hazard analysis must account for this increased exposure frequency.
What Multi-Regime Complexity Reveals
Percepto’s regulatory situation is an extreme version of a problem that any hardware product sold into multiple major markets faces. The specific demands of autonomous BVLOS aviation amplify the underlying challenge: requirements cannot be informal, operational assumptions cannot be implicit, and design decisions that affect safety or compliance cannot be left in individual developers’ heads.
The organizations that solve this class of problem successfully tend to share a structural characteristic: they treat their requirements as a first-class engineering artifact maintained alongside the code and the hardware, not as documentation produced after design decisions are made. Multi-regime regulatory compliance at the complexity Percepto faces is not achievable through a documentation sprint before a certification audit. It requires that the regulatory constraints be present in the engineering conversation from the beginning, that design decisions affecting compliance be traceable to the requirements that motivate them, and that changes in one regulatory regime be assessable for their effect on the overall requirements architecture.
This is precisely where the gap between legacy requirements management tooling and more modern approaches becomes operational rather than theoretical. Tools that treat requirements as structured documents in a database support compliance documentation. Tools that model requirements as connected nodes in a graph — where a change in one requirement propagates through its dependencies and surfaces traceability impacts — support compliance engineering. The difference matters most when the regulatory environment changes, which in autonomous aviation is not a rare event.
Honest Assessment
Percepto is solving a genuinely hard problem. Autonomous BVLOS inspection for critical infrastructure is not a mature category with established playbooks. The regulatory frameworks they operate under are themselves evolving, which means Percepto’s compliance requirements are a moving target.
The systems engineering challenge they face — multi-regime regulatory compliance for an autonomous system with industrial integration requirements — is a useful lens for the broader industry. Autonomous industrial systems that replace human decision-makers in regulated environments will always face some version of this problem. The organizations that learn to manage requirements at this level of complexity — not just produce requirements documents, but actively engineer and maintain the relationships between requirements, design decisions, and regulatory obligations — will have a structural advantage as autonomous systems move from pilot programs into standard industrial practice.
Percepto’s commercial traction in mining and energy suggests the market need is real and the value proposition is landing. The harder, less visible question is whether the underlying requirements and compliance architecture scales as the deployment footprint grows and the regulatory environment continues to evolve. That question will be answered over the next several years, and the answer will matter for the entire autonomous inspection industry.