Supplemental to Certificate Holder Recordkeeping. The Operations Audit Log is supplemental to the certificate holder's primary recordkeeping system and is not a substitute for compliance with the certificate holder's Operations Specifications (including A011 — Areas of En Route Operation Authorized, A012 — Airports Authorized — Special Requirements), General Operations Manual, or FAA-approved Part 135 manual system. The certificate holder is solely responsible for compliance with 14 CFR §135.21, §135.63, §135.439, and applicable Operations Specifications.

Operations Audit Log

For a Part 135 operator, the audit log is the artifact. When a POI walks in for a ramp check, what they want to see is not a UI — it is an evidence chain that survives an FAA Letter of Investigation. AeroCopilot's OpsAuditLog is an append-only, database-enforced, multi-year retention record built so that what an inspector sees on Wednesday is what your dispatcher recorded on Tuesday.

Append-only, enforced at the database

Immutability is enforced at the row level, not the application layer. The laanc_request_event table — the closest sibling pattern to OpsAuditLog — carries a Postgres trigger that blocks UPDATE and DELETE outright. The only documented bypass is SET LOCAL session_replication_role='replica', reserved for the retention-purge cron. The same pattern protects the audit chain: a dispatcher cannot rewrite history, and neither can a developer hot-fixing prod.

The result is a chain of (timestamp, actor, entity, action, snapshot) rows that an inspector can reconcile against the dispatcher's screens.

What gets logged

Every regulatorily significant operation appends to OpsAuditLog:

• Release lifecycle — every state change on a FlightRelease (created, signed, dispatched, closed).
• §135.267 hard-block override — the override path appends an entry under entity="release_267_override" with a cumulative duty snapshot and one of five audit-grade reason codes: urgent_medical, public_safety, pic_voluntarily_extended, incorrect_logged_history, other_documented.
• ForeFlight packet send — the cinematic-grade HTML email release is logged under entity="foreflight_packet" with the §135.77 attestation captured.
• POI Live Audit Portal visits — each inspector visit logs entity="poi_view", creating a bidirectional chain-of-custody.
• Crew lifecycle — mechanic created / deactivated, crew swap requests submitted / withdrawn / approved / declined, unavailability marked / cleared.
• Life-limited parts — installed, removed, scrapped (rows soft-deleted to preserve the chain).
• Dangerous goods — declared, pic_signed, deleted (append-only, scoped to certificate).
• Mishap and corrective action — created, reported_to_faa, faa_acknowledged, closed.

Retention windows

Retention is set to the longest applicable regulatory window for each artifact:

• OpsAuditLog and SubscriptionConsentLog — 7-year retention, set by Durante Tech policy for litigation and insurance cover (and, for consent, state AG audit requirements). No 14 CFR part 135 paragraph sets a retention floor for either table; seven years clears every floor that touches the underlying records — §135.63(b) (6 months, aircraft list; 12 months, pilot and flight-attendant records) and §135.63(d) (30 days, completed load manifests) — by years.
• LAANC events — 7-year retention per FAA UDDS LOA Section 8 (the public-facing rationale the LAANC Status Timeline cites).
• Trip records — 365-day immutable trip record retention per §135.63.
• Dispatch weather snapshots — 365 days per §135.63 (immutable METAR / TAF / SIGMET frozen at release time).

Removed life-limited parts are soft-deleted rather than hard-deleted because §135.439(a)(2)(ii) makes the current status of life-limited parts a maintenance record, and §135.439(b)(3) requires those records to be retained and transferred with the aircraft at the time the aircraft is sold — the obligation outlives the part's installation. Removed mechanics and removed crew records are soft-deleted for the parallel reason under §135.63: the individual pilot record of §135.63(a)(4) and the flight-attendant record of §135.63(a)(5) carry a 12-month floor under §135.63(b) that outlives the person's assignment.

§135.63 Inspector Bundle

The audit log is the spine of the one-click ramp-check artifact. The § 135.63 Inspector Bundle is a multi-section CSV export with cross-table evidence in a single file:

• COVER PAGE — chain-of-custody preamble.
• AUDIT LOG — up to 5,000 rows.
• MEL DEFERRALS — up to 500 rows.
• AD COMPLIANCE — up to 500 rows.
• DISCREPANCIES — up to 500 rows.
• RELEASES — up to 1,000 rows.
• DUTY PERIODS — up to 2,000 rows.

The bundle was built specifically against the NTSB AIR-24-03 §135.63(c) expansion. It reuses ~90% of the existing /api/ops/audit/export plumbing, which is why the regulatory tailwind translates to a one-click feature rather than a quarter of work.

POI Live Audit Portal

The POI Live Audit Portal lands an inspector on a read-only dashboard with Safety Maturity (90 days), the most recent 50 audit log entries, and certificate info. Each visit writes its own entity="poi_view" row. The inspector's read of your evidence is itself part of your evidence — bidirectional chain-of-custody, NTSB AIR-24-03 §135.63(c) compliance.

What this means in practice

The combination — append-only, database-enforced, seven-year retention, structured wet-click signatures everywhere safety attaches, ramp-check-ready CSV bundle — is what an operations audit log has to be to survive a Letter of Investigation. It is the artifact your POI is going to ask for. It is the artifact your insurer is going to ask for after an event. It is, in every meaningful sense, the product.

Related

• Wet-Click Terms-of-Service Attestation
• Pilot Currency Tracking (§61.57)
• Airworthiness Directive Compliance