Certification Has a Clarity Problem, Not a Paperwork Problem

Certification work is often described as a paperwork problem.

There are too many forms. Too many matrices. Too many evidence items to assemble. Too many versions of too many documents, each one carrying a slightly different view of the aircraft, the organization, the means of compliance, or the safety argument.

This may sound like a documents problem. But it's a clarity problem.

Regulators typically want to know:

• What changed?
• Which assumption did this depend on?
• Which evidence supports this claim?
• Who accepted this interpretation?
• Is that acceptance still valid after the design moved?
• Where does a human decision still need to be made?

You can't get better answers to questions like these by having "better documents". What you need is clarity about the system that you are building. And once you have clarity, you'll also get better documents.

Documents are necessary, but they are not enough

Traditionally, certification authorities review evidence through documents. But increasingly, that review surface also includes models.

For example:

• The FAA's software assurance guidance, for example, recognizes RTCA DO-331 / EUROCAE ED-218, the model-based development and verification supplement to DO-178C / ED-12C, as part of an acceptable means of compliance for airborne software.
• NASA's MBSE guidance describes MBSE (model-based systems engineering) as the use of modeling to support requirements, design, analysis, verification, and validation across the lifecycle. The direction of travel is clear: documents still matter, but the thing being reviewed is often a document set plus the models, traces, assumptions, simulations, and generated views behind it.

But a document set is not the same thing as the engineering argument. Rather, the argument lives across the documents. It lives in the trace from regulation to means of compliance, from means of compliance to evidence, from evidence to design state, from design state to assumptions, and from assumptions to accepted engineering judgment.

A program can have all the artifacts and still struggle to answer a basic review question. For example:

• The requirement exists, but the rationale is buried.
• The test report exists, but it was written against an earlier configuration.
• The compliance matrix says an item is closed, but the authority interpretation that made it acceptable is sitting in an email thread three folders away.

That's why "AI helps you write certification documents" won't work. "Better texts" won't help you if the reasoning that connects the texts is still hard to inspect.

The real unit is the decision package

A decision package is the smallest reviewable bundle of context needed for a qualified person to make, reject, or defer a certification judgment.

A useful certification workflow is organized around decisions:

For a given compliance question, an engineer needs a package that shows the regulation, the proposed means of compliance, the relevant precedent, the affected artifacts, the current evidence, the open assumptions, the owner, and the specific decision being requested.

The decision package might later become a section of a document. It might update a compliance matrix. It might trigger a test request or a design question. But the point is not to have "better documents", but to give the responsible engineer a clear review surface.

The engineer can ask: does this match my judgment?

If yes, the decision can be recorded with its rationale and source support. If no, the system has surfaced the place where expert judgment matters.

This is especially important in novel or derivative programs, where the literal text of a rule may not map cleanly onto the architecture in front of the team. In such scenarios, the hard work isn't finding the rule, but explaining how the design satisfies the intent of the rule.

Clarity means you can show what each decision depends on

Engineering teams make decisions with partial information all the time. For example, early in a program, the certification basis may still be evolving. System architecture may still be moving. Supplier data may be incomplete. Authority interpretation may not be final.

That is normal, and part of any developing program. But the danger is losing track of which parts of a decision were settled, which parts were assumed, and which parts still depended on someone else's answer.

A healthy engineering record should distinguish accepted facts from proposed interpretations. It should show which relationships came directly from source artifacts, which were recovered from messy material, and which engineer suggested or decided what. And it should preserve ambiguity when the ambiguity is real.

This is important because a certification decision can become stale when the conditions behind it change.

An approval that was sound last month may become stale when the underlying requirement changes, when a supplier revises an interface, when a test configuration differs from the approved baseline, or when the authority clarifies its interpretation. If the program cannot see what a decision depended on, it cannot tell whether the decision still holds.

This is the clarity problem: not "where is the document?" but "what was this decision true under?"

AI can help make engineering arguments more inspectable

AI can find related requirements, compare versions, assemble candidate evidence, flag drift, draft summaries, and prepare decision packages.

Of course, in safety-critical engineering, engineers own the judgment, not AI.

This is also the practical point behind DO-330. DO-330 is about software tool qualification, not AI specifically. Its central concern is whether a tool could let errors escape detection by replacing or reducing a required assurance activity.

M45 is designed so that this condition does not arise: AI surfaces findings, gaps, and candidate links, but engineers must review and accept, modify, or reject them before anything goes into the engineering baseline.

And this means that every AI-assisted output must preserve the questions a responsible engineer needs to ask:

• What sources did this use?
• What changed since the last accepted baseline?
• Which claims are directly supported?
• Which claims are interpretations?
• What assumptions remain open?
• What decision is being requested from a human?

If these questions are visible, AI can reduce certification burden without weakening engineering control. Without those questions, AI just produces more paperwork faster.

And we don't want more paperwork faster, but a certification record where the program, the authority, and the next engineer can understand why the claim was acceptable at the time it was accepted, and what would make it need review again.

When the reasoning stays visible this way, you get something much more valuable than better documents: better engineering memory.