Regulatory and airspace
Approvals are obtained for a location before deployment and cover its flight radius, so there is no permission step between your request and your data.
Approvals are obtained for a location before deployment and cover its flight radius, so there is no permission step between your request and your data.
This is the single most misunderstood part of the model, and the part that most changes what the service is worth.
Regulatory approval is obtained for a location before a pod is deployed there, and it covers the flight radius around that fixed position. It is not obtained per mission, per customer or per request.
The work is substantial: months of elapsed time and hundreds of hours per location. That cost is why pods are fixed installations rather than equipment that gets moved to wherever the next job is.
There is no regulatory step between requesting data and receiving it. You do not wait for a permission, file anything, or nominate a pilot. When you request a mission at an approved site, the airspace question was settled before the pod arrived.
This is the difference between persistent deployment and hiring a drone operation, and it is most of the reason response times can be measured in minutes at a site that already has a pod.
Approval is not unlimited permission. It establishes an operating envelope for that site: a radius, a set of conditions, and limits on what can be flown and when. Requests outside the envelope are not possible at that site, and validation applies those limits to every request automatically. See Weather and constraints.
Approval also does not travel. It belongs to the location it was obtained for. A site with no approved pod has no route to a mission, however close it is to one that does. See Coverage and sites.
Because approval precedes deployment, the timeline for a new site is set by the approval rather than by hardware availability. This is worth planning around early. See Site requirements.