The Green Airlines

Not with the AOC application. The Green Airlines cannot apply for anything yet, because as far as the Authority is concerned the company does not exist.

Everything in the previous article happens first. The organization has to be registered: identified, its commercial registration confirmed with the MOC, an address, a contact. The people have to exist as individuals, verified against the national register. The Director of Operations has to be linked to the company as an employee, and then separately authorized to file things on its behalf — because being employed and being allowed to speak to the regulator are two different facts.

Only then can anything else happen. And this is where Khalid's team hits the first wall.

The first mistake. The quality manager registers the company. She types the commercial registration number from a scanned copy of the certificate, transposing two digits without noticing. Everything else is correct.

She presses Submit and the screen says: Validation failed.

She now has a form with about forty fields, one of which is wrong, and no idea which. She checks the company name. She checks the address. She re-enters the phone number in a different format, in case that was it. Twenty minutes later she calls the Authority, and somebody there spends fifteen minutes of their own day working out that a commercial registration number does not match.

This is not a small thing. It is the most common defect in government systems and it is entirely avoidable.

The system already knew everything needed for the good version. It sent a number to the MOC, the MOC said no such registration, and the system threw that answer away and replaced it with a code. The information existed and was discarded.

Name the field. "Validation failed" is true of the whole form. "Commercial registration number" is true of one box she can look at.

Say who decided. An error from your own validation and an error from the Ministry of Commerce are different problems with different fixes. If she believes the number is right, she needs to know it is the Ministry she has to call, not you.

Never blame the user for something you could have prevented. If the number has a check digit, verify it as she types and tell her immediately, rather than accepting it, sending it away, and reporting failure a page later.

She corrects the digit. The MOC confirms the company. The Green Airlines now exists in the Authority's system, with a verification result and the date it was true.

Khalid's Director of Operations has done this before, at a previous employer, and he remembers it as a letter. You wrote to the Authority setting out what you intended to do, they read it, and eventually somebody called you in for a meeting.

That letter has a name: the Pre-Application Statement of Intent (PASI). It exists because certification is expensive for the regulator as well as the applicant. Before the Authority commits inspectors to months of evaluation, it wants to know whether this applicant is serious, whether the plan is coherent, and whether they have the faintest idea what they are taking on.

As a letter, it worked and it did not scale. Every submission arrived in a different shape. Half of them omitted something the Authority needed. Nobody could answer "how many pre-applications are open" without going through a filing cabinet, and there was no way to see that an applicant had submitted three times in two years under slightly different company names.

The first job of the system is not to speed the letter up. It is to make every letter contain the same things.

Here is what that becomes in the database. It is worth seeing in full, because the shape of it carries decisions that would otherwise be invisible.

PASI

PASI_FLEET

PASI_KEY_PERSONNEL

PASI_ATTACHMENT

Key personnel are people, not names

person_id rather than a text field. It looks like a small choice and it is not. If the Chief Pilot is a real person record, the system can look at the licenses that person holds. If it is a typed name, it can look at nothing, and the check that matters most has to be done by a human reading a CV.

The fleet is typed, not described

aircraft_type_code from a controlled list. Free text gives you "A320", "A-320", "Airbus 320" and "airbus a320" as four different fleets, and any question about how many operators intend to fly a type becomes unanswerable.

A decision has a person attached

decision_by_person_id, not a name in a box. Years later, in a dispute, "who declined this and on what grounds" has to have an answer that does not depend on anyone's memory.

What Khalid's team submits. The Director of Operations fills the PASI properly. Fleet: three aircraft of one type, dry leased. Base: their home airport. Operation: scheduled passenger, domestic to start, international within two years.

For key personnel he lists himself as Director of Operations, the Director of Maintenance, and the Chief Pilot. He leaves the safety manager blank — they have not hired one yet, and he reasons that it can be added later.

He attaches the business plan and the financial evidence. He does not attach the organizational structure, because the template he was working from did not mention it.

Two things are wrong and they are wrong in different ways.

The missing safety manager is a gap the applicant knows about. The missing organizational chart is a gap the applicant does not know about. A system that treats them identically fails the second one, because the applicant cannot fix a problem nobody has told them exists.

What a weak system does: accepts the submission. It reaches an inspector, who reads it, notices two omissions, and writes an email. The applicant fixes them and resubmits. Somewhere between those two events, days pass, and the Authority's own performance figures record that time as its own.

What the system should do: refuse to accept an incomplete submission, and say precisely what is missing before the applicant presses the button — not after.

This statement of intent cannot be submitted yet. Two items are missing.  Key personnel: no person is nominated for the Safety Manager role.  This role is required for the type of operation you have selected.  Attachments: the Organizational Structure document has not been  uploaded. It is required for all applicants.

This is why the fourth child table exists. Completeness is not something an inspector should have to discover — it is something the system can compute, because the requirements for a given operation type are data.

PASI_MISSING_ITEM — computed, not stored by hand

The reason this is a table and not a validation function. A validation function tells you yes or no, now. A table tells you what was missing, when it was noticed, and how long it took to resolve — which is how the Authority learns that seventy percent of applicants forget the same document, and fixes the form rather than blaming the applicants.

Khalid's team hires a safety manager, uploads the chart, and submits. An inspector reviews it, and the Authority accepts the pre-application. They are invited to a meeting, where somebody explains the road ahead and how long it usually takes. Khalid revises his budget.

Now the real application. And here is where a developer building this system meets the problem that defines it.

The formal AOC application is not a form with a status. It is a container. Before the certificate can issue, several other things must each be approved on their own terms, by different people, on different timescales, and any of them can be refused without the others failing.

This is the design decision that separates a system which survives from one that gets rebuilt. A developer who models the AOC as a row with a status will discover in month four that the row cannot express the state the process is actually in, and by then there is data in it.

The application is not in a state. It is waiting on five things that are each in their own state.

The Operations Manual comes back. The Green Airlines submits its Operations Manual Part A (OM-A) — the general manual covering the operator's organization, responsibilities, procedures and controls. The quality manager built it from a template she brought from her previous employer, adapted for the new company.

It is refused. Not for anything dramatic. Two sections are missing entirely, one describes an organizational arrangement the company does not actually have, and the section on flight time limitations refers to a version of the rules that has since been amended.

Nothing here is unusual. A first manual is refused more often than not, and an experienced quality manager expects it. What matters is what the refusal tells them.

The refusal that helps nobody:

The Operations Manual Part A has not been approved. Please review and resubmit.

She now reads three hundred pages looking for a problem she cannot see, or she calls the inspector and asks — which is what actually happens, and which is why inspectors spend their afternoons on the telephone.

The refusal that does its job:

Operations Manual Part A - not approved. Three findings. 1. Missing section. The manual contains no section covering the   carriage of dangerous goods. Required for the operation type   you have applied for. 2. Inconsistent with your application. Section 1.3 describes a   Deputy Chief Pilot position. No such role is nominated in your   application, and no person has been accepted for it. 3. Superseded reference. Section 7.2 cites a version of the flight   time limitation rules that was amended. The current version applies.

The second finding is the interesting one, and it is the argument for holding all of this in one system rather than several.

Nobody caught that by reading carefully. The manual said the company has a Deputy Chief Pilot; the application said it does not. Two documents in the same case disagreeing with each other is something software is good at noticing and humans are bad at, because the two facts are three hundred pages and several weeks apart.

What this requires of the design. Manual sections have to be structured enough to compare against the application. Not the prose — the claims. Which roles the manual says exist, which aircraft types it covers, which operations it describes. If the manual is only a stored file, the system can tell you it was uploaded and nothing more.

The manual is approved on the second submission. The maintenance program follows. Each nominated person is accepted individually — the Director of Operations, the Director of Maintenance, the Chief Pilot, and the safety manager they hired in a hurry. Individually, because the Authority is accepting a named human being for a named post, and a group approval would mean nobody had actually assessed the quiet one.

Then the base inspection, which is a site visit and a report rather than a document review. Then proving flights: the aircraft flies the routes it intends to operate, without passengers, with the Authority watching.

And only when every one of those is resolved does the parent case have an answer. The certificate issues, with operations specifications attached — the detailed list of exactly what The Green Airlines is authorized to do, which aircraft, which routes, which types of operation.

One more design consequence, easy to miss. Those operations specifications are not a document. They are rows. Each authorization — a route, an aircraft type, a special operation — has its own conditions and its own validity, and the airline will come back next year wanting to change exactly one of them.

If the specifications are a PDF, that amendment is a new PDF and nobody can answer what changed. If they are rows, the amendment touches one row and the history is visible.

The Green Airlines gets its certificate. It takes considerably longer than the feasibility study assumed, and roughly half of the elapsed time is theirs rather than the Authority's — the manual revision, the safety manager they had not hired, the organizational chart nobody told them about.

That last one is the part worth sitting with. It was not in the template they were working from. Nobody was hiding it. The requirement existed, in a document, and the applicant did not know to look.

A system that only tells applicants what is wrong after they submit has decided that discovering the rules is the applicant's problem.

For the developer, five things fall out of this story, and none of them are visible in the regulation.

Nothing starts until the foundation exists

Company registered and verified, people registered and verified, authorization granted. The first article was about this and the AOC is the proof of why.

Errors are a feature, not an afterthought

Name the field, say who decided, give an action. The information is already in your hands when the verification comes back — the only question is whether you throw it away.

Completeness is computable

If the requirements for an operation type are data, the system can tell an applicant what is missing before they submit. If they are in a PDF somewhere, it cannot, and an inspector does it by hand for every applicant forever.

A case can be waiting on several things at once

The status column is the trap. Model the parent as a set of open questions with a completion rule, and the AOC becomes expressible. Model it as a state, and it does not.

Time has two owners

Record every switch as it happens, with a reason. A regulator that cannot separate its own delay from the applicant's cannot defend its own performance figures, and will eventually be asked to.

None of this is specific to airlines. Replace the Operations Manual with a maintenance exposition and it is a repair station. Replace the proving flights with a demonstration and it is a training organization. The shape holds — which is the subject of the next article.