Digital Thread Safety: What the 737 MAX Teaches Us About PLM and Engineering Data

On October 29, 2018, Lion Air flight JT610 entered an uncontrollable nose-down dive minutes after takeoff from Jakarta and killed all 189 people aboard. Five months later, Ethiopian Airlines flight ET302 followed the same flight profile and killed 157 more. The proximate cause was MCAS — a flight control software system that Boeing's engineers had significantly modified during development without fully propagating that modification through the certification record.

This is not, primarily, a story about software failure. It is a story about what happens when engineering change management is treated as a documentation exercise rather than a governance function.

A complete Digital Thread — where every modification to a product definition is linked to its originating requirement, its downstream safety analysis, and the certification artifacts that depend on it — would have forced a reckoning with the MCAS changes before the aircraft reached service. That reckoning never happened.

---

What Happened to the MCAS Thread

MCAS was introduced to compensate for the aerodynamic effect of the 737 MAX's larger, repositioned CFM LEAP engines. The system was designed to push the nose down automatically when the aircraft's angle of attack exceeded certain limits during manual flight at high thrust. In its original form, MCAS had a maximum authority of approximately 0.6 degrees of stabilizer movement.

During development, that authority was increased to 2.5 degrees — more than four times the original design. The change was made to ensure the system could adequately correct the handling characteristics across the full flight envelope. It was a consequential modification to a flight control system operating in conditions that could meet the regulatory definition of hazardous or catastrophic failure.

The change was not reclassified under ARP4754A system safety guidelines. The hazard analysis for MCAS — which had originally characterized an erroneous MCAS activation as having a lower severity level — was not updated to reflect the increased authority. The FMEA (failure mode and effects analysis) for the system's single angle-of-attack sensor input, which could trigger an uncontrollable stabilizer runaway, was not re-examined against the new operating envelope. FAA Designated Engineering Representatives (DERs) who participated in certification were not fully briefed on the change. The type certificate for the 737 MAX was granted based on a product record that did not accurately represent what had been built.

The change existed in Boeing's engineering systems. The safety implications of that change were never propagated to the certification record.

---

What Change Traceability Should Have Enforced

A properly governed PLM change record for a safety-critical modification of this type would have required, at minimum:

Impact assessment linked to the safety hazard analysis. The MCAS authority increase was a change to a system parameter with direct bearing on the classification of failure conditions under ARP4754A. A change impact workflow tied to the original safety case would have identified FMEA items and fault tree nodes referencing the previous authority limit. Engineers would have been required to disposition each impacted artifact before the change could be released.

Certification artifact linkage. The type certificate basis for the 737 MAX referenced specific certification test results and analyses. A functioning Digital Thread traces every released design parameter to the certification artifact that validated it. When a parameter changes, the thread breaks — and a governed system does not allow that break to go unacknowledged. The linked certification documents would have been marked stale, requiring updated analyses under DO-178C for the software and DO-160 for environmental qualification.

Forced acknowledgment by DERs. In an PLM system with safety governance configured for Part 25 aircraft, designated authorities — including FAA DERs — would have been required signatories on the change order before release. The routing would have been automatic. The change could not have been closed without their documented review.

None of these controls are exotic. They are standard features of enterprise PLM change management configured for safety-critical use. The question is whether the configuration enforces them or merely permits them.

---

Visibility vs. Integrity: The Core Distinction

Most PLM deployments give engineers visibility into the change record. Engineers can see that a change was made, who approved it, and when it was released. This is not the same as integrity.

Integrity means the connections in the product record are complete and enforced. It means a change to a system parameter cannot be released without linked disposition of every downstream safety artifact. It means the system refuses to proceed — not just warns, but refuses — when traceability gaps exist. It means the certification baseline is a live artifact, not a snapshot taken at a point in time and then left to drift as the design evolves.

Boeing's engineering systems had visibility. Engineers could look up the MCAS change. What they lacked was a governance configuration that enforced completeness — that made it structurally impossible to release a safety-significant change without closing every downstream impact.

The distinction matters because most PLM implementations are configured for visibility by default. Enforcing integrity requires additional configuration: mandatory change classification rules, safety-criticality flags propagated through the bill of materials, impact assessment workflows tied to the hazard analysis, and sign-off routing that cannot be bypassed. These configurations exist in the tools. They are not installed out of the box, and they require deliberate decisions by the PLM program team to activate.

---

What This Means for PLM Deployments

For manufacturers operating in aerospace, automotive, or medical devices — any domain where a safety case is required for regulatory approval — the 737 MAX case establishes the minimum standard for change governance.

Configuration traceability is not optional. Every system parameter that appears in a certification basis, an FMEA, or a hazard analysis must be traceable in the PLM system to the design artifact that defines it. When that artifact changes, the trace must break visibly and require disposition.

Safety-critical classification must propagate through the BOM. A change classification system that does not know a component is safety-critical cannot route the change appropriately. Safety classifications must be maintained as first-class attributes of the bill of materials, not managed as tribal knowledge in engineering notebooks.

Mandatory change impact assessment workflows are a safety function. Organizations that allow engineers to close a change order without completing an impact assessment on linked requirements, analyses, and certification artifacts have not implemented change governance — they have implemented a change recording system. The difference is enforcement.

Service bulletins and configuration control must stay in sync. The production configuration and the as-certified configuration must remain linked throughout service. Post-certification modifications — including changes introduced through service bulletins and training documentation — must be managed through the same traceability discipline as the original design.

---

The AI Layer

The next layer of digital thread governance is not human auditors working through checklists. It is agentic systems that traverse the product record continuously and surface traceability gaps before they reach certification review.

An AI agent with access to the PLM graph can identify changes that lack linked rationale, requirements that lack linked test evidence, certification artifacts that reference superseded design documents, and FMEA entries that reference parameter values that have since been modified. It can do this across a product record that spans hundreds of thousands of items — a scale no human audit team can match.

Critically, the agent is not making safety decisions. It is identifying the gaps that existing governance rules say should not exist. The engineering judgment still belongs to the engineer. The agent's function is to ensure that the engineer's attention is directed to the right places before a certification package is submitted — not after an accident investigation is opened.

This is not a future capability. Production-grade PLM systems with agentic AI layers that can traverse the change graph, query the safety case structure, and generate traceability gap reports exist today. The question is whether safety-critical manufacturers are deploying them — or are still managing certification traceability the same way Boeing managed MCAS.

---

A Pointed Closing

Three hundred and forty-six people are dead. The investigation record is public. The engineering failure is documented. The PLM and certification governance failures that enabled it are understood.

"Good enough" PLM governance in a safety-critical context is a configuration that makes it structurally impossible to release a safety-significant change without closing every downstream certification impact. Anything less than that is not governance — it is record-keeping with good intentions. The 737 MAX demonstrates, at the cost of 346 lives, that record-keeping is not sufficient.