Weather and constraints
What validation checks before a mission flies, and what happens to a request that cannot fly yet.
What validation checks before a mission flies, and what happens to a request that cannot fly yet.
Between request and flight, every mission is validated. Validation is not a formality; it is the step that decides whether the flight happens.
Availability. Whether the pod and aircraft are free in the requested window.
Site operating constraints. The envelope established when the site was approved: the radius, the conditions and the limits that apply there. See Regulatory and airspace.
Weather. Conditions within the flight window, against the requirements of the aircraft and of the mission type. A survey needing consistent light has different tolerances to a perimeter check.
Equipment health. The state of the aircraft, the dock and the sensors.
Mission requirements. Whether what was requested can actually be captured as requested at this site.
Accepted. The mission proceeds to operation.
Held. Conditions are not suitable yet. The request stays live and flies when the window opens. This is the most common outcome for weather, and it is a normal state rather than a failure. Because the aircraft is already on site, waiting costs a delay rather than another mobilisation.
Not possible. The request falls outside what the site is approved or equipped for. You are told why and where the boundary is, so the next request does not hit the same wall.
Each occurrence in a series is validated on its own. A poor window delays or skips that occurrence and leaves the series intact, and the mission record shows which occurrences flew and which did not. See Recurring inspections.
Validation outcomes are part of the mission record. A held mission with a stated reason is more useful than a silent delay, particularly where the inspection supports a compliance or reporting obligation of your own.