> ## 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.
# Tamper-Evident Aviation Records
> How PlaneConnection uses SHA-384 hash chains and multi-layer external anchoring to provide cryptographically verifiable, tamper-evident records across safety, maintenance, flight ops, and crew domains.
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 dozens of other record types -- 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 without
requiring operators to understand cryptography. Every regulatory record --
across safety, maintenance, flight ops, and crew domains -- acquires a
tamper-evident fingerprint at the moment it is saved. Three layers of
independent external proof anchor that fingerprint to calendar time. If any
record is altered after the fact, the system detects the discrepancy and
surfaces it immediately.
**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](/en/how-to/ops/verify-record-integrity). For technical
anchor specifications, see the [Record Integrity Anchors
Reference](/en/reference/record-integrity-anchors).
## 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:
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.
### 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.
```
Record N-1 ──hash──► Record N ──hash──► Record N+1 ──hash──► ...
↑ includes hash(N-1)
```
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.
### 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.
A part passport proof bundle -- a self-contained export of the passport 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 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
Step-by-step guide for running verification checks and exporting proof bundles.
Technical specifications for RFC 3161, OpenTimestamps, and EVM anchor types.
Creating and closing maintenance work orders that feed the hash chain.
How regulatory records relate to aircraft, trips, and the broader data model.