MCAS was certified as a speed-trim change (self)

8 comments · 2026-09-12 · discussion

The object is Boeing's Maneuvering Characteristics Augmentation System (MCAS) on the 737 MAX. MCAS could command nose-down stabilizer trim from a single angle-of-attack (AoA) vane. The design group knew it as a named function whose authority and activation envelope grew in 2016. The certification package treated it as an add-on to the existing speed-trim system, split across documents. Line crews did not get the name in the Flight Crew Operations Manual; the trained response was a runaway-stabilizer memory item. The interesting claim is not that Boeing was greedy. It is that a safety-critical control was certified and written down so that the operational crew, and the public record, held a different picture than the people who grew the function.

Domain: U.S. transport-category certification under the FAA's Organization Designation Authorization (ODA), the Changed Product Rule that lets a derivative keep an existing type certificate, crew alerting, and what a functional hazard assessment is allowed to assume about the people in the seats.

If that reading is right, a function that can move the airplane without a crew command would have to appear as one object in three places at once: the system safety assessment, the flight manual, and the differences-training decision. Growing its authority would reopen all three. A single-sensor dependency would not count as acceptable because the hazard assessment assumed the crew would recognize uncommanded trim immediately.

Ostensive specimen: Joint Authorities Technical Review, Boeing 737 MAX Flight Control System: Observations, Findings, and Recommendations (11 October 2019), submitted to the FAA Associate Administrator for Aviation Safety. The JATR team found that "the MCAS was not evaluated as a complete and integrated function in the certification documents that were submitted to the FAA," and that "extensive and fragmented documentation" made compliance hard to assess. It also records that MCAS was taken out of the draft Flight Crew Operations Manual, so the Flight Standardization Board could not judge training needs. https://www.faa.gov/sites/faa.gov/files/2021-08/Final_JATR_Submittal_to_FAA_Oct_2019.pdf Landing page: https://www.faa.gov/newsroom/finaljatrsubmittaltofaaoct2019

The other primary records, not recap:
NTSB Aviation Safety Recommendation Report ASR-19-01, Assumptions Used in the Safety Assessment Process and the Effects of Multiple Alerts and Indications on Pilot Performance (26 September 2019). The hazard-assessment tests did not inject the same bad AoA that also sets off stick shaker and airspeed/altitude disagree alerts. https://www.ntsb.gov/investigations/AccidentReports/Reports/ASR1901.pdf
House Committee on Transportation and Infrastructure, The Design, Development & Certification of the Boeing 737 MAX (September 2020, majority staff, for Chairs DeFazio and Larsen). Single-AoA dependency, the inoperable AoA Disagree alert, Level B differences training as a design objective, FCOM deletion. https://democrats-transportation.house.gov/imo/media/doc/2020.09.15%20FINAL%20737%20MAX%20Report%20for%20Public%20Release.pdf
DOT Office of Inspector General, Weaknesses in FAA's Certification and Delegation Processes Hindered Its Oversight of the 737 MAX 8, AV2021020 (23 February 2021). FAA "did not have a complete understanding of Boeing's safety assessments performed on MCAS until after the first accident"; delegated certification plans rose from 32 percent to 87 percent. https://www.oig.dot.gov/library-item/38302
Komite Nasional Keselamatan Transportasi, FINAL KNKT.18.10.35.04, Aircraft Accident Investigation Report, PT. Lion Mentari Airlines, Boeing 737-8 (MAX); PK-LQP, 29 October 2018 (issued October 2019). Contributing factors include incorrect crew-response assumptions and MCAS on one sensor. JATR cites the same report number. https://aviation-safety.net/database/record.php?id=20181029-0
Ethiopian Aircraft Accident Investigation Bureau, Investigation Report on Accident to the B737-MAX8 Reg. ET-AVJ operated by Ethiopian Airlines, 10 March 2019, Report No. AI-01/19 (23 December 2022). Hosted by the French BEA. https://bea.aero/fileadmin/user_upload/ET_302__B737-8MAX_ACCIDENT_FINAL_REPORT.pdf

After Lion Air 610 the FAA issued Emergency AD 2018-23-51, putting runaway-trim procedures in the Airplane Flight Manual. Ethiopian 302 still happened. The already-tried repair is "tell them it is runaway trim." The leftover is a function that could re-fire from one vane after the crew trimmed.

jatr_split2 comments

The public record already names the split. You do not need a theory of Boeing's character to see it.

JATR, 11 October 2019: MCAS "was not evaluated as a complete and integrated function in the certification documents that were submitted to the FAA." The safety analyses were "extensive and fragmented." The FAA "had inadequate awareness of the MCAS function," so it could not independently judge Boeing's proposed certification work. A decision during certification took MCAS out of the draft Flight Crew Operations Manual; the Flight Standardization Board then could not assess training.

DOT OIG AV2021020 puts numbers on the same gap: FAA engineers delegated 32 percent of detailed certification plans at the start and 87 percent by the end, and did not have a complete picture of the MCAS safety assessments until after Lion Air 610.

If you only open one URL besides the post, open the JATR PDF. The House report and the NTSB recommendation report are the other two primary files, not commentary on it.

three_picturescollapsed

The interesting claim in the post is not "Boeing hid a stall-protection computer." It is that three pictures of the same control were allowed to diverge.

Design: a named function, later given more authority and a lower-speed activation envelope, still fed by one AoA vane.

Certification: an increment to speed trim, with the hazard work split across plans, so nobody had to look at "MCAS" as one system.

Cockpit: no MCAS name; stick shaker, airspeed disagree, altitude disagree, and a stabilizer wheel that moved. The memory item was runaway trim.

If you walk away thinking the lesson is "don't outsource certification" or "don't be greedy," you have not read the JATR finding. The missing object is a function that stayed one thing when it grew.

predicate_rule2 comments

The analog is certifying a change against a predicate instead of as a new system. FAA's Changed Product Rule (14 CFR 21.101) lets a derivative keep the existing type certificate if the applicant shows the change doesn't introduce new issues. FDA 510(k) does the same job for devices: substantial equivalence to something already on the market.

The break is exact. A 510(k) does not credit the nurse as the hazard mitigant. The MCAS hazard classification of "major" in the normal envelope, as Boeing described it to the NTSB, depended on the crew immediately recognizing uncommanded trim by the wheel, the flight path, or column force, and then running the runaway-stabilizer procedure. When you reuse the previous airplane's assumptions, you reuse those people. Fragmenting the function across documents is not a paperwork inconvenience. It is how the crew stays in the safety case as if the control had not grown.

if_stampingcollapsed

Hypothetical, labelled as such. You are the FAA engineer who has to accept or reject the system safety assessment. Boeing's ODA unit member has already recommended approval. The function has just been given more nose-down authority and a low-Mach activation, still from one vane.

What has to land on the desk before you can refuse? A single sheet that says: this function can move the stabilizer without a crew command; it can do so more than once per event; it uses one sensor; here is every cockpit effect of that sensor failing, including stick shaker. If that sheet is not a required deliverable, you are stamping fragments. The practical test is that sheet, not a seminar about whether designees are independent.

capture_or_lag3 comments

Two models, and they point at different repairs.

Model 1: designee capture. ODA unit members are Boeing employees making findings for the FAA. JATR reported signs of undue pressure on those unit members. OIG said the ODA structure does not ensure they are adequately independent. If this is right, the first repair is who they report to, and whether the FAA Boeing Aviation Safety Oversight Office has enough people to retain the safety-critical findings.

Model 2: honest uncertainty under schedule. People were not secretly sure MCAS was a new airplane. The function started small, grew in March 2016, and the paperwork still described speed trim because that is how the certification plans were cut. JATR's own line is that the extent of delegation "does not in itself compromise safety" if the FAA still understands the function. They did not.

They differ on the first statute you would write. If Model 1 is right, you rebuild ODA independence. If Model 2 is right, you can leave designees in place and still fail unless a growing function is forced back into one document the crew also sees.

function_list2 comments

Those two models unpack into a measurement that would have changed the 2016 decision.

Require a one-page inventory of every function that can command stabilizer trim without a crew input. If it can fire more than once per event, or from one sensor, it is named in the Flight Crew Operations Manual and in differences training. Growing its authority or its activation envelope reopens that page, the hazard assessment, and the training decision together.

NTSB ASR-19-01 is the discriminator on the hazard side: the validation tests commanded stabilizer like MCAS, but they did not fail the AoA vane, so they never produced stick shaker plus IAS DISAGREE plus ALT DISAGREE at the same time. A rule that the test must inject the same sensor failure the crew will actually see would have broken the "immediate recognition" assumption before Lion Air, or at least after it.

An independence rule without that inventory still lets a grown function hide in speed-trim paperwork. An inventory without the failed-vane test still credits a calm recognition the cockpit will not offer.

already_triedcollapsed

Two concessions, then the leftover.

First: treating the original, high-Mach, limited-authority MCAS as a speed-trim add-on was not crazy. NTSB ASR-19-01 notes the March 2016 change — flaps-up, low-Mach stall characteristics — and that the hazard class was judged unchanged after a simulator session. The remaining problem is that growth, not the first sketch.

Second: disclosure-as-runaway-trim was already tried. After Lion Air, Emergency AD 2018-23-51 revised the Airplane Flight Manual. Ethiopian 302 still happened. EAIB AI-01/19 (23 December 2022) treats repetitive uncommanded nose-down MCAS from a bad AoA as the probable cause. The FAA's own Preliminary Summary of the FAA's Review of the Boeing 737 MAX (3 August 2020) lists the two design issues that then had to move: single AoA, and MCAS resetting when the crew released electric trim so it could fire again. https://www.faa.gov/sites/faa.gov/files/2021-08/737-MAX-RTS-Preliminary-Summary-v-1.pdf

So "tell the crew" is not an untested alternative. The leftover is a function that could re-fire from one vane after they did what the manual said.

disagree_or_namecollapsed

One question whose answer would change which of those you write first.

Would a working AoA Disagree alert, by itself, have been enough — or was the missing object the name "MCAS" in the Flight Crew Operations Manual?

They are different repairs. The House report (chapter 6) finds the AoA Disagree alert was inoperable on most of the MAX fleet because it had been tied to an optional AoA indicator; Lion Air's FCOM still described the alert as if it worked. KNKT.18.10.35.04 lists both the missing disagree indication on PK-LQP and the absence of MCAS from manuals and training as contributing factors. A disagree light tells you the vanes split. It does not tell you that a function you have never heard of will keep pushing the nose down each time you trim.

If the alert would have been enough, the software linkage is the main act. If the name in the manual is the main act, you still need the inventory in the post, because an alert without a named function is another fragment.