Aircraft Registration and Fleet Register | Treat the Same Aircraft Correctly

According to MLIT (Japan's Ministry of Land, Infrastructure, Transport and Tourism), unmanned aircraft of 100 g or more flown outdoors must be registered. Also confirm how the registration mark is displayed and whether Remote ID applies. Remote ID has exceptions, so don't assume "every aircraft is handled the same way"; link to the official guidance instead.

Use an external number as the database's primary key and the maintenance and flight history gets lost the moment it changes. The proposal is to link history through the internal ID and hold official numbers as related records with a validity period.

Start with make, model, and serial number, and show possible duplicates. Then add the registration details and supporting documents. It helps if someone who hasn't finished the official registration can still save a draft. But keep "saved in the app" and "registration completed with the authority" visibly separate.

• If the same number already exists, let the user pick the existing aircraft before creating a new one.
• Separate owner from operator, and check the team's view and edit permissions.
• Record sensor and payload changes in the configuration history instead of duplicating the aircraft.
• If the registration expiry is unknown, save it as unknown and turn it into an open check item.

Below is the app's own design example. It is not the DIPS submission format, so don't send it to external systems as is.

{
  "aircraft_id": "aircraft_demo_01",
  "display_name": "Survey drone 1",
  "registration": {
    "jurisdiction": "JP",
    "mark": null,
    "expires_at": null,
    "verification_state": "unverified"
  },
  "configuration_version": 1,
  "readiness": "not_assessed"
}

Updating the aircraft record after a flight must never rewrite the configuration used on past flights. Keep both the current values in the register and a copy as of each flight. It's an unglamorous detail that pays off in a future incident investigation.