HOW PROOF PACKETS WORK

How Flight Atlas turns flight records into verifiable evidence.

Last updated

2026-06-05

Signature algorithm

Ed25519 (RFC 8032)

Hash algorithm

SHA-512

Key type

Account-level signing key pair, generated at tenant creation

What a proof packet is

A Flight Atlas proof packet is a cryptographically sealed bundle of your flight records. It contains three things:

• The records themselves — your flight data, including the §61.51(b) fields: date, flight time, origin, destination, aircraft type, conditions, and the rest.
• A manifest — a structured document that lists every record's hash, its position in the sequence, and a watermark that binds the export to a specific purpose and moment.
• A regulatory alignment block — a declaration of which §61.51(b) fields are present, where the data came from, and what the proof packet does and does not claim.

Step 1: Hashing — the digital fingerprint

When you export your records, Flight Atlas takes the content of every record and runs it through SHA-512, a cryptographic hash function. The result is a short, fixed-length string of characters — a hash — that acts like a digital fingerprint of that record.

Three properties make hashing useful for record integrity:

• Deterministic. The same input always produces the same hash. If two people hash the same record, they get the same result.
• One-way. You cannot reconstruct the original record from its hash. The hash is a fingerprint, not a compressed copy.
• Avalanche effect. Changing even one character of the record produces a completely different hash. There is no way to alter a record without the hash changing visibly.

If someone later claims "this record was in my ledger," anyone can recompute the hash and compare it to the manifest. If the hashes match, the record is identical to what was exported. If they do not match, the record has been altered.

Step 2: The manifest — bundling the proof

After each record is hashed, the hashes are assembled into a manifest. The manifest records:

• Every record hash — in the same order the records appear in the ledger, so the sequence is preserved.
• Sequence numbers — each record carries its append-only sequence number, proving that record 47 came before record 48.
• A watermark hash — a sentinel value that binds the manifest to a specific export purpose (e.g., "flight-atlas:export-proof:v1"). The watermark prevents a manifest from being reused out of context.
• Metadata — when the manifest was created, which key signed it, and the hash algorithm used.

The manifest is the "what was stored, in what order, at what time" document. It becomes the payload that gets signed.

Step 3: Signing — the verifiable seal

Once the manifest is built, Flight Atlas signs it using your account's Ed25519 private key. Ed25519 is a modern, high-speed digital signature algorithm (defined in RFC 8032).

The signing process works like this:

• Your account has a key pair: a private key that only Flight Atlas holds on your behalf, and a public key that anyone can use to verify signatures.
• The private key is used to produce a signature over the manifest content. The signature is a short string of bytes that is mathematically tied to both the manifest and the private key.
• Anyone with the public key can verify the signature. If the verification succeeds, it proves two things: (a) the manifest has not been altered since it was signed, and (b) the signature was produced by the holder of the private key.

This is the same class of cryptography used for SSH keys, signed software updates, and secure messaging. The math is well-understood and widely deployed.

What you can do with a proof packet

• Present it as evidence. Hand the packet to an examiner, employer, insurer, or operator. They can independently verify the signature and hashes without needing to trust Flight Atlas.
• Store it as a backup. The packet is a self-contained archive of your records at a point in time. Save it alongside your own logbook backups.
• Prove the record hasn't changed. If anyone questions whether a flight record was later altered, the proof packet provides a cryptographic answer: here is the hash, here is the signature, verify it yourself.
• Prove the sequence. Because every record carries an append-only sequence number, the packet proves that your flights were recorded in a specific order.

Current self-serve outputs

Flight Atlas account exports are built around the same signed record set. The current self-serve outputs are:

• JSON proof packet. Manifest, record hashes, per-record signatures, signer key IDs, and regulatory alignment metadata.
• Logbook CSV and PDF. Pilot-facing archive formats with public proof fields only. No private key material is embedded.
• ACORD XML. An insurer-verifiable supplementary evidence export that renders only after manifest and per-record proof checks pass.
• ISO 20022 SupplementaryData. A supplementary XML fragment that carries Atlas verification metadata without fabricating unsupported totals.
• Pilot-authorized verifier links. Account owners can mint, list, and revoke verifier links for selected proof fields without exposing raw tokens or token hashes.

What a proof packet does not do

• It does not certify regulatory compliance. A proof packet is supplementary evidence. It does not, by itself, satisfy any FAA recordkeeping requirement. The pilot is responsible for logbook accuracy.
• It does not validate source data. If your flight provider reports an incorrect departure time, the proof packet faithfully attests that Flight Atlas stored that incorrect time. The signature proves storage integrity, not data accuracy.
• It does not guarantee acceptance. Whether a third party accepts a proof packet is their decision. Flight Atlas does not warrant that any examiner, employer, insurer, or operator will accept it.
• It does not replace your paper or electronic logbook. A proof packet is an export artifact. Your logbook remains your primary record of aeronautical experience.