Part 135 operational control: what 135.77 actually means for the dispatch desk

14 CFR 135.77 is four sentences. It is also the legal foundation that determines who is responsible for every dispatch decision a Part 135 operator makes.

"Each certificate holder is responsible for operational control of each flight conducted under its certificate and shall list, in the certificate holder's operations specifications, the name and title of each person authorized to exercise operational control."

— 14 CFR 135.77(a)

That word — responsible — is doing a lot of work. The certificate holder does not just authorize flights; they are the legally accountable entity for every decision made in the name of that certificate.

What "operational control" means

Operational control means the exercise of authority over initiating, conducting, or terminating a flight. Under 14 CFR 1.1, a person who exercises operational control has, at that moment, the authority and responsibility for the safety of the flight.

For Part 135, operational control is exercised jointly by the PIC and the certificate holder — 135.77 makes the certificate holder accountable, while 135.75 and the general flight crew rules make the PIC the final authority once airborne. The dispatch desk is the certificate holder's expression of operational control before departure.

This is different from Part 121, where the dispatcher shares operational control with the PIC and both must concur in a flight release. Part 135 does not require a licensed dispatcher, but it does require an identifiable person — named in the OpSpecs — who is authorized to exercise that control on behalf of the certificate holder.

What the OpSpecs must list

Under 135.77(a), the operator's OpSpecs must list by name and title each person authorized to exercise operational control. This is not a general authorization — it is a named-person requirement. If the person making dispatch decisions is not in the OpSpecs, the certificate holder is running dispatches outside its approved authority.

Small operators frequently overlook this. The DO is in the OpSpecs. The owner is in the OpSpecs. But the operations coordinator who has been issuing flight releases for three years may never have been added. That is a certification problem, not just an administrative one.

When a compliance gate returns UNABLE

A pre-dispatch compliance gate — checking duty time, rest, medical currency, instrument currency, MEL, airworthiness — returns findings. When it returns UNABLE, that is not a prohibition on the flight. It is information presented to the person exercising operational control on behalf of the certificate holder.

The person in the OpSpecs who is authorized to exercise operational control may choose to override the UNABLE. 135.77 makes them responsible for that decision. The software's role is to surface the finding, cite the regulation, and log the override — not to lock the crew out of the aircraft.

This distinction matters because it is the correct legal framing. A compliance gate that positions itself as the decision-maker is overreaching. A gate that presents documented findings to the authorized person, logs their decision, and provides a tamper-evident record of that decision is operating within its proper scope.

The override is not inherently a violation

An UNABLE finding and a documented override does not mean the flight was illegal. It means the gate identified a potential issue and the person with operational control exercised their authority to proceed.

Examples where an override may be correct:

• The gate flagged an instrument approach as outside the 6-month window, but the pilot flew approaches yesterday and the logbook has not been updated yet. The DO verifies this and overrides with a note.
• The gate computed a rest violation, but the pilot's rest was calculated against a conservative interpretation that the operator's GOM explicitly addresses differently. The DO applies the GOM interpretation and overrides.
• The gate flagged a deferred MEL item as expired, but maintenance corrected the item this morning and the dispatch system has not yet been updated. The DOM confirms the squawk is cleared; the DO overrides with reference to the maintenance release number.

In all three cases, the override should be documented with the basis. That documentation is what converts an override from a red flag into a defensible operational decision.

What an undocumented override looks like in an FSDO investigation

An FSDO investigator reviewing a flight that ended in an incident will pull the dispatch record. If the flight was preceded by a compliance finding and no documentation of an override decision, the certificate holder's position is weak — the finding was there, the flight went anyway, and there is no record of who decided to proceed or why.

An override with a documented basis — the person in the OpSpecs, the timestamp, the cited reason — tells a different story. The system flagged the issue. Authorized personnel reviewed it. A decision was made and recorded. That is operational control functioning as designed.

The override rate and the quality of override documentation are among the most operationally revealing metrics in a compliance record. A certificate holder who can show a low override rate and well-documented overrides on the ones that happened has a materially different risk profile than one who cannot produce either.