Ask an engineering team when their aircraft program was hardest and most of them will point to the same window: late detailed design, somewhere between critical design review and first article. The configuration is largely frozen. Most of the engineering hours are already spent. And that is precisely when the certification problems surface.
That timing is not bad luck. It is a structural feature of how most programs are run, and it is the single most expensive habit in the industry.
Certification difficulty should peak at the opposite end of the program — during planning, while requirements are still being decomposed to systems and items, while the architecture is still negotiable, and while a design decision can be revisited for the cost of an afternoon rather than a retooling. Most programs have this exactly backwards.
What the inversion actually looks like
It rarely announces itself. It looks like a series of individually reasonable decisions.
The certification basis is treated as an administrative task to be completed once engineering has settled the configuration — because how can you establish applicability before you know what you are building? Means of compliance are deferred because the team would rather choose a method once the design is stable. Conformity planning waits, because there is nothing yet to conform. Each of these has a defensible logic. Together they guarantee that every certification question arrives after the answer has become expensive.
Then the questions arrive all at once. A requirement turns out to apply that nobody had scoped. A novel feature of the architecture does not fit the plain text of the rule and needs a special condition, which needs a technical argument, which needs data the program was not planning to generate. An analysis that was going to close a requirement turns out to rest on an assumption the authority does not accept. A part that was built to a drawing was not built under conformity, so the test run on it does not count.
None of these are engineering failures. Every one of them is a sequencing failure.
Why the sequence gets inverted
It is worth being fair about the reasons, because they are not stupid ones.
- Early in a program, certification work feels speculative. Committing to a certification basis before the design is settled looks like guessing.
- Certification staffing usually ramps late, because that is when the visible deliverables are due. The people who would have front-loaded the work are not in the room yet.
- Planning artifacts are hard to demonstrate progress with. A certification plan does not fly. A wind tunnel model does.
- And the cost of getting it wrong is deferred, which means it is invisible at the moment the decision is made.
That last point is the crux. The decision to defer certification thinking is made by people who will not personally absorb the consequence, at a time when the consequence cannot yet be measured.
What front-loading actually means
It does not mean writing a finished certification plan on day one. It means resolving the questions whose answers constrain the design, before the design forecloses them. Concretely:
- Establish the certification basis early, and treat it as provisional. You will not get it perfectly right. You will get it approximately right, which is enough to reveal which requirements will drive architecture.
- Identify where the design will not fit the rule. Novel configurations, new propulsion architectures, and highly integrated systems routinely land outside the plain text. Special conditions, equivalent level of safety findings, and exemptions all exist for exactly this — but each one is a negotiation with a lead time, and lead time is only cheap if you start early.
- Choose means of compliance for what they will cost to execute. A method that looks efficient on paper can be ruinous in practice. A similarity argument that will not survive scrutiny costs more than the test it was meant to avoid.
- Know your conformity requirements before hardware exists. The cheapest conformity plan is the one written before the first part is cut. The most expensive one is written after a test article has already been built.
- Decompose requirements far enough to see the assurance implications. The design assurance level of a system is not a preference. It falls out of the safety assessment, and it determines a development cost that has to be budgeted before the software and hardware teams start.
The objection, and what it is worth
The strongest argument against front-loading is that early certification work is partly wasted. Requirements churn. Architectures change. A certification basis established at concept will be revised, possibly several times, and some of the analysis done against the early configuration will be thrown away.
That is true, and it should be said plainly. Front-loading does have a real cost, and anyone who tells you otherwise is selling something.
But the comparison is not between wasted early work and no wasted work. It is between wasted early work and wasted late work. Early certification analysis is cheap to redo: it is a document, a matrix, a position. Late certification discovery is expensive to redo: it is hardware, tooling, a test campaign, a schedule slip, and sometimes a redesign. The question is not whether you will absorb rework. It is which kind you would rather absorb.
There is also a second-order benefit that is easy to miss. A program that has thought seriously about certification early tends to make better architectural decisions, because certifiability becomes one of the design constraints rather than a downstream tax. Engineering teams are good at optimizing against constraints they can see.
Why this matters commercially
An aviation concept is only as viable as what can be designed, manufactured, and maintained in a safe and certifiable form. However good the technology, if an air system is intended to carry people or fly over places where people live, it has to be certifiable — or there is no product to sell.
That makes certification a business constraint, not an engineering afterthought. And business constraints belong in the planning phase, alongside cost and schedule and weight, where they can shape the design instead of punishing it.
Certification will be difficult. That is not the problem, and it is not a problem worth trying to solve. The problem is difficulty arriving at the moment when the program has the least ability to respond to it.
Move the difficulty earlier, and it stops being a threat to the schedule and starts being an input to the design.