Picture the simplest screen in the system. Apply for a pilot license. A form, a few fields, a Submit button. An afternoon's work, maybe two if the checks are fiddly.
Now here is everything that has to be true before that button can do anything.
Is this person who they say they are, or did their employer type their name into a box? Is their medical certificate still valid — and valid for this class of license, which is a different question? Did they pass the skill test, and was the examiner still authorized on the day they conducted it? Are their exam credits still inside the window where they count? Which version of the regulation applies — the one in force today, or the one in force when they applied, which may not be the same and which matters legally? Is the officer reviewing this qualified for this type of aircraft? Is the person approving it someone other than the person who recommended it?
Seven questions. None of them appear on the form. Most are outside the applicant's control. Several can change between the day they apply and the day someone decides. And every one of them can make the license invalid if it turns out to have been wrong.
And that is the simple service.
Part one · The one that is not simple
An Air Operator Certificate — what an airline needs before it can sell a seat — is not an application. It is an application that contains other applications.
Before the certificate can be issued, the operator's Operations Manual has to be approved. That approval is a case in its own right: its own reviewer, its own deadline, its own decision, and it can be refused on its own terms. So can the maintenance program. So can the training program. Key staff have to be accepted one by one. An inspection at the operator's base has to happen and pass. Test flights have to be flown.
A developer building this reaches for a status field. PENDING, UNDER REVIEW, APPROVED. It is the obvious move and it is wrong within a week, because the status is not one thing. The application is waiting on four separate processes at the same time, any of which can fail without failing the others, and one of which cannot even start until another finishes.
There is no value you can put in that field that is true.
This is the moment most people realize they are not building a form. They are building something that has to track a case made of other cases, each waiting on the others — and they usually realize it in month four, with a database design that cannot express it.
Figure 1 — An application made of other applications
The certificate cannot be issued until each smaller case is settled — and each can be refused without failing the others. A single status field on the main application has nothing true to hold.It gets harder, and this is the part nobody warns you about
Everything above assumes the rules are consistent and easy to find. Here is what happens when you read them properly.
I have spent the last several weeks doing exactly that: reading a national civil aviation framework from end to end — every regulation, every procedure handbook — and building a catalog of the services the authority actually provides. Two hundred and fifty-seven of them.
Four things came out of it that I did not expect.
A handbook that contradicts the rule it is quoting. One regulation requires an operator to give the authority notice before resuming operations after a break, measured in working days. The authority's own procedure handbook, in the very paragraph that names and cites that regulation, gives a shorter period — and counts it in calendar days instead. Those are not the same unit, so the real gap is wider than the two numbers suggest. An operator who follows the authority's own guidance gives far less notice than the rule demands, and the penalty for insufficient notice is suspension or loss of their certificate.
Requirements nobody can find. A maintenance organization applying for approval must already hold an economic license before its certificate can be issued. That requirement appears in the authority's internal process map. It is not in the regulation. It is not in the handbook. An applicant who read every published source cover to cover would never learn it exists — and would fail at the final step for a reason they could not have known about.
A deadline you cannot work out. One regulation tells you to apply for renewal a set number of days before your certificate expires. The same regulation never says how long the certificate is valid in the first place. You are given a deadline counted backward from a date the rule never defines.
And the biggest one. 119 of the 257 services have a regulation but no written procedure at all. The rule exists. The obligation is real. How the authority actually handles it is written down nowhere I could find. That is forty-six percent of the catalog. In one case the authority has written, against its own procedure, "NOTE: This guidance to be developed at a later date."
None of this is unusual, and none of it is a criticism of the people involved. Rules build up over decades, in pieces, written by different people solving different problems at different times, and nobody ever gets a quiet afternoon to make the whole thing agree with itself. That is the normal state of every large body of rules, in every country, in every industry.
But it is the condition your system has to survive.
And the rules can be replaced entirely
There is one more thing, and it is bigger than any amendment.
Most civil aviation authorities do not write their regulations from nothing. They take the international Standards published by ICAO, the United Nations aviation body, and turn them into national law using a structure borrowed from a larger authority. Two models dominate. One comes from the United States, through the Federal Aviation Administration. The other comes from Europe, through the European Union Aviation Safety Agency.
Why this matters for what you are building. Saudi Arabia's General Authority of Civil Aviation built its regulations on the American model, and now has a project underway to move to the European one. It is not alone; authorities across the region are considering or doing the same thing.
This is not an amendment. Rule numbers change. The structure changes. A whole layer that did not exist before appears — the European model separates the binding rule from an official description of an acceptable way to comply with it. Some services disappear and new ones appear.
Here is what that looks like in practice. Under the current model, an approved maintenance organization holds a certificate that expires, so there is a renewal service: a form, a fee, a deadline, a reminder, a workflow, an officer who processes it. Under the European model, that approval does not expire at all — it stays valid as long as the organization keeps meeting the conditions.
So the renewal service does not get smaller. It stops existing. And every screen, fee line, deadline calculation and reminder email built on top of it has nothing to point at.
If you build a system where each service is its own hand-written thing, a change of model means rebuilding most of it. If you build a system where services are described by data, a change of model is a large but survivable data migration.
Why this changes the design, not just the schedule
The obvious reaction is that this is a research problem: gather the requirements properly, then build.
It is not. You will never have complete requirements, because the source material is genuinely incomplete. You cannot resolve the contradictions, because you do not have the authority to decide which document wins. And you will keep finding new ones for as long as the system exists.
So the design has to hold rules it does not know yet, and hold rules that disagree with each other, without breaking. Three things follow from that.
Rules are data, not code
The moment a requirement lives inside an if statement, changing it needs a developer, a release and a deployment. Rules change constantly — amendments, new editions, new international Standards, and occasionally the whole model as described above. If every change is a code change, the system is permanently behind the law it is supposed to implement. Requirements, service definitions, document checklists, deadlines, fees: rows in tables, edited by an administrator on a screen.
Services are settings on a small number of patterns
Two hundred and fifty-seven services sounds like two hundred and fifty-seven builds. It is not. Read them all and they collapse into about ten shapes.
Figure 2 — 257 services, ten patterns
An airline certificate and a maintenance organization certificate are the same process with different documents, different reviewers and different timings. Build the ten. Configure the rest.Time is part of the design, not an afterthought
Get this wrong and you have not built a system — you have built two hundred and fifty-seven systems that happen to share a login page.
A certificate issued three years ago was issued under the rules in force three years ago. When someone challenges it today, the system has to answer what the rules said then — not what they say now. That is not a change log added later. It means every case records which version of the framework it was decided under, and every reference in the system carries a date. Adding this afterward is not a change; it is a rewrite.
And the part that is really about people
Here is what automation is for, and it is not speed.
An authority's core problem is consistency. Two operators in the same situation should get the same answer. Two inspectors looking at the same evidence should reach the same conclusion. A decision made in one city in March and one made in another city in September should stand up next to each other.
Paper does not do this. Spreadsheets do not do this. Experience in the heads of senior inspectors does it beautifully, right up until those inspectors retire.
And there is a second thing, which matters more than it sounds. When an authority refuses an application, suspends a certificate or withdraws an approval, the person affected has a right to know why. Not "your application was unsuccessful" — the actual reasons, tied to the actual requirement, measured against the actual evidence they submitted. A system that records a decision without recording the reasoning behind it cannot support an appeal, cannot show it treats people consistently, and cannot defend the authority when the decision is questioned years later.
That is what you are building. Not a workflow tool. A machine that has to be able to explain itself.
Part two · What I am using, and why you should not feel obliged to
Enough theory. Here is what you need on your machine before the next article, which starts building.
I am building this on Oracle APEX 26.1 on Oracle Database 26ai, running on a Linux server. That is a disclosure more than a recommendation — it is what I know deeply, it is what the environment I work in runs, and building screens quickly on top of a serious database happens to suit this problem well.
But nothing in this series depends on it. The hard parts are the data design, the process engine and the security boundary — and those are the same problems in any technology.
| What I use | Works just as well |
|---|
| Oracle Database | PostgreSQL, SQL Server, MySQL |
| Oracle APEX | Django, Rails, Laravel, ASP.NET, Spring Boot, or a React front end on a REST API |
| PL/SQL packages | Stored procedures, a service layer, an application-layer API |
| ORDS | Any REST framework |
If you follow along in PostgreSQL and Django, you will hit exactly the same design decisions and reach exactly the same conclusions. The SQL will differ in dialect. The thinking will not.
One real caution: whatever you choose, pick something that enforces relationships properly. This subject is full of them — a person holds a license, which carries ratings, each with its own validity, earned by passing tests, taken with examiners who hold their own authorizations. A loose document store will let you write all that. It will not let you ask, three years later, which certificates were valid on a given Tuesday.
What you actually need
Four things, whatever the technology.
- A database you can develop against on your own machine. Not shared with anyone. You will drop and rebuild it a dozen times before the design settles, and you cannot do that on a database someone else is using.
- A migration tool. Liquibase, Flyway, Alembic, Rails migrations — whichever your technology prefers. Not optional, and not something to add later. The design will change constantly, you will need to rebuild from scratch repeatedly, and every change has to be repeatable. Scripts run by hand from a folder are how two environments quietly stop matching.
- Version control, from the first file. Including the database design. Especially the database design.
- Somewhere to keep the regulations. This is the one people skip and regret. You will be reading regulation text constantly, and you need it searchable, on your machine, not in a browser tab. A folder of PDFs, converted text, a wiki — what matters is that it exists and that you can search it.
The setup, in order
One — the database
Install it locally, or run it in a container, whichever you prefer. Containers are easier to throw away, which is the point. For Oracle, the free edition is genuinely free and enough for everything in this series. For PostgreSQL, the official image and five minutes. Make sure you can connect from a client before going further; an hour lost to networking now is better than an hour lost in the middle of a build.
Two — a workspace that belongs to this project alone
Create a dedicated user or schema for it. Do not build in the default one, and do not build as an administrator. You will want to delete the whole thing and start again, and you want that to feel small rather than frightening.
Three — migrations, before the first table
Set the tool up first and create your first table through it. If the first few tables go in by hand with the intention of adding migrations later, they never do, and the history starts with a hole that never gets filled.
Four — the application layer, connected to nothing
Get one page showing something from the database. One page, one query, no features. Prove the connection, the credentials and the deployment path all work before there is any logic to confuse the diagnosis.
Five — the regulations, on your machine
Download the framework you are working with. Convert it to text if you can. Make it searchable. When the next article asks you to model an eligibility requirement, you want to be reading the actual clause, not somebody's summary of it.
One habit to start with
Before you write anything, decide where the why lives.
Every real decision in this build will have a reason, and reasons disappear fast. Six months from now you will find a rule in your own code that you do not recognize, and you will either spend a day working out why it is there or — worse — delete it, because it looks unnecessary, and rediscover the reason the hard way.
A plain text file in the project is enough. One entry per decision: what you chose, what you rejected, why. Two minutes at the time, days saved later.
I know this because I did it badly. I built an entire storage design around a guarantee I was sure the regulations required, spent a week working through its consequences, and only later — when someone asked me to point at the requirement — found that I had assumed it. It was my own engineering judgment wearing a regulation's clothes. The design came out. What survived was the note explaining why it had gone in, and that note is the reason nobody will lose another week working it out again.
Write the reasons down.