Part 135 compliance software: what the category covers and what operators actually need

"Part 135 compliance software" covers a wide range of products, from crew scheduling tools with a currency-tracking tab to purpose-built pre-dispatch gates that block a release when a check fails. Understanding what the category actually contains — and where the gaps are — matters before evaluating any specific product.

What compliance means in Part 135 operations

In the context of Part 135 on-demand charter, compliance has three distinct layers:

1. Personnel compliance. Crew members holding the required certificates, ratings, medicals, and recurrent training — and those credentials being current on the date of the proposed flight.
2. Operational compliance. Duty time, rest, and flight time limits tracked against the proposed assignment before dispatch — not after the fact.
3. Aircraft compliance. Airworthiness, MEL deferred items, and inspection currency for the specific aircraft on the specific date.

All three layers must clear before a legally compliant Part 135 flight can be released. A tool that tracks one or two but not all three is a partial compliance tool, not a compliance gate.

The four product types in the market

1. Currency trackers

The most common product type — a roster system that stores crew credentials and flags expiring items. Typically covers medical expiry, training currency, instrument currency windows, and recurrent check dates. Outputs: warning emails, dashboard indicators, expiry reports.

What currency trackers do not do: connect the crew member's current status to a specific proposed flight. The tracker shows that a pilot's instrument currency expires in 45 days — it does not check whether that pilot is instrument current on the date of the proposed trip. That check requires a different calculation.

Useful as an administrative tool. Not sufficient as a pre-dispatch gate.

2. Scheduling platforms with compliance overlays

Mid-tier products — Leon, Q5, FOS — that built scheduling first and added compliance features as the market demanded them. Compliance is typically implemented as a visibility layer: the dispatcher can see that a crew member is approaching a duty limit, or that a medical is expiring, but the system does not prevent the dispatch action from completing when a check fails.

The practical consequence: compliance depends on the dispatcher seeing the indicator and acting on it. The audit trail shows a trip was dispatched, not that all compliance checks were verified before dispatch. In an FSDO inquiry, "the system showed it" and "the system blocked the release" are very different positions.

3. Pre-dispatch gates

Products built around the compliance check itself rather than scheduling. The quote or release does not proceed until the gate clears — duty time, rest, medical, instrument currency, training, MEL, airworthiness. A failing check blocks the release and requires either a corrective action (update the crew, find a different aircraft) or a documented override by an authorized person.

The key differentiator is the audit trail: not "the system showed a warning" but "the gate ran on [date/time], check [X] returned UNABLE, override documented by [name, credential, timestamp] with reason [Y]."

This is the architecture that produces a defensible compliance record for FSDO review, insurance submission, or litigation.

4. SMS platforms

Broader safety management tools — hazard reporting, corrective action tracking, safety meeting records, FRAT logging, training management — typically without tight integration to the dispatch workflow. Strong for SMS documentation; not built to run as a pre-dispatch gate.

Operators who need both the SMS record and the pre-dispatch gate typically run two systems: an SMS platform for safety program management and a compliance gate for dispatch.

The questions to ask before buying

Before evaluating any Part 135 compliance tool, establish what you are actually trying to accomplish and test the product against those specific outcomes:

• Does a failing check block the release? Or does it produce a warning the dispatcher can ignore?
• What is the audit trail? Can you produce a document showing what was checked, when, and what the result was for a specific flight?
• Are overrides documented? When a check fails and the flight goes anyway, is there a record of who authorized the override and why?
• What regulations does it check? List them: 135.267, 135.247, 135.293, 135.243, 135.179. If the vendor cannot list specific citations, the compliance coverage is probably generic.
• How are rule updates handled? When the FAA changes a regulation, how does the product update? Who is responsible for verifying the calculation is current?
• Can the methodology be reviewed by a DO? A compliance gate that cannot produce a document describing its rule interpretations cannot be validated by a Director of Operations — which means its outputs are advisory, not signed off.

What the record needs to show

The output of a compliant pre-dispatch process is not just a cleared flight — it is a record of what was checked and what the result was, stored in a way that can be retrieved on demand.

For an FSDO records request, the question is: "Show me your pre-dispatch compliance record for flight [X] on [date]." The answer should be a specific document — not a reconstructed account — showing the duty time calculation, the crew currency status, the aircraft airworthiness check, and the result of each.

For an insurance submission, the question is: "Show me your pre-dispatch compliance activity for the trailing 12 months." The answer should be an aggregate report — total decisions, UNABLE catches, override rate, corrective action closure rate — drawn from the compliance system of record.

A compliance tool that cannot produce either of those documents is tracking compliance for its own sake, not building the record that actually matters.