FLIGHT / KNOWLEDGE & DESIGN
Flight Plans, Day-of Checks and Flight Logs | Closing the Operation
Don't stop at filing a plan. Tie what you checked, what happened and how it ended into a single operation.
Read this page in order
Keep the plan and the actual record separately
For a specific flight (one that requires permission or approval), you need to confirm the obligations around advance flight-plan notification and flight logs. The latest guidance from MLIT (Japan's Ministry of Land, Infrastructure, Transport and Tourism) is the standard. An app's own records do not automatically satisfy the statutory format, so cross-check the fields it exports.
Source: MLIT | Flight plan notification and flight logsThe plan says "this is how we intend to fly"; the record says "this is what actually happened". Overwrite the plan with the record and you lose why the flight ran late and what was changed. Keep both and look at the difference.
Hand off responsibility across three phases
| Phase | Examples of checks and records | Signal of completion |
|---|---|---|
| Pre-flight | Aircraft condition, weather, surroundings, crew, emergency procedures | The person in charge confirms the conditions for this flight |
| In flight | Start and end, position, deviations, anomalies, operator inputs | End of flight and recovery of the aircraft confirmed |
| Post-flight | Defects, maintenance, media retrieval, required reports | Open items given an owner and a deadline |
A row of checkboxes alone is weak. When someone selects "anomaly found", the design must lead them on to an explanation and a point of contact. Go/no-go thresholds for weather and aircraft come from the model's manual, the operations manual and the on-site risk assessment. Don't fix a one-size-fits-all number here.
An example of state transitions
draft → planned → preflight_review → ready
ready → in_progress → landed → closed
preflight_review → on_hold
in_progress → contingency → landed
landed → follow_up_required → closedThese are example states for a record-keeping app. The design does not issue commands to the real aircraft from this sequence. If the link drops, don't lock in the last state received as "the current state"; report it as unknown, with a timestamp.
Recovering from offline
Assume the connection will be weak in the field, and consider letting unsent entries be held temporarily on the device. Show whether each entry has been shared, and reuse the same event ID on resend so nothing is registered twice. If someone else has updated the record in the meantime, don't overwrite silently; show the difference first.
DEFINITION OF DONE
When you build it, check these.
- Both the pre-change version of the plan and the actual flight record are kept.
- Unsent, sent and failed entries can be told apart.
- A case closed with an anomaly keeps an owner and a follow-up.
Design checklist items for use in spec reviews and functional testing.
Check the sources
The explanations of rules and definitions refer to the materials below. The screens, data and definition of done are our own design proposals.
- MLIT | Flight plan notification and flight logsPlan notification and records for specific flights
Sources checked on 30 September 2026. Confirm how the rules apply to your own case against the latest official information.