Electronic Signatures and Recordkeeping at Checkride

Overview

Checkride LLC operates a digital flight training platform that supports electronic logbook entry approvals and endorsement issuance between certificated flight instructors and their students. All electronic signature and recordkeeping functionality is designed to conform to:

• FAA Advisory Circular 120-78B, Electronic Signatures, Electronic Recordkeeping, and Electronic Manuals (current edition)
• The Electronic Signatures in Global and National Commerce Act, 15 U.S.C. § 7001 et seq. (ESIGN Act)
• The Uniform Electronic Transactions Act (UETA), as adopted in the applicable jurisdiction

This page describes the technical and procedural controls in place for each requirement. Questions may be directed to support@trycheckride.com.

Signer Identity Verification

Reference: AC 120-78B paragraph 2.1.2.2

Before recording any electronic signature on a logbook entry, the system requires the signing instructor to re-enter their account password in the same request as the signature blob. A failed password check is recorded as a failed signing attempt in the signature audit trail (see "Audit Trail" below) and the signature is not written.

The instructor's name and FAA certificate number (CFI number) that appear on a signed record are sourced at sign time from the authenticated user session and from the user's verified account profile. They are not accepted as client-submitted parameters and cannot be overridden by the browser or mobile app. This binding satisfies AC 120-78B's requirement that the electronic signature be uniquely linked to the individual making the entry and that the system be capable of verifying who made the entry.

For endorsements, the instructor identity is bound to the authenticated session in the same way: the instructor_id, name, and certificate fields are drawn from the authenticated session at the time of creation, not from the request body.

Signature Integrity and Tamper Evidence

Reference: AC 120-78B paragraph 2.1.2.1

At the moment an electronic signature is recorded, the system computes a SHA-256 hash over a canonical, versioned set of the signed record's fields (the "payload hash"). The fields included in the hash for each schema version are fixed in the application code; adding or reordering fields requires a schema version bump that invalidates prior hashes for any row that is subsequently mutated.

The payload hash is stored on the record itself. At any time, the system can recompute the hash from the record's current fields and compare it to the stored value using a constant-time comparison. If the on-disk values have been altered after signing (for example by a direct database write outside the application), the comparison will fail, providing tamper evidence.

Signed logbook entries are made immutable by a Rails model callback that rejects any update to an approved entry. Corrections to a signed entry must go through a new, superseding entry chained to the original; the original is preserved intact with its hash. Endorsements follow the same pattern.

Audit Trail

Reference: AC 120-78B paragraph 2.2

Every attempt to sign or approve a logbook entry creates an append-only audit record (SignatureEvent) that captures:

• The authenticated actor (user ID and, by extension, name and CFI number from the user record at that point in time)
• The event type: approval succeeded, approval failed, rejection succeeded, rejection failed
• The reason for a failed attempt (for example: password invalid, CFI number missing, identity mismatch, entry not in pending status)
• The payload hash of the signed record, when the signing succeeded
• The canonical timestamp of the signing event
• The IP address from which the request originated
• The User-Agent string of the client (truncated to 500 characters)

SignatureEvent records are enforced as append-only at the model layer. Any attempt to update or destroy a SignatureEvent row raises an exception.

Status transitions on logbook entries (draft, pending approval, approved, rejected) are also captured in a separate audit table, which records the before and after status, the actor, the IP address, and the User-Agent.

Record Retention

Reference: AC 120-78B paragraph 2.3; ESIGN Act 15 U.S.C. § 7001(d)

Signed logbook entries and endorsements are retained for the life of the account. Account deletion by the user does not erase prior signed records. This is disclosed in the Checkride Privacy Policy (Section 6) and in the ESIGN disclosure presented to users before their first signature.

Withdrawal of electronic records consent is prospective only (per 15 U.S.C. § 7001(c)(3)): records signed before withdrawal remain in the system and remain valid. Withdrawal only prevents new signatures from being recorded until consent is re-granted.

Reproducibility and Paper Equivalents

Reference: AC 120-78B paragraph 2.4

Checkride provides logbook export functionality that produces a downloadable file of the authenticated user's logbook entries, including approval status and instructor identity fields. This export can be presented for inspection by an FAA aviation safety inspector, designated pilot examiner, or chief flight instructor.

Endorsements are similarly accessible through the user's endorsements view and can be printed or exported for paper presentation.

To request a paper copy of any specific record, contact support@trycheckride.com with the subject line "Paper Copy Request" and identify the record by date or title. We will respond within ten (10) business days.

User Consent (ESIGN Act)

Reference: 15 U.S.C. § 7001(c)(1)

Before any user may electronically sign or approve a training record on Checkride, the system presents an electronic records consent disclosure that satisfies all six elements required by 15 U.S.C. § 7001(c)(1): affirmative consent to electronic records; the right to paper copies and how to request them; the right to withdraw consent and the consequences; the scope of consent (account-wide, for logbook entries and endorsements); procedures to update contact information; and hardware and software requirements.

The user's acceptance is recorded in the database with a timestamp and the version number of the disclosure text presented. If the disclosure text is materially updated, the version number is incremented and users are re-prompted before their next signing action.

The full text of the current disclosure is presented in the consent modal accessible from Settings > Electronic Records.

Limitations and Regulatory Note

Checkride is a convenience tool and is not an FAA-approved system of record. The FAA does not formally approve or certify individual electronic logbook products. AC 120-78B describes acceptable means of compliance; it is the operator's and certificate holder's responsibility to ensure their recordkeeping practices conform to applicable regulations (14 CFR Parts 61, 91, 141, and 142 as applicable).

Checkride does not provide legal advice. Schools and operators integrating Checkride into their training programs should review their own regulatory obligations and, if appropriate, consult with their FSDO before relying on electronic records for compliance purposes.

Contact

Questions about Checkride's electronic recordkeeping system: support@trycheckride.com.