Who should read this: Directors of Maintenance, safety managers, chief pilots, compliance
officers, accountable executives, and insurers who need to understand how PlaneConnection
supports audit defensibility across all regulatory record types. For step-by-step verification
procedures, see Verify Record Integrity. For technical
anchor specifications, see the Record Integrity Anchors
Reference.
Protected Record Types
PlaneConnection protects 19 record types across four operational domains, each tied to specific regulatory requirements:Safety Management (14 CFR Part 5, AC 120-92D)
| Record type | Regulatory basis |
|---|---|
| Safety reports | 14 CFR 5.21 — safety policy requires reporting systems with data integrity |
| Investigations | 14 CFR 5.63 — investigation findings must be preserved for trend analysis |
| Corrective actions (CPAs) | 14 CFR 5.65 — corrective actions must be documented and tracked to completion |
Maintenance (14 CFR Part 43, 14 CFR 91.417)
| Record type | Regulatory basis |
|---|---|
| Work orders | 14 CFR 43.9 — maintenance records must include description, date, signature |
| Inspections | 14 CFR 91.409 — required inspection programs and compliance records |
| AD/SB compliance | 14 CFR 39 — airworthiness directive compliance tracking |
| Discrepancies | 14 CFR 43.11 — discrepancy documentation during inspections |
| MEL deferrals | 14 CFR 91.213 — minimum equipment list deferral records |
| FAA Form 337 | 14 CFR 43.9(a) — major repair and alteration documentation |
| Part install/remove | 14 CFR 91.417(a)(2) — component installation and removal history |
Flight Operations (14 CFR Part 91, Part 135)
| Record type | Regulatory basis |
|---|---|
| Flight logs | 14 CFR 91.417 — flight time and cycle recording |
| eAPIS filings | 19 CFR 122.49a — advance passenger information for international flights |
| Weight & balance | 14 CFR 135.63 — load manifest requirements for Part 135 |
| FRAT risk assessments | AC 120-92D — flight risk assessment documentation |
| Dispatch releases | 14 CFR 135.65 — operational control and dispatch records |
Crew (14 CFR Part 61, Part 135 Subpart E)
| Record type | Regulatory basis |
|---|---|
| Training records | 14 CFR 135.323 — training program records and completion documentation |
| Currency checks | 14 CFR 61.57 — recent experience and currency verification |
Why Tamper-Evident Records Matter
The aviation regulatory record is the definitive evidence that an operator is compliant. 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 that better suits the narrative. Several failure modes motivate tamper-evident design: Human error. A technician or safety officer 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, records have been falsified to conceal deferred work, extend inspection intervals, or suppress safety findings. 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. Under 14 CFR 5.97 — which requires operators to maintain the integrity of safety data — record integrity is not merely a best practice. It is a compliance obligation for Part 135 operators with an SMS.The Insurance and Audit Advantage
Tamper-evident records provide measurable value for insurance underwriting and claims:- Reduced premiums. Insurers can independently verify that maintenance, safety, and training records have not been altered. Operators with cryptographically verified records demonstrate a higher standard of operational control, which underwriters increasingly recognize in premium calculations.
- Faster claims resolution. When an incident occurs, the proof bundle provides immediate, independently verifiable evidence of the operator’s compliance history. There is no ambiguity about whether records were modified after the event.
- Independent verification. Insurers, brokers, and auditors can verify record integrity without requiring access to PlaneConnection or trust in the operator’s systems. The proof bundles are self-contained and verifiable with standard open-source tools.
The Trust Model
PlaneConnection’s approach separates two distinct questions:- Has this record changed since it was saved? (local integrity)
- Did this record actually exist at the claimed time? (temporal proof)
Local Integrity: Hash Chains
When a record is saved, the system computes a SHA-384 cryptographic hash of the record’s canonical content (field values, attachments, metadata, and the hash of the immediately preceding record in the chain). This hash is stored alongside the record. SHA-384 produces a 48-byte digest. Any change to the record’s content — even changing a single character in a technician note or safety narrative — produces a completely different hash. The chaining property means that altering any historical record invalidates not only that record’s hash but every subsequent hash in the chain. An auditor running a verification check will see exactly where the chain breaks and which records are affected.External Anchoring: Proof That Records Existed at a Specific Time
A hash chain proves that records have not changed since they were created, but it does not prove when they were created. An operator could theoretically delete all records and reconstruct a new chain backdated to the original dates. External anchors prevent this by publishing the hash to an independent system at the time of creation. PlaneConnection uses three external anchor layers, each with different characteristics and trust assumptions: RFC 3161 Trusted Timestamping. Immediately after a record is saved, the system submits its hash to an accredited timestamping authority (TSA). The 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 and are the fastest layer (typically confirmed within seconds). OpenTimestamps (Bitcoin anchoring). The system also batches record hashes and publishes them 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. EVM Smart Contract Attestation. The system publishes record hashes to a purpose-built smart contract on an Ethereum-compatible network. The UniversalAnchor V2 contract supports batch anchoring with workspace and record-type scoping, allowing hundreds of records to be anchored in a single transaction at a cost of approximately $0.001 per anchor. This layer provides programmable verification and integrates with emerging digital airworthiness frameworks.Not all three anchor layers are required simultaneously. Each layer provides independent proof.
Having multiple layers means that even if one anchor source becomes unavailable years from now,
the others remain valid. For most Part 135 operators, RFC 3161 timestamps satisfy current
regulatory requirements. OpenTimestamps provides the strongest long-term immutability guarantee at
no cost.
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. The part passport extends this to the full operational history. 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.
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 entries, not rely solely on cryptographic integrity checks.How Verification Works in Practice
When an auditor or inspector requests evidence that a specific record has not been altered, 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 Ethereum 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
Verify Record Integrity
Step-by-step guide for running verification checks and exporting proof bundles.
Record Integrity Anchors Reference
Technical specifications for RFC 3161, OpenTimestamps, and EVM anchor types.
Manage Work Orders
Creating and closing maintenance work orders that feed the hash chain.
Flight Operations Data Model
How regulatory records relate to aircraft, trips, and the broader data model.