FLIGHT / KNOWLEDGE & DESIGN
Flight Permission and Approval | Make Conditions and Sources Visible
To guide someone to the right application, you have to handle the combination of location and flight method. Design for exceptions and unverified items at the same time.
Read this page in order
Split the decision into five boxes
Whether flight permission/approval is required depends on the airspace, the flight method, and more. Beyond the Civil Aeronautics Act procedures, you also need to watch the Act on Prohibition of Flying Small Unmanned Aircraft and local government or facility restrictions. Check the latest conditions in the procedure guidance from MLIT (Japan's Ministry of Land, Infrastructure, Transport and Tourism).
Source: MLIT | Flight permission and approval procedures| Box | Example inputs | How the result is held |
|---|---|---|
| Airspace | Airport surroundings, altitude, densely inhabited districts, etc. | Applies / does not apply / unverified |
| Method | Night flight, beyond visual line of sight, distance from people and property, etc. | A check for each operating condition |
| Aircraft and pilot | Certification, qualifications, applicable conditions | Validity of evidence managed separately |
| Ground and facilities | Land use, access, local restrictions | Record of confirmation with the manager |
| Temporary restrictions | Temporary designations, emergency changes | Applicable period and time the information was retrieved |
This list organizes the inputs to the decision; it is not an exhaustive legal determination table. When implementing conditional exceptions, go all the way to the statute and the review guidelines, and have a specialist review the result.
Don't store rules as prose alone
Give each rule a jurisdiction, effective date, applicable conditions, exceptions, source URL, and review status. Bury only the thresholds in code and, when the rules change, nobody can find what needs fixing.
rule = {
jurisdiction, effective_from, effective_until,
conditions, exceptions, required_actions,
source_url, source_checked_at, review_status
}
assessment = {
mission_revision, rule_version,
result: "requires_review",
missing_inputs, reasons
}Even with a permit, match it against this plan
Check the conditions written in the document: the covered aircraft, pilot, period, location, flight method, and so on. Never let AI guess at parts that can't be read. Let AI extract candidates, but keep comparison with the original and sign-off by the responsible person as explicit steps in the process.
| Change | Proposed app response |
|---|---|
| Switch to a different aircraft | Re-match the conditions for the covered aircraft |
| Change the start time | Recheck the validity period and temporary restrictions |
| Extend the route | Recheck the permitted area and ground management |
| Document text is illegible | Show "unreadable" and request resubmission |
Build a screen that doesn't go silent on failure
Map data unavailable, rule expired, permit unreadable. None of these three means "no problem." Show why the item is unverified and offer either an official check or a handoff to a person. Give the user a path forward.
DEFINITION OF DONE
When you build it, check these.
- Missing inputs and non-compliance are shown as distinct states.
- Missions assessed under an outdated rule can be identified.
- Sources, exceptions, and scope can be traced from the result.
Design checkpoints for spec reviews and functional testing.
Check the sources
Explanations of the rules and definitions draw on the material below. The screens, data, and definition of done are our own design proposals.
- MLIT | Flight permission and approval proceduresPermission and approval, airspace, and flight methods
Sources checked on: September 30, 2026. Please confirm how the rules apply to your case against the latest official information.