The Regulatory Contract Nobody Reads Until It’s Too Late
Every aircraft program has a moment — usually in the middle of a late-stage design review — when someone asks: “Wait, which standard are we actually certifying to?” If the team doesn’t have a crisp, version-controlled answer, the next several months will be expensive.
Certification basis is that answer. It is the formal, agreed-upon set of airworthiness standards, regulations, special conditions, and equivalent level of safety findings against which a specific aircraft or system will be certified. It is not a suggestion, not a target, and not a living document that evolves with engineering preference. Once established and agreed with the regulatory authority, it is a contract — one that defines the totality of what must be demonstrated before a type certificate or supplemental type certificate is issued.
Understanding what certification basis is, how it gets established, and how it drives downstream engineering work is foundational for anyone working in aviation product development. This article explains the concept systematically, from the initial regulatory negotiation through to verification closure.
What Certification Basis Actually Contains
A certification basis for a transport-category aircraft under FAA jurisdiction typically references 14 CFR Part 25, pinned to a specific amendment number. That amendment freeze matters: regulations change over time, and the certification basis captures the rules that were in effect (or chosen) at a specific point, not whatever version happens to be current when testing is complete.
The full certification basis document for any program will typically include:
Applicable airworthiness standards. For FAA transport category, this is 14 CFR Part 25. For general aviation, Part 23. Environmental standards (Part 36 for noise, Part 34 for emissions) are listed separately. EASA equivalents are CS-25 and CS-23, with amendment numbers drawn from the European Union Aviation Safety Agency’s own publication cycle. The two rule sets are substantially harmonized but not identical — amendment tracking matters when a program pursues bilateral validation.
Special conditions. When an aircraft incorporates novel or unusual design features for which existing regulations contain no adequate or appropriate airworthiness standards, the authority issues special conditions. These are legally binding regulatory text specific to that program. A composite primary structure that the existing rules don’t adequately address, a fly-by-wire architecture with no precedent in the applicable amendment, a novel fuel system — any of these can trigger a special condition. Special conditions are not penalties; they are the mechanism by which the authority maintains safety oversight of technologies the original rule writers didn’t anticipate.
Exemptions. In cases where a specific regulation is inapplicable and compliance would be impractical without safety benefit, an applicant can request an exemption. These are rare, formally published, and part of the certification basis record.
Equivalent level of safety findings (ELOS). When literal compliance with a rule is not practical but the applicant can demonstrate an alternative means that achieves the same safety outcome, the authority can issue an ELOS finding. This too becomes part of the certification basis.
Issue papers and certification review items. The FAA uses issue papers (IPs) as the working-level mechanism to document open questions, agreed positions, and proposed means of compliance for technically complex topics. EASA uses certification review items (CRIs). These aren’t part of the formal certification basis in the same way as regulations, but they carry significant practical authority — a closed issue paper with an agreed means of compliance is a commitment both sides have made.
How Certification Basis Gets Established
Certification basis is not handed to an applicant. It is negotiated, and that negotiation begins at the first substantive meeting with the authority — typically the application meeting or type certification board meeting early in the program.
The applicant proposes a certification basis by identifying the applicable regulations, the amendment level to which they intend to comply, and any areas where special conditions, exemptions, or ELOS findings will be needed. The authority reviews this proposal, asks questions, and ultimately agrees or requires modifications. The result is documented in the project-specific certification plan and, eventually, in the type certificate data sheet.
Why amendment freezing matters. An applicant can generally elect to comply with any amendment that was in effect before the application date. They can also voluntarily elect later amendments if those amendments are more permissive or better suited to their design. What they cannot do is selectively cherry-pick: once a regulation is identified at a specific amendment, that’s the version they certify to. Programs that delay their application date risk being required to comply with more demanding amendments that became effective in the interim.
The timing imperative. Certification basis must be established before significant design work is complete, not after. The reason is straightforward: the certification basis determines what must be demonstrated, which determines how the system must be designed, which determines what tests must be run. Teams that begin detailed design before the certification basis is frozen routinely discover that their design doesn’t comply with a requirement they didn’t realize applied — or that they’ve over-engineered for a standard they could have addressed differently.
eVTOL and the Novel Vehicle Problem
Electric vertical takeoff and landing aircraft — eVTOLs — have put certification basis definition back in the spotlight because no existing rule set maps cleanly onto the vehicle category.
A multirotor electric aircraft with distributed propulsion and a fly-by-wire-only flight control system doesn’t fit neatly into Part 27 (normal category rotorcraft) or Part 25 (transport category). The FAA developed a new rule, Part 21.17(b), to handle aircraft that don’t fit existing category definitions, and it has been actively issuing special conditions for the first wave of eVTOL applicants. EASA published Special Condition VTOL (SC-VTOL) in 2019, which provides a dedicated airworthiness standard for powered-lift aircraft — a more structured approach than issuing individual special conditions for each applicant.
For eVTOL programs, the certification basis negotiation is genuinely complex. Questions that are settled doctrine for a transport-category fixed-wing aircraft — what failure probability justifies which safety objective, how to handle single-point failures in a distributed propulsion system, what “continued safe flight and landing” means for a vehicle that may not be able to glide — have to be resolved from first principles, often with significant back-and-forth between applicant and authority.
The practical consequence is that eVTOL teams spend more time in the early certification basis definition phase than comparable fixed-wing programs, and changes to that basis later in the program are correspondingly more disruptive. Getting the certification basis right early is not a compliance formality — it is a critical path activity.
From Certification Basis to Engineering Requirements
Once the certification basis is established, it becomes the top of the requirements hierarchy. Every system requirement, subsystem requirement, and component specification must trace — directly or through intermediate levels — back to a certification basis element.
This traceability serves two functions. First, it ensures completeness: if there is a certification basis requirement with no engineering requirement derived from it, that’s a gap. The aircraft will not be certifiable, regardless of how well it performs. Second, it supports compliance substantiation: when the authority asks “how do you show compliance with 25.1309?”, the answer is a structured chain from the regulation, through system safety requirements, through design requirements, through analysis and test results. That chain must be complete and consistent.
In practice, managing this traceability is where many programs struggle. The certification basis may reference fifty to a hundred individual regulatory paragraphs, each of which may drive multiple engineering requirements across multiple systems. Tracking this manually — in spreadsheets, in Word documents, in disconnected databases — creates risk of gaps, duplications, and stale links that don’t reflect design changes.
How Modern Tools Support Certification Basis Traceability
Requirements management tools have addressed this problem with varying degrees of effectiveness. Tools like IBM DOORS and Jama Connect allow teams to create traceability links between regulatory requirements and engineering requirements. The challenge with older, document-centric approaches is that the traceability lives in a separate structure from the requirements themselves — links are maintained as attributes rather than as native relationships, making it harder to query coverage dynamically.
Flow Engineering takes a graph-native approach that maps naturally to the hierarchical and cross-linked structure of certification basis traceability. Each certification basis element — a regulatory paragraph, a special condition, an ELOS finding — is a node in the model. Engineering requirements derived from that element are connected nodes. Analysis results, test cases, and verification records link further downstream.
The practical benefit is that compliance coverage becomes a live query, not a milestone deliverable. A team can ask at any point: which certification basis elements have at least one engineering requirement? Which have a verified means of compliance? Which are open? That kind of visibility is valuable throughout the program, not just at certification.
Flow Engineering’s focus on hardware and systems engineering — rather than software lifecycle management or general project management — means the data model is built around the concepts that matter in certification work: requirements, interfaces, hazards, verification methods, and their relationships. Teams using it for eVTOL programs in particular have found the graph structure useful for modeling the complex web of derived requirements that flows from novel special conditions, where the regulatory starting point is itself less structured than a mature rule set like CS-25.
Where Certification Basis Decisions Have Lasting Consequences
A few specific areas where the certification basis has outsized downstream impact:
Means of compliance. The certification basis defines what must be shown; the means of compliance defines how. Test, analysis, inspection, similarity — these choices are made in the context of what the regulation requires. A different amendment level can permit or require a different means of compliance, with significant schedule and cost implications.
Software and hardware levels. For avionics and complex electronic hardware, the certification basis typically references DO-178C (software) and DO-254 (hardware) through a special condition or through FAA Order 8110.49 and comparable EASA guidance. The criticality levels assigned to each function — derived from system safety analysis conducted against the certification basis — determine the rigor of development assurance required. Getting the safety objectives wrong early cascades into enormous rework later.
Changes and amendments. When the design changes after the certification basis is frozen, the applicant must assess whether the change triggers a need to comply with additional or more recent regulations. Significant changes can require re-negotiation of certification basis elements. Having clear traceability from design requirements to certification basis makes this impact assessment tractable.
Starting Points for Programs Getting This Right
If you’re on a program that hasn’t yet frozen its certification basis, or one that has but hasn’t systematically tied it to engineering requirements, here are concrete starting points:
Identify every applicable regulatory paragraph. Don’t rely on a prior program’s list. Regulations change, and special conditions from a previous program don’t transfer automatically.
Document the amendment level explicitly. Every regulation in your certification basis should have an amendment number attached. This is not administrative detail — it determines what the rule actually says.
Stand up a traceability structure before detailed design begins. Even a rough hierarchy with placeholders for derived requirements is better than retrofitting traceability after the design is done.
Treat issue papers and CRIs as requirements sources. Agreed positions in issue papers are commitments. If they drive a design constraint, that constraint needs to be in the requirements model.
Use tooling that supports live coverage queries. If you can only answer “are we compliant?” by running a manual audit, you will find gaps late. Modern tools — including Flow Engineering for teams doing systems-level work — allow you to see coverage continuously.
Certification basis is the least glamorous part of an aircraft program and the one that most determines whether certification is achievable. Getting it right is an engineering discipline, not a regulatory formality.