By Bjorn Fehrm and Henry Tam

December 19, 2025, ©. Leeham News: We do a series about ideas on how the long development times for large airliners can be shortened. New projects talk about cutting development time and reaching certification and production faster than previous projects.

The series will discuss the typical development cycles for an FAA Part 25 aircraft, called a transport category aircraft, and what different ideas there are to reduce the development times.

We will use the Gantt plan in Figure 1 as a base for our discussions. We have concluded the articles about flight tests with the aircraft. Now we revisit the Certification subject and look at how we can show compliance with requirements and work our way to a Type Certificate. We are at the end part of the Testing and Certification phase in our Program Plan in Figure 1.

Figure 1. A generic new Part 25 airliner development plan. Source: Leeham Co. Click to see better.

      ** Special thanks to Andrew Telesca for helping with this article **

Certification Implementation

In the last few articles, we’ve shared information on a variety of activities and the associated controls required during the certification project’s implementation phase. This is where the rubber meets the road in showing the regulator(s) – with data – that your design does everything it’s supposed to do, and nothing that it’s not.

If you’ve structured everything in your plans well, resourced appropriately, your suppliers are delivering on time, and you’ve designed for compliance, this phase is all about efficient execution. If not, it’s a nightmare of change control, regression testing, and delays (see: Boeing 777X). The FAA always models it as the longest part of a certification project, Figure 2.

Figure 2. The typical Certification Process. Source: FAA Order 8110.4C.

Substantiating, Showing, and Finding Compliance

Whether prototype testing, stress analysis, flight testing, or any of the other previously agreed activities needed to satisfy a regulation, each activity requires three distinct efforts to be considered closed:

• Substantiating Compliance – i.e., data. Data must be created/collected in a controlled manner representative of the design and its use. Examples of substantiating compliance include: conducting environmental qualification testing to show equipment will operate as intended in its installed environment; performing finite element analysis to ensure parts have a sufficient strength margin for their limit and ultimate loads; or conducting a multi-use human factors evaluation of the flight deck controls to ensure their operation is clear and the pilot workload is acceptable.
• Showing Compliance – i.e., reports. Terabytes of data will be created in this phase, and neither the regulator nor their delegates can (or want to) look at all of it. When the applicant shows compliance, they collate the relevant regulations, design data, and substantiating data together into reports that show the regulatory compliance of the type design with the airworthiness regulations. Examples of showing compliance include: Test reports, design assurance records, system safety assessments, and compliance summaries.
• Finding Compliance – i.e., approvals. Typically documented in a specific manner or form specified by the regulator, each showing of compliance must be approved by an authorized individual before it is considered complete. In the end, this will be captured in a compliance matrix or checklist showing, for each regulation and each aspect of the design, how compliance was found.

Substantiating and showing compliance are our responsibility as the applicant. Finding compliance is the responsibility of the regulator and their delegates. Clear communication and coordination between the two parties is essential to avoid delays.

The type certificate cannot be granted until all required findings are completed. As a result, a significant amount of time is spent during this phase conducting meetings between the regulator and the applicant to explain and answer questions about the compliance showings to support approval. If regulators are short-staffed (they usually are), this can be a very slow process.

Change Management

Each individual activity that is required in this phase can be challenging – the last few articles provide examples of the types and depth of investigation (and associated controls) that are required to substantiate the design.

If we consider that a new aircraft development requires many thousands of such activities to support, resulting in tens of thousands of compliance findings, the complexity of our endeavor comes into view, and with it a fundamental challenge – change management.

As noted previously, the implementation phase is typically long, spanning a couple of years at a minimum. Even if I complete some compliance activities successfully early, what happens when the substantiation of another regulation uncovers an issue, and a design needs to change? Let’s look at a hypothetical example:

You’ve completed 50%+ of your prototype testing. You’ve built your first flight test aircraft and you’ve started to explore the intended service envelope (altitudes, speeds, etc.). Then you have a discovery. You calibrate your air data system and find that, under certain combinations of aircraft orientation, speed, and altitude, the readings are unreliable. After conducting a painful root cause analysis, you have no choice but to move the pitot-static tube. That’s an easy change – you identify a new location, the structural modification is not hard, nor is the updated stress analysis. Except…

The new location requires that you reroute the connection to the pressure transducer, displacing a wire harness. Simple enough to move, except the only place it can go is too close to the harness that includes wiring for a redundant essential system, so due to system separation regulations, that wire in the harness will have to be separated and routed differently.

This results in the redesign of multiple harnesses, updated drawing approvals, and a repeat of multiple analyses. Additionally, the required change impact analysis of those design changes reveals that the harness redesign may have an EMI impact, so the associated testing needs to be repeated and the reports resubmitted for new compliance findings.

Moreover, further testing reveals the new location gives slightly different readings than the old location. This means changes to software parameters, which means changes to software requirements for which the validation and verification have already been completed by the supplier, so new software reviews must be conducted for the new software build. An additional change impact analysis is of course done for any other testing already conducted with the previous software build that may now need to be repeated. Of course, each of these changes that impacted a previous compliance finding must be coordinated with the regulator.

While hypothetical, this example shows the reality of modern aircraft development – each time a change is made during the implementation phase the impacts on today’s highly integrated and coupled design must be assessed. In order to complete the compliance matrix with only correct and applicable compliance findings, we need to ensure that all data is representative of the final type design being presented for certification.

As a result, late changes can not only have ballooning impacts on design, but also on the reams and reams of paperwork that have already been completed. Tracking and controlling these changes is one of the largest challenges of the implementation phase.

Type Inspection Authorization (TIA)

One of the few major milestones in this phase that companies often report publicly (at least in the USA) is TIA – the FAA’s authorization for their personnel to get on board the aircraft and begin conducting FAA flight tests.

This is granted after a completed aircraft is presented to the FAA with data showing it is (a) safe enough for FAA personnel to get on board, and (b) sufficiently mature that compliance findings made will be representative of the final production product because the risk of further change is low.

This second part is to reduce the risk of change management mistakes causing missed compliance findings, as well as to preserve regulatory resources so they don’t have to fly the same test points multiple times.

Showing these conditions are met requires the presentation of company flight testing results, as well as a significant amount of equipment, structural testing, and analysis data. It also requires the completion of many software audits, as today’s aircraft software is often the last part of the product to mature. This is typically the last major milestone prior to the granting of the type certificate.

Receiving the Type Certificate

By now, our hybrid aircraft program has pretty much completed the Type Design. We have released a complete set of drawings and specifications along with the required datasets. We can now push forward to obtain the Type Certificate by closing out the Type Certification Board Meeting. In order to close out the Type Certification Board Meeting with the FAA and receive the Type Certificate, all the data comprising the Type Certification must have been presented and compliance found in all areas. Beyond the types of testing and analysis discussed, this also means we need to finalize, based on that data, the allowed usage and limitations of the aircraft’s operation, Figure 3.

Figure 3. Required data for the Type certificate. Source: FAA Order 8110.120.

These airworthiness and operational limitations are captured in documents such as the Type Certificate Data Sheet, Aircraft Flight Manual, and Instructions for Continued Airworthiness:

• Type Certificate Data Sheet (TCDS) – A publicly released summary of the type certificate supporting product use and modification. It summarizes the key configuration and operational limitations (number of passengers, max takeoff weight, compatible engines, etc.), the regulations that the product is certified to, and often provides a reference to applicable documents where more information can be found.
• Aircraft Flight Manual (AFM) [25.1581] – Guidance on how to operate the aircraft (including in emergency situations) and additional details on the operational limits beyond what’s in the TCDS.
• Instructions for Continued Airworthiness (ICA) [25.1529] – Maintenance and installation procedures, including required maintenance intervals for Certification Maintenance Requirements and Life Limited Parts where, if the activities are not conducted as scheduled, the aircraft may no longer be airworthy.

Only after these documents are presented for review by the applicant, along with the final version of the Type Design (drawings and specifications) and the compliance matrix (showing all the compliance showings and findings made) can the Type Certificate be granted. Additionally, as the applicant, we must submit a positive statement under 21.20 confirming that the product complies with all applicable regulations. It is both our responsibility and liability to present only a safe, compliant product for certification.

Considerations for Speeding Up

While the earlier phases of the project benefit from a balance of speed and caution to avoid committing resources to a bad design, the implementation phase is all about speed. The design is already set, the plans are in place, so how can we progress through the verification and reporting as quickly as possible?

• Discipline in Execution – strong KPIs and avoidance of interim milestone traps
  • With such a large number of simultaneous substantiation activities being conducted, it’s difficult as a leader to see the big picture of whether progress is being made. Instead, it’s easy to get focused on near-term milestones and fighting fires. This leads to short-sighted decision making as compromises are made to hit those targets, even if it pushes other work to the right and increases the total quantity of work that must be accomplished, for example, by releasing incomplete parts onto an aircraft to support Power On, only to have to remove and replace those parts with finalized ones to support first flight or TIA. Key Performance Indicators designed to show the entirety of the work necessary for completion can help here as they drive awareness of the total program impact of decisions.
• Change Control Replaces Scope Control
  • In earlier phases, we discussed the importance of scope control – not letting the design effort get out of hand and create additional work for the program. In this phase, it’s about change control – any time a change is proposed, it must be challenged due to the complexity and knock-on effects described above. Something may not be working as it ideally should – but if it’s still certifiable and the customers won’t groan too loudly, maybe it can be the subject of a product improvement after entry into service.
• Templating
  • While there are many thousands of activities in this phase, quite a few of them are similar. Strong templates and checklists can improve work consistency, reduce errors, and streamline regulatory review processes. Moreover, if data is collected consistently with a consistent targeted output format, it becomes a potential opportunity for the use of automation or AI.
• Data Quality Pre-TIA vs. Phase TIA
  • A big question in this phase is when to get the official regulator feedback on the flight characteristics of the aircraft. If I work to mature the bare-minimum design to the point it’s safe and mature, I can get the regulator on board for early assessments and reduce the risk of discovering a non-compliance. This approach is often referred to in the US as a “Phased TIA”. However, this conflicts with the cautions above about interim milestones and change management – trying to move forward with compliance finding on this minimum viable prototype will likely result in an increased total work statement as we repeat activities after future discoveries are made. One opportunity here is high-fidelity simulation. Spending time and money to have the right equipment and data in a simulator can not only reduce the total number of flight test hours required, but allow earlier derisking at a lower cost and with less distraction than interim flight test builds.