Textron Aviation and the Quiet Revolution in General Aviation Certification
How the shift from prescriptive to performance-based Part 23 rules is reshaping requirements engineering at a legacy OEM
Textron Aviation does not make headlines the way Boeing or Lockheed does. The company’s Cessna and Beechcraft brands occupy the less dramatic end of aerospace—piston trainers, turboprops, light jets, the King Air family that has outlasted every competitor that tried to kill it. But the engineering organization inside that Wichita facility is navigating a regulatory transition that is, in its own way, as consequential as anything happening in large transport aviation. And the tools and processes they inherited are not keeping pace.
The 2017 Rewrite: What Actually Changed
For most of its history, FAA Part 23—the regulation governing airworthiness certification for small aircraft—operated like a detailed instruction manual. Designers had specific stall speed limits, specific load factor requirements, specific test procedures. Compliance meant demonstrating you had followed the manual. Requirements engineers, by extension, had a relatively mechanical job: cite the applicable regulatory paragraph, document your test or analysis result, close the requirement.
The FAA’s 2017 restructuring of Part 23 changed this in a fundamental way. Driven by the recognition that prescriptive rules were freezing out innovation and making certification of modern avionics and composite structures unnecessarily expensive, the agency replaced the old granular ruleset with 31 high-level airworthiness standards. The details moved into industry consensus standards—primarily ASTM International documents—that the FAA accepts as means of compliance. Crucially, those consensus standards are not the only path. OEMs can propose alternative means of compliance and negotiate them with the FAA. The regulation now asks: does the aircraft meet the performance intent? How you get there is, within limits, your engineering problem to solve.
For the FAA, this was modernization. For an OEM like Textron Aviation, it was a quiet restructuring of the engineering organization’s core job description.
What This Means for Requirements Engineering Teams
Under the old Part 23, a requirements engineer at Textron could trace a design requirement to a specific regulatory paragraph with relative confidence. The paragraph existed, it said what it said, and the compliance method was either prescribed directly or negotiated from a short list of acceptable means. Requirements traceability was, in the engineering sense, a cleaner problem. Not simple—Cessna’s Mustang certification involved thousands of requirements—but structurally tractable.
Under the revised Part 23, the team now routinely does something different: they write their own means of compliance. When a program team determines that the applicable ASTM consensus standard does not fit their specific design—or when they are doing something novel enough that no accepted standard covers it—they must author a compliance document, negotiate it with their Aircraft Certification Office, and then trace requirements against their own authored standard rather than against a fixed regulatory text.
This is a more intellectually demanding form of requirements engineering. It requires the team to simultaneously understand design intent, regulatory intent, and verification approach, then document the relationship between all three in a way that will survive an FAA audit. The traceability artifact is no longer a simple table pointing at external text. It is a network of relationships: design requirement → means of compliance → verification evidence, where the middle term is itself a living document owned by the engineering organization.
The problem is that most requirements management tools in use at large OEMs were designed around the older model. They are good at storing requirements, linking them to source documents, and generating traceability matrices. They are less good at managing the situation where the source document is itself a work product of the same engineering team, subject to revision, and connected bidirectionally to the design.
Textron’s Position: Heritage as Asset and Constraint
Textron Aviation is not a startup. The engineering organization in Wichita carries certification data packages stretching back decades. The King Air 350 has been in continuous production since 1988. The Cessna 172—still the most produced aircraft in history—has FAA type certificate data that the company must maintain, update, and protect across every derivative variant. That institutional knowledge is genuinely valuable; it represents an accumulated understanding of how the FAA thinks, what arguments hold up under audit, and which engineering shortcuts tend to produce problems later.
But institutional heritage in aerospace tends to calcify around the tools that existed when the institution was formed. Requirements management systems implemented in the 1990s or early 2000s were designed for a world of fixed regulatory text, linear waterfall development, and document-centric audit trails. The data structures those systems impose—hierarchical requirement decomposition, manual linking, snapshot-based baselines—made sense when the job was filing a compliance checklist against a fixed regulatory paragraph.
They fit less well when the engineering team is:
- Authoring consensus documents in parallel with design work
- Managing requirements against standards that themselves have version histories and competing interpretations
- Dealing with avionics software governed by DO-178C alongside structural requirements governed by ASTM consensus standards alongside human factors requirements with their own means of compliance discussion
- Reusing certification data from previous programs while tracking where that data is and is not applicable to the new design configuration
This is not a criticism unique to Textron. It describes the structural position of any large traditional OEM attempting to modernize under a regulatory framework that has become, by design, more complex to navigate even as it became more flexible.
The Modernization Tension
The most useful way to understand Textron’s engineering challenge is as a tension between two legitimate engineering values: continuity and capability.
Continuity is not simply organizational inertia. Certification heritage has real value. An aircraft type certificate is a legal instrument that represents thousands of hours of engineering analysis, testing, and FAA negotiation. The traceability artifacts that support it—the compliance checklists, the test reports, the type inspection reports—must be maintained accurately for the life of the aircraft. A modernization effort that breaks the chain of custody on that data creates certification risk, which is existential risk for an aviation OEM.
Capability is what the revised Part 23 now demands. Teams need to author their own standards, manage bidirectional traceability in complex networks rather than simple hierarchies, track the status of compliance negotiations with the FAA as a live process rather than a completed paperwork exercise, and reuse prior certification data intelligently rather than copying and pasting from previous programs and hoping nothing was missed.
The tools that maximize continuity—mature, auditable, familiar to the FAA—tend to be the same tools that limit capability. The tools that offer the capability—graph-based modeling, AI-assisted traceability, modern SaaS architectures—tend to be newer, less proven in certification environments, and harder to justify to a certification authority that has seen your current toolchain for twenty years.
This is the real modernization problem. It is not primarily a technology selection problem. It is a risk allocation problem.
What Modern Tooling Can Actually Offer
The practical implications of the Part 23 revision—authoring your own means of compliance, managing bidirectional traceability, reusing prior certification artifacts intelligently—point toward tooling capabilities that document-based systems were not built to provide.
Graph-based requirements models, where requirements, verification activities, design elements, and compliance documents exist as nodes in a connected network rather than rows in a table or sections in a Word document, handle the new certification reality better structurally. When a means of compliance document is revised, a graph-based system can surface every requirement, test case, and design element that touches it. A document-based system requires manual audit of every artifact that might have cited the changed document.
AI-native traceability—where the system can suggest links between requirements and compliance artifacts, flag gaps in coverage, and identify when a change in one part of the network likely propagates to another—addresses the volume problem that the Part 23 revision created. Writing your own means of compliance generates more requirements engineering artifacts, not fewer. Teams need help managing the surface area.
Tools like Flow Engineering, built specifically for hardware and systems engineering teams working in graph-based models, represent what the architecture for this problem space looks like when you design for it from the start rather than adapt a document management system to cover it. They are not designed primarily for FAA Part 23 specifically, but the structural match between what modern certification requires—connected traceability, AI-assisted coverage analysis, bidirectional linking between requirements and evidence—and what graph-native systems provide is better than the structural match with legacy RTM tools.
The gap for an OEM like Textron is that adopting tools like this requires validating them in a certification context, demonstrating to an ACO that the tool outputs are trustworthy, and managing the transition of existing certification data without breaking the audit trail. That is non-trivial work, and it is work that startup tool vendors do not always understand how deep it runs.
An Honest Assessment
Textron Aviation is neither the most advanced engineering organization in aerospace nor the most behind. They are doing something genuinely difficult: maintaining clean certification data on programs that have been in production for decades, while absorbing a regulatory change that requires a more sophisticated form of requirements engineering than the tools they inherited were built to support.
The 2017 Part 23 revision was the right policy decision. Performance-based standards are better engineering philosophy than prescriptive checklists, they enable genuine innovation, and they have already enabled new entrants and novel designs that the old framework would have strangled. But they transferred work from the FAA to the OEM, and specifically they transferred requirements authoring work from the regulatory text to the engineering organization. That transfer happened faster than tooling and processes at large traditional OEMs could adapt.
The question for Textron—and for every traditional OEM in Part 23 airspace—is whether modernization of engineering tooling gets treated as a certification risk to be minimized or as a capability investment that reduces long-term compliance cost and program risk. Organizations that treat it as the former will find themselves managing increasingly complex compliance obligations with tools designed for a simpler regulatory environment. Organizations that treat it as the latter will face real near-term friction but will be better positioned as the gap between what modern certification requires and what legacy tooling delivers continues to widen.
The King Air has been updated continuously for nearly forty years because the engineering organization understood that the value of the platform depends on the capability of the team that maintains it. The same logic applies to the tools that team uses.