What evidence is needed to support aircraft certification?

Aircraft certification is supported not by a single test report or a completed checklist, but by a connected body of objective evidence showing that a defined aircraft configuration complies with its certification basis. The decisive question is whether every applicable requirement can be traced to an approved design feature, a stated means of compliance, verified results, and a controlled record. A successful certification case therefore has to demonstrate both technical compliance and confidence in the process used to establish that compliance.

For a transport-category aircraft, a new propulsion installation, a major avionics change, or an emerging eVTOL configuration, the evidence set will differ in scale and emphasis. The underlying logic remains consistent: the applicant must show that the design is safe for its intended operation, that the aircraft performs as claimed, that failures have been addressed at the required level of rigor, and that the approved design can be manufactured and maintained without losing its airworthiness characteristics.

The certification basis defines what must be proved

Evidence has little value until it is tied to the correct certification basis. In the United States, type certification is generally administered under FAA Part 21, against the applicable airworthiness standards such as 14 CFR Part 23, 25, 27, 29, 33, or 35. In Europe, EASA certification follows the framework of Regulation (EU) 2018/1139 and its implementing rules, with Certification Specifications such as CS-23, CS-25, CS-27, and CS-29 serving as the technical baseline.

The certification basis is more than a list of regulations. It normally includes the applicable amendment levels, special conditions for novel or unusual features, equivalent level of safety findings where literal compliance is not practical, exemptions where granted, and environmental requirements. Noise and emissions requirements may be governed separately from airworthiness rules, but they still form part of the approval pathway for an aircraft intended for operational entry.

A certification programme should establish this baseline early. If the applicant applies an incorrect rule amendment, treats an installed system as outside the aircraft-level scope, or overlooks a special condition, later test success may not resolve the underlying approval gap. The first useful artifact is therefore a controlled certification basis document, with each requirement uniquely identified and assigned to the affected design area.

A distinction is also needed between a type certification programme and other approval routes. A supplemental type certificate (STC) must demonstrate that a major change complies with the applicable requirements and does not adversely affect previously approved areas. A production approval establishes the ability to manufacture conforming products; it does not replace design approval. Validation by a foreign authority may rely partly on the primary authority’s findings, but it introduces additional requirements, validation items, and documentation expectations.

Compliance planning converts regulations into an evidence strategy

Regulatory text rarely specifies one universal method for proving compliance. A structural requirement may be addressed through analysis supported by test; a systems safety requirement may require functional hazard assessment, architecture evidence, and verification records; an operational limitation may be established by flight test and documented in the aircraft flight manual. The applicant must translate each rule into a credible, agreed means of compliance.

The central control document is often a certification plan or certification programme. Its value lies in making the logic visible before verification is complete. At a minimum, it should link:

• each applicable requirement to a compliance statement;
• the selected means of compliance, such as analysis, inspection, similarity, ground test, flight test, or a combination;
• the design configuration and assumptions being evaluated;
• the responsible engineering discipline and approval authority interface;
• the planned compliance artifact, review status, and closure criteria.

“Compliance by similarity” deserves particular scrutiny. It is valid only when the applicant can demonstrate that the new design is sufficiently equivalent to the previously substantiated design in relevant loads, materials, geometry, environment, system architecture, operating conditions, and failure effects. Similarity is not a shortcut based on shared product lineage. A changed battery enclosure, cooling path, software revision, composite lay-up, or mounting arrangement may invalidate the comparison for a particular requirement.

Certification authorities may publish advisory material, acceptable means of compliance, policy memoranda, issue papers, or certification review items to clarify expectations. These documents help define an acceptable path, but the actual compliance argument must remain specific to the design. Treating generic guidance as evidence is a common weakness: guidance explains how evidence may be developed; it is not evidence that the aircraft meets the rule.

Design data must establish a stable, reviewable configuration

Certification findings depend on knowing precisely what has been evaluated. Drawings, specifications, material definitions, interface control documents, wiring data, software and hardware identification, equipment lists, and approved limitations collectively define the type design. If the tested configuration cannot be shown to match the final proposed configuration, test results may be unusable or require a formal delta assessment.

Configuration control is especially important where the development process contains rapid iterations. A test article may incorporate temporary instrumentation, non-production fasteners, a preliminary flight-control law, or a structural repair. None of these conditions automatically disqualifies the test, but each discrepancy must be recorded, assessed, and closed. The certification file needs a defensible answer to a basic question: what configuration was tested, and why does that result apply to the configuration submitted for approval?

For complex systems, interface definition is often where compliance evidence breaks down. An avionics unit can satisfy its own equipment qualification requirements while still creating aircraft-level integration risks through power quality, data latency, electromagnetic coupling, alerting logic, or installation-specific cooling. The aircraft certification case must account for those integration effects rather than relying solely on supplier declarations.

Analysis is evidence only when its assumptions are controlled and validated

Aircraft certification relies heavily on analytical substantiation. Finite element models support structural strength and aeroelastic assessments. Computational fluid dynamics may inform aerodynamic loads and cooling analyses. Reliability models, fault trees, common-cause analyses, and thermal models can support system safety and equipment qualification. Analytical evidence is acceptable when its method, inputs, assumptions, boundary conditions, margins, and validation status are adequate for the decision being made.

The critical issue is model credibility. A structural model that has not been correlated with representative test data may be useful for development decisions but insufficient as the sole basis for a final compliance finding. Likewise, a battery thermal-propagation analysis must be supported by representative cell, module, and installation evidence if it is used to demonstrate protection against hazardous effects.

Margins require equally careful treatment. A report should not merely state that calculated stress is below an allowable value. It should identify the source and pedigree of the allowable, manufacturing and environmental knockdowns, load factors, uncertainty treatment, fatigue spectrum assumptions, and the configuration to which the calculation applies. In composite structures, evidence frequently has to address material and process variability, damage tolerance, environmental conditioning, bonded-joint behavior, and inspection capability—not simply static ultimate strength.

Ground and flight tests must be representative, conforming, and traceable

Testing is often the most visible form of certification evidence, but a test result alone does not establish compliance. The authority and the applicant need confidence that the article was representative, the instrumentation was suitable, the procedure covered the required conditions, and the data reduction was controlled.

A complete test package commonly includes the approved or accepted test plan, configuration record, conformity documentation, instrumentation calibration information, test procedure, raw data, processed data, anomaly records, deviations, photographs or inspection records where relevant, and a final report linking the outcome directly to the applicable requirement.

Conformity is a separate but essential concept. Before a certification test, the test article, parts, software load, and installation must be shown to conform to the design data applicable to that test. A nonconformity does not always prevent testing, but it must be evaluated and accepted through the appropriate process. Without conformity control, the test may demonstrate only the behavior of an unapproved prototype.

Flight testing provides evidence for handling qualities, performance, flight characteristics, systems operation, operational limitations, and certain failure conditions. It cannot safely or practically cover every scenario. Certification therefore uses flight test alongside analysis, simulation, rig testing, and system safety assessment. A hazardous failure condition is not normally “proven safe” by intentionally creating it in flight; the required evidence is developed through a combination of architecture, development assurance, failure analysis, and controlled verification.

System safety evidence connects failures to design assurance

For aircraft with integrated electrical, electronic, and software-intensive functions, the safety case must demonstrate more than component reliability. It must show how failures affect the aircraft and how the design prevents or mitigates unacceptable outcomes.

Industry practice commonly uses processes aligned with SAE ARP4754A for aircraft and systems development and SAE ARP4761A for safety assessment methods. Typical artifacts include a Functional Hazard Assessment (FHA), Preliminary System Safety Assessment (PSSA), System Safety Assessment (SSA), Fault Tree Analysis (FTA), Failure Modes and Effects Analysis (FMEA), common-cause analysis, zonal safety analysis, and particular risks analysis. The exact artifact set depends on the certification basis and system architecture, but the chain of reasoning is fundamental.

The FHA classifies the consequences of functional failures. That classification drives the required probability objectives and development assurance rigor. The PSSA then demonstrates that the proposed architecture can meet those objectives, including independence, redundancy, monitoring, segregation, and latent-failure controls. The final SSA uses verified implementation evidence to show that the delivered design meets the approved safety objectives.

A recurring evaluation problem is the gap between a safety assessment and the actual implementation. A fault tree may assume independent power sources, but shared routing, common cooling, common software, or a common data concentrator can defeat that independence. The evidence must reach down to installation drawings, wiring segregation, software partitioning, maintenance tasks, and physical system interfaces.

Software, airborne electronic hardware, and environmental qualification require disciplined evidence

Software used in airborne systems is generally substantiated through a lifecycle assurance process. RTCA DO-178C is widely used as an accepted framework for airborne software considerations, while RTCA DO-254 is commonly used for complex airborne electronic hardware. Their applicability and acceptance depend on the certification authority and project context, but both illustrate an important principle: compliance is demonstrated through process evidence, traceability, verification independence where required, configuration management, and problem reporting—not by a final executable file alone.

For software, the evidence trail generally connects system requirements to high-level and low-level software requirements, source code, verification cases, test results, coverage objectives where applicable, change control, and the software configuration index. Unresolved anomalies must be assessed against the intended function and safety classification. A statement that software “passed testing” is inadequate without visibility into requirements coverage, test completeness, and the status of known defects.

Environmental qualification of airborne equipment is frequently organized using RTCA DO-160. Relevant test categories may include temperature, altitude, vibration, shock, power input, radio-frequency susceptibility, lightning-induced transients, and electromagnetic emissions. DO-160 test reports are valuable equipment-level evidence, but they do not by themselves establish safe aircraft installation. Installation-specific electromagnetic compatibility, cooling, mounting, cable routing, and exposure conditions must still be substantiated.

Manufacturing evidence proves that the approved design can be reproduced

Type design compliance and production conformity are closely related. A certification test may establish the strength of a component, yet that result has limited continuing value if serial production cannot control the material, process, inspection, and configuration characteristics that supported the test.

Production approval evidence addresses quality-system capability, supplier control, traceability, nonconformance management, inspection planning, calibration, process qualification, and configuration control. In the FAA system, production approvals may take forms including a production certificate, approved production inspection system, or other applicable approval arrangements under Part 21. EASA Part 21 similarly provides a framework for production organisations and their responsibilities.

Special processes require particular attention because their quality may not be fully verified by final inspection. Heat treatment, welding, bonding, composite curing, plating, and certain additive manufacturing processes need qualified procedures, controlled parameters, material traceability, operator qualification where applicable, and evidence that process variation remains within substantiated limits. A design is not fully certifiable in practice if its essential characteristics depend on an uncontrolled production process.

Continued airworthiness documents are part of the safety evidence

Certification does not end at first delivery. The applicant must provide the instructions and limitations needed to preserve airworthiness in service. These can include the aircraft flight manual or operating limitations, Instructions for Continued Airworthiness (ICA), maintenance manuals, airworthiness limitations, inspection intervals, wiring practices, repair data, and component life limits.

These documents are not administrative appendices. They often contain the operational assumptions on which the compliance finding depends. If structural fatigue substantiation assumes periodic inspection, that inspection task and interval must be captured in the airworthiness limitations. If a system safety conclusion assumes a dispatch restriction, maintenance check, or crew procedure, the relevant operational or maintenance documentation must express it accurately and unambiguously.

The most robust aircraft certification submissions are therefore built as a traceable argument rather than a collection of engineering outputs. Each requirement should lead to a defined design feature, a justified means of compliance, representative verification evidence, identified assumptions and limitations, and controlled documentation for production and service. Where one link is weak—an unrepresentative test article, an unvalidated model, an uncontrolled software change, or an omitted maintenance limitation—the certification risk is not isolated. It can undermine the credibility of the compliance case as a whole.