A change request is not paperwork. It is the only place a "why" is supposed to survive. When that place doesn't exist — when a design change moves through engineering, verification, and certification without one continuous record connecting it to its impact analysis — the change itself can be correct and the outcome can still be catastrophic.
A 0.6° system that became a 2.5° system
The Maneuvering Characteristics Augmentation System (MCAS) on the Boeing 737 MAX began, in initial design, as a limited-authority function: roughly 0.6 degrees of stabilizer trim, active only in a narrow high-speed, high angle-of-attack corner of the flight envelope, and reliant on assumptions established early in the aircraft's safety analysis.
During flight testing, engineers found the aircraft needed correction at lower speeds too. MCAS's authority was increased — ultimately to as much as 2.5 degrees per activation, able to re-trigger repeatedly, and driven by a single angle-of-attack sensor reading rather than a compared pair. That is a materially different system from the one the original hazard analysis had assessed.
The U.S. House Committee on Transportation and Infrastructure's final report (September 2020) and the international Joint Authorities Technical Review (JATR, October 2019) both reached a related conclusion from different angles: the expanded authority was not accompanied by a re-assessment that reliably reached everyone who needed it. The FAA's safety review team was not fully informed of the change's scope. Pilots were not told MCAS existed at all. Two aircraft — Lion Air Flight 610 in October 2018 and Ethiopian Airlines Flight 302 in March 2019 — were lost, with 346 fatalities.
What the investigations converged onThe individual engineering decisions were each explainable. What was missing was a single, traceable record connecting the design change to its updated hazard analysis, its verification evidence, and every party who needed to sign off on it.
Where the record breaks down
This is not a story about one bad decision. It's a story about a change that traveled through several rounds of engineering refinement — each individually reasonable — without a mechanism forcing the question: does the original safety case still hold, given what this change now does?
That is exactly the job of change control done right. A problem report or change request is supposed to be more than a ticket that gets closed. It is meant to carry, permanently and visibly: what changed, why, what it touches downstream, who reviewed the new impact, and what evidence confirms the system still behaves safely. When that chain is spread across engineering notebooks, email threads, and review minutes instead of one linked record, "why was this approved" stops being answerable — not because nobody knew, but because no single artifact ever held the whole answer.
The fix is boring, on purpose
Nothing about closing this gap requires heroics. It requires that every change — however incremental it looks in isolation — is linked to the requirements and hazard analyses it touches, that the impact is visible to reviewers before approval rather than reconstructed after an incident, and that the resulting record can answer an auditor's question in minutes rather than months.
That is the ordinary discipline PES is built around: a problem report or change request that is never just a ticket, but a node on the same thread as the requirement, the design, the test, and the review that approved it — so "what changed, and was it re-assessed" is a lookup, not an investigation.
