> ## Documentation Index > Fetch the complete documentation index at: https://docs.planeconnection.com/llms.txt > Use this file to discover all available pages before exploring further. # Record Integrity Architecture > Deep explanation of PlaneConnection's 5-layer tamper-evidence system for aviation regulatory records — why each layer exists, the regulatory context (14 CFR 91.417, 14 CFR 5.97), and how blockchain anchoring provides immutable proof of record existence. Aviation regulatory records are legal documents. Under 14 CFR Part 43, 14 CFR 91.417, and 14 CFR Part 5, operators must maintain accurate records of inspections, repairs, airworthiness directives, safety reports, flight logs, crew training, and other operational records for the life of the aircraft and often beyond. A record that can be silently altered -- whether by accident, system error, or bad intent -- undermines this legal foundation and creates safety risk that may be invisible until an audit or incident reveals it. PlaneConnection's record integrity system addresses this problem with five independent layers of tamper evidence across 19 record types spanning safety, maintenance, flight ops, and crew domains. This page explains why each layer exists, what threat it mitigates, and how the layers work together. **Who should read this:** Directors of Maintenance, safety managers, chief pilots, DOM/AE staff, compliance officers, accountable executives, insurers, and engineers who need to understand the architecture behind PlaneConnection's audit defensibility. For step-by-step verification procedures, see [Verify Record Integrity](/en/how-to/ops/verify-record-integrity). For technical specifications, see the [Record Integrity Anchors Reference](/en/reference/record-integrity-anchors). ## The Problem: Why Tamper-Evident Records Matter Aviation regulatory records are the definitive evidence that an operator is compliant and an aircraft is airworthy. When an FAA inspector, insurance auditor, or accident investigator examines records, they need to trust that what they see is what was actually recorded -- not a revised version. Several failure modes motivate tamper-evident design: **Human error.** A maintenance technician updates the wrong record, realizes the mistake, and corrects it -- but the audit trail of the correction is not captured. From the outside, it looks like the record was changed without explanation. **System error.** A database migration, backup restoration, or software bug silently updates timestamps or field values. No one intends harm, but record accuracy is compromised. **Fraud.** In rare but documented cases, maintenance records have been falsified to conceal deferred work or extend inspection intervals. The consequences for air safety and operator liability are severe. **Data migration.** When operators move from one platform to another, records must transfer without loss. If the receiving system cannot verify that imported records match what was exported, the chain of custody is broken. ## The Regulatory Foundation Six primary regulations drive the design: | Regulation | Requirement | How record integrity addresses it | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | **14 CFR 91.417** | Maintain maintenance records for the life of the aircraft. Records must accurately reflect all inspections, repairs, and alterations. | SHA-384 hash chains detect any modification to record content. External anchors prove records existed at the claimed time. | | **14 CFR 43.9** | Maintenance records must include specific content (description of work, date, signature, certificate number). | Canonical serialization ensures all required fields are included in the hash. Missing fields produce a different hash. | | **14 CFR 5.97** | SMS operators must maintain the integrity of safety data and safety information. | Cross-layer verification detects discrepancies between database records and external proofs. | | **14 CFR 5.21** | Safety policy must include reporting systems with data integrity protections. | Safety reports, investigations, and CPAs are hash-chained and externally anchored at creation time. | | **14 CFR 135.63** | Part 135 operators must maintain flight records including load manifests and dispatch releases. | Flight logs, weight & balance, and dispatch releases are protected by the same 5-layer integrity system. | | **AC 120-92D** | SMS guidance recommends data integrity controls for safety records. | The 5-layer system exceeds AC 120-92D's guidance by providing cryptographic proof, not just access controls. | ## The Trust Model PlaneConnection separates two distinct questions: 1. **Has this record changed since it was saved?** (local integrity) 2. **Did this record actually exist at the claimed time?** (temporal proof) Answering the first question requires only a hash. Answering the second requires an external anchor that was created at the time the record was first saved -- something that cannot be backdated. Neither question alone is sufficient. A hash proves integrity but not time. A timestamp proves time but not integrity. Together, they prove that specific content existed at a specific moment and has not changed since. ## The Five Layers ### Why Five? Multiple independent layers provide defense in depth — no single point of failure can compromise record integrity. The layers use complementary trust models (certificate authorities, proof-of-work, and programmable verification) so that records remain verifiable even if individual systems experience outages or deprecation. ### Layer 1: SHA-384 Record Hashing Every regulatory record is hashed at the moment it is saved using SHA-384 via the Web Crypto API (zero external dependencies). SHA-384 was selected per the CNSA 2.0 mandate for cryptographic agility -- it provides a 192-bit security level, above the 128-bit minimum recommended for long-term protection of sensitive data. The hash covers the record's canonical content: field values sorted alphabetically, serialized as JSON, with undefined values omitted and null values preserved. This deterministic serialization means the same record always produces the same hash, regardless of the order in which fields were written to the database. **Threat mitigated:** Any modification to a record's content -- even a single character change in a technician note -- produces a completely different hash. Verification immediately detects the alteration. ### Layer 2: Hash Chain (Per-Aircraft Linked List) Each aircraft maintains its own hash chain where every record's hash incorporates the previous record's hash. This creates a tamper-evident linked list: altering any historical record invalidates not only that record's hash but every subsequent hash in the chain. The chain is analogous to a tamper-evident seal on a physical document folder. The seal itself is not the document, but breaking the seal is visible evidence that someone opened the folder. **Threat mitigated:** An attacker who modifies a single historical record cannot simply recompute that record's hash -- they would need to recompute every subsequent hash in the chain. The chain break is visible to any auditor running a verification check. ``` Record N-1 ──hash──► Record N ──hash──► Record N+1 ──hash──► ... ^ includes hash(N-1) ``` ### Layer 3: RFC 3161 Trusted Timestamping Immediately after a record is saved, the system submits its hash (via a Merkle root) to three accredited Timestamping Authorities in parallel: DigiCert, Sectigo, and Apple. Each TSA signs a timestamp token that cryptographically binds the hash to a calendar time verified against the TSA's trusted clock. RFC 3161 timestamps are accepted in legal and regulatory proceedings worldwide (including EU eIDAS and US federal courts). They are the fastest anchor layer, typically confirmed within seconds. **Threat mitigated:** An operator could theoretically delete all records and reconstruct a new chain backdated to the original dates. RFC 3161 timestamps prevent this because the TSA's signature cannot be forged without access to the TSA's private key. The token proves the hash existed at a specific time. ### Layer 4: OpenTimestamps (Bitcoin Anchoring) The system batches record hashes into a Merkle tree and submits the root to the Bitcoin blockchain via the OpenTimestamps protocol. Bitcoin's proof-of-work consensus makes it economically infeasible to rewrite blockchain history. An OpenTimestamps proof that a hash was anchored to block 850,000 (for example) provides independent confirmation that the record existed before that block was mined -- a fact that requires no trust in PlaneConnection or any certificate authority. **Threat mitigated:** RFC 3161 relies on trusting the TSA (a certificate authority). OpenTimestamps provides an alternative trust model based on computational work rather than institutional trust. Even if all three TSAs were compromised, the Bitcoin anchor remains valid. OpenTimestamps anchoring is free and requires no account or API key. The protocol is open source, and the calendar servers are operated by the community. This layer adds zero marginal cost to PlaneConnection's integrity system. ### Layer 5: EVM Smart Contract Anchoring The system publishes Merkle roots to a purpose-built smart contract on an EVM-compatible blockchain. This layer provides programmable verification — anyone with a blockchain client can query the contract to verify that a specific Merkle root was anchored at a specific time. The contract supports batch anchoring, allowing hundreds of records to be anchored in a single transaction at negligible cost. This is significant for operators with high record volumes — a busy Part 135 operation generating dozens of records per day can anchor them all efficiently. For contract addresses and technical details, see the [Record Integrity Anchors Reference](/en/reference/record-integrity-anchors). **Threat mitigated:** EVM anchoring provides a third independent trust anchor (after TSA certificates and Bitcoin proof-of-work) based on blockchain consensus. It also enables future integration with emerging digital airworthiness frameworks that may require on-chain attestation. ## How Blockchain Anchoring Works The term "blockchain anchoring" can be misleading -- PlaneConnection does not store regulatory records on a blockchain. Instead, it stores a compact fingerprint (Merkle root) that represents a batch of records. Here is the precise sequence: ### Step 1: Records are hashed and chained When regulatory records are saved, each gets a SHA-384 hash that incorporates the previous record's hash (Layer 1 and 2). ### Step 2: Hashes are batched into a Merkle tree Individual record hashes are combined into a binary Merkle tree. The root of the tree is a single 48-byte value that represents all records in the batch. ### Step 3: The Merkle root is anchored externally The Merkle root is submitted in parallel to RFC 3161 TSAs, OpenTimestamps calendar servers, and (optionally) the EVM RecordAnchor contract. Each layer returns a proof or receipt. ### Step 4: Proofs are stored alongside records The RFC 3161 token (DER bytes), OpenTimestamps proof file, and EVM transaction hash are stored alongside the original records. ### Step 5: Verification compares stored hashes to anchored hashes When an auditor runs a verification check, the system re-computes hashes from source data and compares them to stored hashes. External proofs confirm the hashes existed at the claimed time. Any discrepancy triggers a tamper alert. ## Part Passports and Back-to-Birth Traceability Beyond individual record integrity, PlaneConnection maintains a **part passport** for each tracked component -- a complete, hash-chained history from manufacture through every installation, inspection, repair, and removal. The part passport answers the question regulators and insurers increasingly ask: where has this component been, and what was done to it at every stage of its life? Under 14 CFR Part 45 and AC 20-62E, traceability to the component's origin is required for certain life-limited parts. Back-to-birth traceability means: * The initial airworthiness certificate and manufacturer documentation are anchored in the passport at import time. * Every maintenance action is cryptographically linked to the previous action. * Transfers between aircraft are recorded and anchored. * The passport travels with the component when it is sold or transferred to another operator. A part passport proof bundle -- a self-contained export with its hash chain and anchor proofs -- can be provided to a buyer, insurer, or regulator as independent evidence of the component's full history, verifiable without trusting PlaneConnection's servers. ## What the System Cannot Guarantee Tamper-evidence addresses integrity after a record is created. It does not guarantee that what was entered was accurate in the first place. If a technician enters incorrect data, that incorrect data is faithfully preserved and anchored. The system detects changes to records after they are saved; it does not validate the truth of the original content. This distinction matters for compliance. Record integrity is one element of a broader safety culture. Operators should maintain procedures for technical review of maintenance entries, not rely solely on cryptographic integrity checks. ## Design Decisions SHA-384 provides a 192-bit security level compared to SHA-256's 128-bit level. The CNSA 2.0 advisory recommends SHA-384 for data that needs to remain secure through the post-quantum transition period. Since maintenance records are retained for the life of the aircraft (potentially decades), the stronger algorithm provides margin against future cryptanalytic advances. SHA-256 is supported for backward compatibility and for OpenTimestamps submission (which requires exactly 32-byte digests). A single TSA creates a single point of failure. If DigiCert's timestamping service goes offline or its certificate is revoked, records created during that period would lack RFC 3161 proof. Submitting to three TSAs in parallel ensures at least one token is available even during outages. The cost is negligible (requests are small and fast) and the redundancy is significant for records that may be audited years later. A global chain across all aircraft and workspaces would mean that verifying one aircraft's records requires downloading the entire chain -- potentially millions of entries. Per-aircraft chains keep verification focused and fast. A typical aircraft accumulates hundreds to low thousands of records over its lifetime, which can be verified in seconds. EVM-compatible networks provide programmable verification at low cost, enabling batch anchoring of hundreds of records in a single transaction. The anchor contract is purpose-built for aviation record anchoring and can be deployed across multiple EVM chains as needs evolve. Most operators do not need on-chain attestation for day-to-day operations -- RFC 3161 and OpenTimestamps provide sufficient proof. EVM anchoring is enabled per-environment when operators require blockchain-level attestation for high-value records or regulatory requirements. ## How Verification Works in Practice When an auditor or inspector requests evidence that a specific record has not been altered -- whether a maintenance work order, safety report, flight log, or training record -- the workflow in PlaneConnection produces a **proof bundle**: a PDF-format export containing the record's content, its hash, the RFC 3161 timestamp token, the OpenTimestamps proof (once confirmed), and the EVM transaction reference if applicable. The auditor can verify this bundle using standard tools (OpenSSL for RFC 3161, the OpenTimestamps client, or any Polygon block explorer) without requiring access to PlaneConnection. This independence from the platform is a deliberate design goal. The value of external anchoring is precisely that it does not require the auditor to trust the operator's own systems. ## Related Step-by-step guide for running verification checks and exporting proof bundles. Technical specifications for all five layers including contract ABI and TSA endpoints. How maintenance records relate to aircraft, trips, and the broader data model. Overview of tamper-evident records across all 19 protected record types.