In the previous article, The Green Airlines, Khalid spent eighteen months and his own money on a feasibility study, registered a company, hired four people with a century of experience between them, and set out to get an Air Operator Certificate (AOC). A typing error stopped him at registration. His Pre-Application Statement of Intent (PASI) was refused for a missing safety manager and an organizational chart nobody had told him about. His Operations Manual came back with three findings, the clock switched sides while he rewrote it, and when the certificate finally issued, its operations specifications were rows in a table, not a document. The article closed with a claim: none of this is specific to airlines. Replace the manual and the flights, and the shape holds.
Then I sat down to design it from the Authority's side, and the story needed two corrections and one extension. Khalid's application went to the wrong office, and his certificate came out of the wrong office. And the shape holds only if the rules that fill it are data, not code. This part is about both corrections, the extension, and the design that came out of them: one workflow for every provider the Authority certifies, configured by what the applicant says it wants to be.
The wrong door
In the story as I told it, Khalid's Director of Operations filled the PASI and an inspector reviewed it. That is how it feels from the applicant's side, and it is not what happens.
The PASI, with its business plan, its financial evidence, and its organizational chart, goes first to Economic Licensing. Before any inspector reads a manual, the Authority asks a different question: is this a viable business? Economic Licensing studies the application and gives one of three answers. No, and the case closes. Hold, more information is needed, and the case waits for the applicant with the clock stopped. Or OK, which means the concept is accepted. Not the airline. The concept.
Three things happen on OK. A fee for the certification work is assessed, based on what the application asks for; an airline's certification is expensive because it consumes months of inspectors' time. The case is routed to the departments that own this kind of certificate, which for an airline means Flight Operations leads. And the certification project starts. Nothing has been certified. The Authority has agreed that Khalid's idea is worth its people's time, and it has said so in writing.
I had folded this into the pre-application phase because the applicant experiences it as one step. It is two, run by two sectors, and the system has to know that, because who owns the case decides who can act on it.
And the same door out
The second correction was smaller and I had missed it completely. When the five phases are done, when the manuals are approved, the post holders accepted, the base inspected, and the proving flights flown, the case does not end in Flight Operations. It goes back to Economic Licensing, and the certificate is issued from there.
The reasoning is separation of duties, applied to an office rather than a person. The people who assessed Khalid's airline do not sign the certificate they assessed. The office that judged the business at the start formalizes it at the end. For an airline the document is called an Air Operator Certificate. For anyone else, it carries the name the regulation gives that kind of provider. The Authority's word for all of them is the Operator Certificate.
Figure 1 — One journey, three stages
One journey, three stages. Stages 1 and 3 are identical for every provider. Only stage 2 changes, and it changes because the rule set changes, not the code.The shape holds, if the rules are data
Now the larger correction. I had ended the previous article by saying that a repair station is the same process as an airline with different evidence. True. But I had been about to build it wrong: one design document per certificate, each listing its own steps and its own smaller approvals, copied from the catalogue by hand. Five documents with the same shape and different labels. When you find yourself writing the fifth, the shape is the thing to build and the labels are data.
So the PASI gained one field that matters more than the rest: what does the applicant want to be. An airline under the air transport rules. A commuter or on-demand operator. A repair station. A ground handler. A training organization. An air navigation service provider. That answer loads a requirements pack.
The pack is everything about certification that is specific to that kind of operator. The regulatory part that governs it, with its European equivalent recorded alongside, because the numbering Khalid knows follows one model and the harmonized rules follow another. Every requirement the applicant must meet, shown on the form and ticked as read before submission. Every task the Authority performs, and the department that owns it. The smaller approvals the project will create. The list values the teams pick from. And the numbers that matter, each with the citation that makes it a rule rather than a habit.
The pack also reshapes the form. Khalid saw fields for fleet, routes, and a draft of his operations specifications. A repair station sees the ratings it wants and the facilities it has. A ground handler sees airports and service categories. One form, switched by one answer.
Why the condition lives on every line
An airline must fly proving flights before it is certified. A ground handler must not, because it has no aircraft. In my first design that difference was a fork in the workflow. In the pack it is a line that exists for the airline and does not exist for the ground handler, so the engine never asks the question. The same is true for the notice period before intended operation, the minimum size of a demonstration, and which manual which department must approve. Each is a line, with a citation, in force when its condition says so. When the rule changes, the pack changes, and no code is touched.
Many departments, one project
The previous article showed the formal application as a container waiting on five children, each in its own state. That was right, and it was also too tidy: I had drawn all five as Flight Operations' work. They are not.
The operations manual belongs to Flight Operations. The maintenance manuals belong to Airworthiness. The training program belongs to Training. The evacuation demonstration belongs to cabin safety. The security program and the safety management system belong to departments that run their own processes, which this case tracks but does not run. The project manager in Flight Operations does not approve any of this. He confirms that each department has closed its own items and that nothing in the pack is still open.
In the system, that means the children are not a list I write. They are created from the pack: each item names the phase in which it opens, the department that owns it, and whether the certificate may issue while it is still open. Khalid's airline gets about ten. A repair station gets its manual, its quality control manual, its capability list, a facility inspection, and its nominated persons, from the same mechanism and a different pack. A ground handler gets one airport authorization per airport it names.
Phases three and four are allowed to overlap, and the case is allowed to move backward. A demonstration that fails because a manual was wrong reopens the manual in its owning department; the other demonstrations continue. The regulation does not describe certification as a straight line, and a system that forces one produces the familiar workaround of keeping the real state on paper.
Figure 2 — The form loads the rules
The form loads the rules; the rules create the work. The same PASI, answered differently, produces a different set of children in different departments.The applicant writes the specifications
One more thing the previous article got half right. The operations specifications are rows, each with its own conditions and validity, and an amendment touches one row. That stands. What I had not said is who writes them.
The applicant does. Khalid's team prepares its operations specifications inside the PASI, section by section, with all the detail an operation needs: which aircraft, which routes and areas, which airports, which special operations, whether it will carry dangerous goods, what it has leased and from whom. Only the airline knows what it intends to fly. The project teams inspect what the applicant wrote, row by row, and the rows they accept become the rows on the certificate. A row they refuse is dropped, and the certificate issues without it.
For a repair station the same table holds its ratings. For a ground handler, its airports and service categories. The mechanism does not change with the provider. It never did; I had just been looking at one provider.
If, then, else
Here is the design reduced to the branches the pack carries, so the engine does not have to.
If the applicant is an airline, then the pack is the air transport rules; Flight Operations leads; the children include manuals in three departments, post holders, a base inspection, proving flights, and an evacuation demonstration; the specifications are operations specifications; the certificate is an AOC.
Else if the applicant is a commuter or on-demand operator, then the pack is the smaller operating rules; Flight Operations leads; fewer children; a demonstration only if the aircraft is large enough for the rule to apply; the certificate is still an AOC, under a different part.
Else if the applicant is a repair station, then the pack is the maintenance organization rules; Airworthiness leads; no flights and no operations specifications; the attached list is ratings; and if the facility is outside the country, the pack adds the foreign approval evidence.
Else if the applicant is a ground handler, then the pack is the ground handling rules; the ground services department leads; no aircraft at all; one airport authorization per airport; equipment, facilities, and staff training records; a link to the security program.
Else if the applicant is a training organization, then the pack is the part it declared; Training leads, or Airworthiness for a maintenance school; curricula, instructors, facilities; and if simulators are declared, a simulator qualification child.
Else if the applicant is an air navigation service provider, then the pack is the service parts it declared; Air Navigation leads; a safety case, a manual per service, and an inspection per unit.
In every branch, stage one and stage three are the same two lines of code. Only the pack changed.
What to take from this
Four things I would tell myself before drawing the AOC workflow again.
The door is not where the applicant thinks it is. Khalid experienced the pre-application as one step. It is an economic decision in one sector and a technical project in another, and the certificate comes back through the first. Model the owner of the case, not the applicant's feeling of progress.
When the fifth copy looks like the first four, stop. The workflow was the thing to build. The differences were data, and the regulation had already written them down. The first construction task is not a page or a package; it is reading one regulatory part line by line and recording each requirement, its department, its phase, its condition, and its citation.
A case belongs to many departments at once. The children are not the lead department's to-do list. They are owned where the competence is, and the parent only confirms that each owner has closed its own.
The applicant knows things the Authority does not. What Khalid intends to fly is his to state and the Authority's to check. Build the form so he states it in rows, and the inspection so it accepts or refuses rows, and the certificate writes itself from what survived.
Khalid already has his certificate; his story was the specification. The first case to run the new shape end to end will be a repair station: in through the door his airline used, a pack with no flights in it, and out through the same door with a certificate that carries ratings where his carries routes. If the engine needs one line of code changed to do that, the design has failed. The bet is that it will not.
Glossary
Air Operator Certificate (AOC) — The certificate an airline must hold before it carries passengers or cargo for money. The airline's form of the Operator Certificate.
Operator Certificate (OC) — In this design, the generic certificate issued to any aviation service provider after certification. Its name follows the regulation for that kind of provider.
Pre-Application Statement of Intent (PASI) — The applicant's first formal submission, describing what it intends to operate. Here, a form in the system whose operator type loads the requirements pack.
Requirements pack — The rule set for one operator type: regulatory part, requirements, Authority tasks and their departments, child approvals, list values, and cited numbers.
Operations specifications — The instrument attached to an AOC listing what the operator may do. Prepared by the applicant, inspected by the Authority, stored as rows on the certificate.
Child case — A smaller approval, acceptance, inspection, or demonstration created by the main case and owned by the department responsible for it.
Economic Licensing — The office that judges the applicant as a business at the start of the journey and issues the Operator Certificate at the end.
Five phases — Pre-application, formal application, document compliance, demonstration and inspection, certification.
Separation of duties — The rule that whoever assesses an application does not decide it.
Applies-if condition — The rule on every pack line saying when that line is in force for a given application.
Sources
- ICAO, Annex 6 to the Convention on International Civil Aviation, Operation of Aircraft, Part I, Chapter 4 (air operator certification).
- ICAO Doc 8335, Manual of Procedures for Operations Inspection, Certification and Continued Surveillance.
- Regulation (EU) 965/2012, Annex III (Part-ORO), ORO.AOC.100 and ORO.AOC.105.
- Aviation Affair, Building a Civil Aviation Authority System, Parts 0 to 4, aviationaffair.com.