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 unverifiable-check override — the override path appends an entry under entity="release_267_override" with a cumulative duty snapshot, the list of checks the engine could not run, and one of two audit-grade reason codes: incorrect_logged_history, other_documented. The override exists only for a §135.267 check that could not be evaluated — most often duty or rest that was never recorded. A measured breach of §135.267(a) cannot be overridden here or anywhere in the product: the paragraph binds the certificate holder and the crewmember ("no flight crewmember may accept an assignment"), and the only relief in §§135.261–135.273 — §135.263(d) and §135.267(e) — is retrospective, so none of it authorizes assigning a crewmember already over the limit. An inspector reading one of these rows is therefore reading an unverifiable check, never a signed-off violation.

  This list carried five codes until 2026-09-06. urgent_medical, public_safety and pic_voluntarily_extended were removed along with the override branch they served: consent cannot cure a prohibition that binds the consenting party, and emergency medical work under part 135 runs under §135.271 (HEMES), which sets its own limits rather than waiving these.

• 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 days from arrival, set by Durante Tech policy, and stamped onto trip_record.retentionExpiry at creation. No 14 CFR part 135 paragraph sets a retention floor for a trip record — the term appears nowhere in part 135. The floor that matters is indirect: a trip record carries the PIC/SIC block time behind the §135.63(a)(4)(vii) pilot record, and §135.63(b) requires that record be kept at least 12 months, so purging trip records sooner can destroy the evidence for a record that is federally floored. Two limits to read plainly: the rows are not immutable (trip_record carries no Postgres trigger, and TripRecordService.update() mutates in place — unlike flight_release, ops_audit_log, currency_audit_log, laanc_request_event, admin_audit_log and pic_attestation, which are trigger-protected), and nothing purges on that date — retentionExpiry is written and read by no job, so 365 days is the declared policy, not an enforced ceiling.
• Dispatch weather snapshots — 365 days of Durante Tech policy for the METAR / TAF / SIGMET captured at release time. No part 135 paragraph sets a retention floor for a weather snapshot. dispatch_weather_package is written once by the release flow and never updated in application code, but it carries no immutability trigger and no retention column, so neither the write-once property nor the window is database-enforced.

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