REGULATORY ALIGNMENT

How Flight Atlas structures records around 14 CFR §61.51(b).

Effective

2026-05-28

Last updated

2026-05-28

Reference regulation

14 CFR §61.51(b) — Pilot logbook entry elements

Related FAA guidance

AC 120-78B — Electronic Signatures and Electronic Recordkeeping

What 14 CFR §61.51(b) requires

Under 14 CFR §61.51(b), pilots must log the following elements for each flight or lesson used to meet aeronautical experience requirements:

• Date — the date of the flight or lesson.
• Total flight time or lesson time — duration of the flight or training session.
• Departure airport or location — the point from which the flight originated.
• Arrival airport, destination, or area of operation — where the flight or lesson concluded.
• Aircraft type and identification — type of aircraft flown, plus its registration or other identifier.
• Safety pilot name (if required) — name of the safety pilot when simulated instrument conditions apply.
• Type of pilot experience or training — solo, PIC, SIC, dual instruction, or other training category.
• Flight conditions — day or night, and actual or simulated instrument conditions.

These elements form the backbone of every pilot logbook entry that counts toward a rating, currency, or recency-of-experience requirement.

How Flight Atlas maps to §61.51(b)

Flight Atlas stores each flight record with dedicated columns that correspond to the §61.51(b) logbook-entry elements. When you import flight data from a provider like FlightAware, or when you enter a flight manually, the record is stored with the fields that the source provides:

• Date — flight_records.date
• Flight time — flight_records.duration_minutes
• Route — flight_records.origin and flight_records.destination
• Aircraft type — flight_records.aircraft_type
• Aircraft identification — linked via flight_records.aircraft_id
• Safety pilot — flight_records.safety_pilot_name
• Experience type — flight_records.pilot_experience_type
• Conditions — flight_records.flight_conditions

Every field is present in the ledger schema. Fields are populated when the import source provides the data; when a source does not supply a particular field, the column stores NULL. Field values are sourced from provider data, manual entry, or OCR — they are not independently validated against FAA records.

What signed proof packets prove

A Flight Atlas signed proof packet provides four forms of verifiable evidence:

• Existence. The packet proves that specific flight records were stored in the append-only ledger at a specific time, in a specific order.
• Order. Every record carries a monotonically increasing sequence number. The sequence order is part of the signed manifest.
• Hash integrity. Each record is hashed with SHA-512. The manifest bundles every record hash into a single attestation.
• Signature. The manifest is signed with your account's Ed25519 signing key. Anyone with the corresponding public key can verify that the manifest has not been altered since the moment it was signed.
• Field coverage. The regulatory alignment block in each proof packet enumerates which §61.51(b) fields are present for every record, along with the source column and whether the field value has been independently validated.

In plain terms: a signed proof packet is a verifiable, cryptographically sealed snapshot of what was in your ledger at the time of export. You can hand it to an examiner, employer, or insurer and say: "These records existed in this order at this time, and here is the cryptographic proof."

What signed proof packets do not prove

Proof packets are evidence of what Flight Atlas stored. They are not a substitute for the pilot's own duty to maintain an accurate logbook:

• Flight Atlas is not FAA-issued, FAA-approved, or FAA-certified. No regulatory body has reviewed, endorsed, or certified Flight Atlas.
• Proof packets do not replace the pilot's logbook. The pilot remains responsible for the accuracy and completeness of their logbook entries under 14 CFR §61.51. A proof packet is supplementary evidence — it does not discharge the pilot's logging obligations.
• Proof packets do not validate upstream data. If a provider reports an incorrect tail number, departure point, or flight time, the proof packet will faithfully attest that Flight Atlas stored that incorrect data. The signature proves integrity of storage, not accuracy of source data.
• Proof packets are not a guarantee of regulatory acceptance. Whether an examiner, employer, insurer, or operator accepts a proof packet is their decision. Flight Atlas makes no claim that a proof packet satisfies any specific regulatory, employment, or insurance requirement.

AC 120-78B: Electronic recordkeeping guidance

AC 120-78B provides FAA guidance for electronic signatures and electronic recordkeeping where records and signatures are maintained electronically. Advisory Circulars provide standards and guidance and are not mandatory regulations.

Flight Atlas's proof packet design — Ed25519 signatures, SHA-512 content hashing, and an append-only ledger — follows the general principles outlined in AC 120-78B for electronic record integrity and non-repudiation. However, conformance with an Advisory Circular does not constitute regulatory compliance, and operators should evaluate Flight Atlas against their own operational and recordkeeping requirements.

Instructor endorsements

Flight Atlas does not currently support instructor digital endorsements (such as those required under 14 CFR §61.87, §61.93, §61.39, or §61.189). The record fields for safety pilot name, pilot experience type, and flight conditions are stored in the ledger and can carry endorsement-related metadata, but the platform does not yet provide a dedicated instructor endorsement workflow with instructor-keyed signatures.

Instructor endorsements are a planned future capability. When available, endorsements will be stored as signed, append-only records in the same ledger, with the instructor's own Ed25519 key providing the signature, so an endorsement is independently verifiable without relying on the platform's integrity guarantees.