14 CFR Part 89, the FAA's Remote Identification of Unmanned Aircraft rule, has been in full effect since September 2023. For most commercial UAS operators, compliance is not optional and documenting that compliance is part of a complete flight record. Yet many operators treat Remote ID as a hardware checkbox rather than a documentation requirement, which creates a gap when an auditor or incident review asks them to demonstrate compliance for a specific flight on a specific date.
This post covers what Remote ID documentation actually requires, where the documentation gaps typically appear for commercial fleets, and how an automated approach closes those gaps without adding preflight workload.
What Part 89 Actually Requires
Part 89 requires that most UAS operated in US airspace broadcast Remote ID information throughout the flight. The specific data broadcast must include: the UAS ID (either the serial number of a standard Remote ID compliant aircraft, or a session ID for aircraft using a Remote ID broadcast module), takeoff location (latitude, longitude, geometric altitude), current location and altitude, velocity, and a time mark.
Standard Remote ID is built into the aircraft itself. DJI aircraft manufactured after the compliance date have standard Remote ID built in via firmware. Older aircraft that predate the compliance date could achieve compliance through one of two paths: adding an FAA-accepted Remote ID broadcast module, or operating only at FAA-recognized identification areas (FRIAs).
From a documentation standpoint, compliance means you can demonstrate for any given flight that the aircraft operated was either a standard Remote ID compliant aircraft or was equipped with an accepted broadcast module at the time. This requires knowing, per flight record, which aircraft was used, what its Remote ID capability is, and for module-equipped aircraft, what module was installed and whether it was functioning.
Where Documentation Falls Apart in Practice
The most common documentation gap we see is not that operators are flying non-compliant aircraft. It is that they cannot produce a clean record linking a specific flight to a specific aircraft's Remote ID compliance status.
Consider a survey firm running a fleet of six DJI Mavic 3 Enterprise aircraft and two older Matrice 210 v2s that were field-upgraded with Remote ID modules. The Mavic 3 Enterprise units are standard Remote ID compliant by design. The two Matrice 210s each carry a Remote ID module with its own serial number and firmware version. If an auditor asks for documentation showing Remote ID compliance for twelve flights conducted over a two-week period, the operator needs to show which aircraft flew which flights and, for flights on the Matrice 210s, that the module was installed and operational.
Without a system that links flight records to aircraft serial numbers and aircraft-level compliance records, this requires manual reconstruction. Most operators do have this data; it just lives in multiple places that were never connected. The DJI FlightHub record shows the aircraft. The purchase receipt or installation record for the Remote ID module is somewhere else. The flight log shows the flight. Connecting all three for twelve flights across a two-week window is exactly the kind of task that takes four hours when it should take four minutes.
The Fleet Register as a Foundation
The starting point for automatable Remote ID documentation is a fleet register: a per-aircraft record that captures each aircraft's Remote ID status and effective compliance date. For standard Remote ID aircraft, this is the serial number, model, and the firmware version that enabled Part 89 compliance. For module-equipped aircraft, it includes the module make, model, and serial number alongside the aircraft record.
This register does not change frequently. Aircraft are added when purchased and removed when retired. Module upgrades trigger an update. It is a relatively small data set, but it is the data set that every flight record needs to reference for Remote ID compliance demonstration.
NVdrones maintains this fleet register as a first-class record. When a flight log is ingested, the aircraft serial number extracted from the log is cross-referenced against the fleet register to attach the aircraft's compliance record to the flight. For module-equipped aircraft, the compliance record includes the module serial number and installation date. This linkage happens automatically at ingest time, not retrospectively when someone asks for it.
Per-Flight Remote ID Documentation
At the per-flight level, Remote ID compliance documentation consists of two things: the flight record identifying the aircraft used, and the aircraft's compliance record showing it was Part 89 compliant at the time of the flight.
Flight log data from DJI aircraft provides the aircraft serial number directly. SRT logs embed the aircraft model; DAT logs contain the full serial number and, for aircraft with standard Remote ID, firmware version data. CSV exports from FlightHub or DJI Pilot typically include aircraft serial number as a field. Parsing this out of each log and attaching it to the flight record is a mechanical step that does not require manual entry.
The generated compliance documentation for each flight should, at minimum, show: date and time of flight, aircraft serial number, confirmation of Remote ID compliance method (standard or module), and the basis for that confirmation (firmware version date for standard, module serial number for modules). For a fleet with clean data, this can be produced per-flight at report generation time with no human involvement after initial fleet register setup.
FAA TRUST and Pilot Certificate Linkage
Remote ID compliance documentation does not exist in isolation from pilot certificate records. Part 107 operations must also demonstrate that the remote pilot in command held a valid certificate. When generating compliance documentation, linking the flight record to a pilot certificate number is part of the complete picture. This is particularly relevant for operations where multiple pilots share aircraft, because the aircraft's Remote ID record and the pilot's certificate record need to be associated to the same flight event.
Operators who track this manually typically maintain a preflight sign-out sheet or use a dispatch system. Operators who automate it typically capture pilot identification at the time of flight log ingest, either through a field in the upload interface or through integration with a dispatch or scheduling system. The end state is a flight record that carries both the aircraft's compliance attributes and the pilot's certificate information, generated from log data rather than assembled from multiple manual sources.
What Automation Does Not Solve
Automation handles the mechanical assembly of records from existing data sources. It does not fix underlying compliance gaps. If an aircraft in your fleet is operating without Remote ID capability because a module was removed or a firmware version was never updated, automated documentation will surface that gap, not hide it. A fleet register that accurately reflects each aircraft's compliance status is the prerequisite for automated documentation to be useful rather than misleading.
Similarly, for operations at FRIAs, the documentation picture is different. FRIA operations are exempt from the broadcast requirement, but the operator needs to be able to show that the flight took place within the FRIA boundaries. That requires location data from the flight log, not Remote ID broadcast records. The automation pattern is different, but the principle is the same: per-flight documentation linked to the aircraft and location data from the log.
The goal is documentation that reflects operational reality accurately, not documentation that looks complete on the surface. Audit-ready records are only valuable if they are accurate.