Who Are You, and How Do We Know?

A business analyst sitting with the licensing department asks things that sound too obvious to be worth asking. They are the most productive questions in the room.

Q. Who submits the application?
A. The company.

Q. Which person at the company?
A. Usually the operations manager. Sometimes the accountable manager.

Q. Can anyone else?
A. They can appoint a consultant. That happens with new operators who do not have the staff yet.

Q. How do you know that person is allowed to?
A. ...

That pause is where a table gets designed.

Look at what each answer actually names. "The company" is an organization — something with a legal identity, a registration number, an address. "The operations manager" is a person, employed by that organization, holding a role. "Can appoint a consultant" is somebody who is not an employee at all, acting on the organization's behalf because it granted them permission. And "how do you know" is the discovery that permission is a thing the system must hold, grant, and be able to withdraw.

Four questions produced four entities, and not one of them is mentioned in the regulation you started from. You would not have found them by reading harder.

There is a failure mode in requirements gathering that looks exactly like success.

The stakeholder says: the company must be verified before it can apply. Everyone nods. It goes into the document. It gets signed off. It reads like a requirement — it has a subject, a verb, and a condition.

Now try to build it. Verified by whom? Against what source? Recorded where? Checked at which point in the process — at registration, at submission, at the moment the certificate issues? What happens if the verification succeeded two years ago and the company has since been struck off?

If nobody in the room can answer those, the requirement passed review and constrains nothing. A developer reads it, decides it means a checkbox called IS_VERIFIED, sets it to true when someone ticks it, and ships. The requirement is satisfied and the system verifies nothing.

A requirement you cannot test is a requirement you have not gathered.

The test is simple and it is worth applying to every line: what would I have to look at to prove this is true? If the answer is "a column somebody sets by hand," the requirement is a placeholder wearing a requirement's clothes.

Why this matters more in a regulatory system. In most systems an untestable requirement produces a feature nobody uses. Here it produces a certificate that was issued on the strength of a check that never happened — and somebody will ask about it years later, in a dispute, when the person who ticked the box has left.

What the four questions surface is a small set of tables that have nothing to do with aviation and without which nothing aviation-related can happen.

Three of these are worth pausing on, because each embeds a decision that is easy to get wrong and expensive to reverse.

Employment is dated, and it is not a column

The obvious design is a company column on the person: this pilot works for that airline. It is one column, it is easy to query, and it is wrong.

A licence issued three years ago was issued while that person worked somewhere else. If the column holds today's employer, the question "who employed them when this was issued" has no answer at all — and that is exactly the question that gets asked when something goes wrong. Employment is a relationship with a start and an end, not an attribute of a person.

Some people have no employer, and that is not an error

A private pilot flying their own aircraft works for nobody. A licence holder between jobs works for nobody. If your model requires everyone to belong to an organization, you will end up inventing a fake one to put them in — and then explaining to the next developer what the "General Public" company is and why it has four thousand employees.

A person holds several identity documents at once

A national ID and a passport. A residency permit and a passport. Different numbers, different issuers, different expiry dates, all valid simultaneously. Two columns will not do it, and the moment you try, someone arrives with three.

This is roughly eighty percent of the work, and none of it looks like the thing you were asked to build.

The reason to build it once, properly, is arithmetic. An authority provides hundreds of distinct services, and every single one begins by knowing who is asking. Build the foundation per service and you build it hundreds of times, slightly differently each time, and the pilot who appears in two of them is two different people as far as the system is concerned.

Four consequences fall out of this, and they are design consequences rather than inconveniences.

An answer is true on a date, not forever

The commercial registry said this company was active on the day you asked. It does not follow that it is active today. So you store the answer and the date it was given, and anything that depends on it knows how old it is. A verification with no timestamp is a rumour.

Every one of them can be down

The national identity service is not part of your system and does not care about your uptime target. So registration needs a state that means waiting for someone else — and the clock that measures how long the Authority took should not be running while it waits, because that delay is not the Authority's.

Some of them say no

Not every refusal is a failure. A security clearance that comes back negative is a valid answer that the process has to handle, route to somebody, and record — not an error to be retried.

You never hold what you do not need

Payment is the clearest case. The system records that a fee is owed and that it was settled, with a reference. It never sees a card number, and it should never be built in a way that could.

The mistake this section exists to prevent. A registration screen with a text box labelled "Commercial Registration Number", stored as free text, never checked against anything. It looks finished. It passes testing, because testing types a plausible number into it. And the first time it matters — in a dispute, an audit, or an appeal — the Authority discovers it has been accepting whatever anyone typed.