The current conversation about AI
There is a conversation happening in aviation right now that I find both interesting and slightly frustrating. Every second conference talk, every third LinkedIn post, is about AI and what it will do for speeding up the work (productivity first!). Faster document review. Automated requirement traceability. Intelligent regulatory monitoring. The promises are real enough — and some of them I genuinely believe in, which I will come to. But the conversation has developed a blind spot, and the blind spot matters. The blind spot is this: the problems that actually make certification programmes fail — late delivery, budget overrun, frantic close-out sprints, findings that should have been caught months earlier — are not problems that AI solves. They are not even problems that AI addresses. They are structural problems, planning problems, visibility problems, which become coordination problems at project execution. And no amount of intelligent document parsing or information surfacing fixes a programme that was never properly set up in the first place. I have spent twenty years in aviation. Part of that time in the airworthiness office, part of it as project manager and another small part as external evaluator. I have seen a lot of certification programmes. The ones that ran into serious trouble almost never ran into trouble because the team lacked technical knowledge. They ran into trouble because of how the work was organised — or not organised.
What AI can genuinely do
Before I make the case against AI as a certification silver bullet, I want to be clear about what it can actually do well — because the legitimate use cases are specific, practical, and worth taking seriously. An LLM with access to your compliance documentation can detect missing cross-references — requirements in your compliance matrix that point to evidence which does not actually address them. That is a legitimate and useful capability. Also interesting are the document intelligence tasks: given a compliance report and the set of requirements it is supposed to address, AI can generate a compliance summary — a structured account of how the document demonstrates compliance with each requirement. This does not replace the engineering judgement that produced the report, but it reduces the administrative overhead of producing the summary significantly. Even more valuable in practice: if you hold an STC on a given aircraft type and need to port it to a closely related variant — different TCDS, different applicable amendments, different certification basis in some areas — AI can handle the structural adaptation of the compliance documentation. Changing applicability statements, updating references, flagging which requirements now differ and which carry across unchanged. This currently takes weeks. Done with proper AI tooling and human review, it should take days. And there is a capability I find genuinely compelling as someone who has reviewed compliance reports from both sides: AI-based confidence scoring on compliance claims. Given a requirement and the section of a document claiming to show compliance with it, a model can assess whether the claim is explicit, traceable, and unambiguous — and give you a score. Not as a replacement for the reviewer, but as a first-pass filter that surfaces the weak claims before the reviewer does. These are real. They are available with current technology. They will make certification teams more efficient in specific, bounded tasks.
What AI cannot do
AI cannot tell you that your compliance strategy was wrong at project initiation. It cannot flag that the three disciplines contributing to compliance with a single structural requirement have been working in parallel for six months without anyone managing the interface between their outputs. It cannot surface the fact that your team's senior engineer — the one who carries the institutional knowledge of how this product family was certified last time — is spending thirty percent of their week maintaining a compliance tracking spreadsheet that two other people also maintain in slightly different formats. It cannot tell you that your programme is six months late because the design kept moving an never looked back at the certification basis as agreed, and nobody made a formal decision about how to handle the delta that has formed. Nobody actually even know there was a delta, as the requirements were stored in an excel at the beginning and just left there. These are the problems I actually see. Repeatedly. In organisations with good engineers, solid technical knowledge, and genuine commitment to doing the work properly. The failure mode is almost never technical incompetence. It is the absence of structure around technically competent people. Let me give you two examples from my experience — anonymised, but real in substance. The first: a small DOA with genuine airworthiness expertise but chronic manpower pressure. Talented engineers, but permanently stretched. When I looked at how they were actually spending their time, a significant portion of it was on coordination overhead — tracking open compliance items, managing document versions, chasing status on deliverables that were nominally someone else's responsibility. The engineering brain was being used for administrative work. Not because the team was disorganised by character, but because they had no proper infrastructure to carry that load. The result was a programme that delivered late, with a close-out sprint that should not have been necessary. The second: a larger organisation with experienced people across multiple disciplines — structures, systems, avionics, performance. Individually strong. But on a requirement that sat at the intersection of two disciplines — where the structural analysis had implications for the systems compliance demonstration and vice versa — nobody had formally owned the interface. Both teams were working. Neither was watching the join. It was the kind of gap that is invisible until it is not, and by the time it surfaced, both workstreams needed rework. AI would not have caught either of these. A properly structured certification programme — with clear ownership, live visibility of status, and explicit interface management — would have.
The question worth asking
When people ask me what CIVIRES does, I usually try to resist the temptation to lead with features. The more useful answer is to describe the problem it is built around. A certification programme, properly managed, is not a document management exercise. It is a structured demonstration: a set of requirements, a set of claims, and a body of evidence that supports those claims. The primary job of a certification tool is not to store that evidence. It is to maintain the live relationship between requirements, claims, and evidence — across the full project, continuously, in a form that every member of the team can query and that they can trust: because the picture is complete. CIVIRES is built around that relationship. It gives you a live picture of your type investigation status at both project level and compliance matrix level. It creates the documents, data and metadata directly on top of that relationship, with your templates, releasing those entities according to your processes. It manages versioning and compliance baselines — snapshots that let you trace what the compliance picture looked like at any point in the programme. It is not a Configuration Management System — it does not handle design changes and order management in the way a PLM does. But it carries the compliance infrastructure that PLM tools do not address out-of-the-box: the structured, queryable, auditable demonstration that your programme is — or is not — on track. On top of that infrastructure, AI has a proper place. AI that can score your compliance claims for clarity. AI that can draft a compliance summary from your existing documentation. AI that can port your compliance matrix when you move an STC to a new aircraft variant. These are force multipliers when the underlying structure is sound. They are noise when it is not.
What digital transformation actually means for a DOA
The phrase gets used loosely. In most cases, what organisations mean when they say they are digitally transforming their certification process is that they have moved their documents from a filing cabinet to a shared drive. The content is digital. The process is not. A digitally transformed certification process is one where the programme structure itself is represented digitally — where the compliance strategy is not in someone's head, the status is not in a meeting, and the evidence is not in a folder. Where a design change triggers a structured review of the compliance areas it touches, automatically surfacing what needs to be revisited. Where new engineers can orient themselves from the system rather than from a three-hour handover conversation. Where you have a digital twin AND a digital thread that handles the lifecycles of the entities and their interconnection. That is not an AI problem. It is an architecture problem. And solving the architecture problem is what makes the AI capabilities useful rather than decorative.
A note on honesty
We have built a product in this space, which means you should weigh what I say accordingly. But the argument I am making here is not a sales argument — it is a product philosophy. CIVIRES has AI features on the roadmap because the document intelligence tasks I described above are genuinely valuable. We have a proof-of-concept, and we intend to build them properly, trained on real certification data with human review built into the workflow. What CIVIRES will not do is lead with AI as a positioning claim. The organisations that have improved their certification outcomes most consistently — that deliver on time, that find oversight visits routine rather than stressful, that absorb design changes without their compliance picture collapsing — did not do it with clever tooling. They did it by taking the structural problem seriously first. The tooling follows. The AI follows. The structure comes first.