This follows on from Nobody Asks to Build the Waiting Room, which built phase one: the nineteen tables that establish who is asking.
The company is registered. The people are verified. Somebody logs in and lands on a page that has to answer one question: what can we apply for?
This looks like the easiest screen in the entire system. It is a list. You have a catalogue of services, you have an organization, you show the ones that apply.
I built it in an afternoon and it was wrong in three different ways, each of which only became visible when I imagined a specific company at a specific moment.
The version that ships in a day
Every service belongs to a kind of organization. An Air Operator Certificate (AOC) is for air operators. A maintenance approval is for maintenance companies. A training certificate is for training schools.
So: a table linking organization type to service, a join, a list on screen. Done.
Services available to Green Airlines
Apply for Air Operator Certificate
Amend Air Operator Certificate
Renew Air Operator Certificate
Surrender Air Operator Certificate
Apply for operations specifications amendment
Nominate accountable manager
…
Now picture the company that has just finished registering. They have no certificate of any kind. The screen offers to amend one, renew one, and surrender one.
And picture the company that has held its AOC for six years. The screen offers to apply for an AOC.
Both companies are being shown things they cannot do, and neither screen is telling them why.
The first kind of available: are you the right sort of company?
This is the one the naive version gets right, and it is genuinely necessary. A maintenance company cannot apply for an AOC no matter what else is true about it. A training school cannot apply for an aerodrome certificate.
It is a fixed relationship between what the company is and what it may ever ask for. It does not change from one week to the next.
It is also, on its own, useless.
The second kind: do you already have it?
An operator holding a valid AOC cannot apply for another one. Not "should not" — cannot. There is one certificate per operator, and a second would be meaningless.
What they can do is amend it, renew it, or surrender it. Every one of those requires the certificate to already exist.
So the same catalogue entry flips depending on a fact that lives somewhere else entirely:
| Service | Holds no AOC | Holds a valid AOC |
|---|
| Apply for AOC | available | not available |
| Amend AOC | not available | available |
| Renew AOC | not available | see below |
| Surrender AOC | not available | available |
Four services, and the availability of every one of them is decided by a row in a completely different table. The organization type says nothing about it.
The third kind: is this the right moment?
Renewal is where it stops being a boolean.
An operator holding a valid AOC cannot renew it whenever they feel like it. Renewal opens inside a window before expiry — too early and there is nothing to renew, too late and it is no longer renewal at all but a different, harder process.
So renewal has three states, not two: not yet, now, and too late. And the middle one is a window computed from a date on the certificate.
Figure 1 — The same operator at four moments
The same air operator at four moments. A screen filtered on organization type shows the identical list in all four columns, and is therefore wrong in three of them.So, it is not a filter
The mistake in my first version was treating this as one question with one answer. It is three questions asked of three different things:
| Question | Asked of | Changes |
|---|
| May you ever? | the organization type | almost never |
| Do you hold it? | the certificate register | when something is issued or surrendered |
| Is it the moment? | dates on that certificate | every single day |
The last row is the uncomfortable one. It means the answer to "what can we apply for" is not a stored list. It is calculated when somebody asks, and it can be different tomorrow without anyone having done anything.
Figure 2 — Three inputs, one of them the calendar
Three inputs, one of which is the calendar. That is why the result cannot be a stored list.Two hundred and fifty-seven services, and the rule that is not
Here is where I expected the work to become enormous.
Reading the framework end to end produced a catalogue of two hundred and fifty-seven services. If each one needs its own availability rule, that is two hundred and fifty-seven rules to write, test and maintain, and every one is a place to get it wrong.
It turned out to be ten.
Because the rule does not belong to the service. It belongs to the shape of the service, and there are only about ten shapes: apply for the first time, change something, renew, give up, accept a named person, approve a document, ask for an exception, report an occurrence, inspect, enforce.
Every "apply for the first time" service in the catalogue shares one rule: you must not already hold the thing. Every "change something" service shares the opposite: you must hold it. Renewal adds the window. Surrender needs nothing but possession.
Write ten rules, not two hundred and fifty-seven. The catalogue entry says which shape it is, and the shape carries the rule.
An air operator certificate and a maintenance approval are the same four services with different evidence attached. So are a training certificate, an aerodrome certificate, and every personnel licence in the system.
Where this shows up in the data. The catalogue holds the service. The pattern holds the rule. A small table maps organization type to service for the first question, and the certificate register answers the second and third.
Adding a new service to the catalogue means choosing its shape and its eligible organization types. It does not mean writing an availability rule, because one already exists.
The screen should not hide things
Having worked out what is available, the tempting next step is to show only that. A clean list of what you can do. Nothing greyed out, nothing confusing.
It is the wrong instinct, and Part Two of this series is the reason why.
A company that has never seen "Apply for Air Operator Certificate" on any screen does not know it exists. They cannot plan for it, cannot ask what it requires, and cannot tell whether they are on the right path. A menu that shows only today's options teaches nobody anything about tomorrow.
What hiding produces:
Services
Amend Air Operator Certificate
Surrender Air Operator Certificate
Two options. No indication that renewal exists, or when it will open, or what the operator should be preparing. The screen is accurate and it teaches nothing.
What showing with a reason produces:
Services
Amend Air Operator Certificate
Surrender Air Operator Certificate
Renew Air Operator Certificate
opens when your certificate is nearer expiry
Apply for Air Operator Certificate
you already hold one — amend it instead
The same two things are actually clickable. The operator now knows what else exists, why it is closed, and what to do instead.
This is the same principle as a useful error message, applied a step earlier. Do not make somebody discover a rule by failing against it.
The empty screen problem
One case breaks all of the above, and it is the first one every new user meets.
A company registers. It holds nothing. Almost every service is closed, so almost every line is greyed out. The screen looks broken, or looks like a mistake, or looks like the company is not allowed to do anything.
The honest answer is that a newly registered operator genuinely has one option: begin the certification process. Everything else really is unavailable, and correctly so.
So the screen has to say that plainly rather than presenting a wall of disabled options and letting somebody work it out.
What a new company should see. One clear action, and an explanation of the road: start with the Pre-Application Statement of Intent (PASI), because everything else in the catalogue becomes available only after a certificate exists.
A list of two dozen things you cannot do is technically correct and practically useless.
And the one I had not considered at all
There is a fourth question, and it does not belong to the company.
The person looking at the screen may be an employee of the operator, or a consultant acting under a power of attorney. That power of attorney has a scope. It may cover airworthiness matters and not flight operations. It may have been revoked last week.
So two people from the same company, looking at the same screen on the same day, may correctly see different things.
That turns "what can this company apply for" into "what can this person apply for on behalf of this company" — and it is checked each time, not once when the delegate registered.
What to take from this
The screen that looked like a list turned out to be the place where four separate facts meet: what kind of company this is, what it holds, what day it is, and who is asking.
Four things I would tell myself before starting it again:
Availability is calculated, never stored
One of the inputs is the calendar. A cached list is wrong by tomorrow, and the bug it produces — a service that should have opened and did not — is invisible until somebody complains.
The rule belongs to the shape, not the service
Ten patterns carry the rules for two hundred and fifty-seven services. Get that wrong and you are writing the same four rules over and over with small variations, and one of the variations will be a mistake.
Closed is not the same as hidden
Show what exists and say why it is not open. A menu of only today's options is a menu that teaches nobody what to prepare for.
The empty state is the most common state
Every company passes through it, and it is the first thing they see. It deserves more design than the busy screen that comes later.