A check that cannot run has not passed

#The question

A flight departed with an airworthiness certificate that the API itself, asked directly, described as expired.

Nothing was broken. There was no exception, no failed check, no alert. The takeoff gate ran, it returned a verdict, and the verdict was that the flight could go. The system had every fact it needed to say no, in its own database, reachable by a query it already knew how to write, and it said yes.

That is a more uncomfortable failure than a crash, because a crash tells you about itself.

#What I thought was happening

My model of the gate was a list. A flight wants to depart; the gate walks a list of conditions; if any condition fails, the departure is blocked. Adding safety meant adding conditions to the list, and the work was in getting each condition right.

Two assumptions were hiding in that model, and both were wrong.

The first was that a condition which cannot be evaluated is a condition that does not apply. The pre-flight blocker was written as conditional on a checklist template existing. A brand new organisation seeds no templates, so the condition was false, so the blocker did not fire. It did not error, and it did not warn. It just was not there, and the gate quietly narrowed to the one question that could still be answered: is the pilot authorised.

The second was that overridability tracks severity. If something is serious, make it hard to override; if it is advisory, let people through. That sounds obviously right and it produced an arrangement that was precisely backwards.

#What I found

The audit was blunt about it. The takeoff gate never checked aircraft document expiry, never checked crew licence or medical expiry, and never checked overdue maintenance schedules. Those are not house rules. They are the conditions under which an aircraft is legally permitted to fly, and none of them were consulted.

Meanwhile the one condition that genuinely needs human judgement in the moment, an open grounding defect, could be overridden with a five-character free-text reason.

So the gate had inverted itself. The matters of law were unchecked, and the matter of judgement was a text box. Nobody designed that. It accreted, because each individual decision was locally reasonable: the override existed because operations really do need to dispatch with known defects, and the document checks were missing because nobody had got to them yet.

The pre-flight degradation is the part I find most instructive, because it is the one that will recur in every system I build. The gate did not fail open in the dramatic sense. It failed narrower. It kept returning confident verdicts about a shrinking set of questions, and from the outside a narrower gate and a complete one look identical: both say "cleared".

#The decision

Two changes, and the second one is the interesting one.

Fail closed. A safety check that cannot run because its configuration is absent is a blocker, not a skip. An organisation without checklist templates is not an organisation with nothing to check; it is an organisation we cannot make a statement about. To stop that being merely annoying, new organisations are seeded with persona presets, so they are safe by default rather than blocked by default.

Grade overridability by the kind of limit, not by how serious it feels. Three categories:

Kind of limit	Override
Expired airworthiness documents, expired crew credentials, hard component life limits (hours, cycles, date)	None
An open grounding defect	Only by deferring it, with an MEL or CDL reference and an expiry
The synthetic health band	With a reason

The distinction is not severity. It is who is the authority for this fact.

An expired certificate is a matter of law, and no operational judgement can make it not expired, so there is nothing for an override to express. A grounding defect is different: dispatching with a known defect is legitimate and routine, and aviation already has a mechanism for it, the minimum equipment list. Routing the override through the deferred state the schema already modelled replaces a free-text box with the actual regulatory instrument. And the health band is our own heuristic, computed from a wear rate that defaults to zero for most organisations, so it must never be treated as an airworthiness finding. It is a hint we invented, and it should be overridable precisely because we invented it.

#What it cost

This is the part I would want to read in someone else's write-up, so: it is not free, and it is not obviously right.

Failing closed means an under-configured organisation is blocked rather than permissive. That is deliberate, and it will generate support load the first time someone signs up. The seeded presets exist to absorb that, and I do not yet know whether they absorb enough of it.

Non-overridable document expiry is worse. A clerical lapse, a renewed certificate that is valid but has not been uploaded yet, grounds the fleet with no manual escape. That is a real operational risk, not a theoretical one. It is mitigated by warning ahead of the expiry date, and the escape is to file the renewed document, which is a first-class action rather than a workaround. But there is deliberately no override, and I was not comfortable making that call alone: the decision sat as Proposed while its policy table shipped and became load-bearing, and was ratified explicitly a month later.

I still think it is right. An override on a legal precondition is not a safety valve, it is a second, undocumented definition of airworthiness with a text box in front of it.

#The model that made it click

A check that cannot run has not passed. Absence of configuration is absence of evidence, and evidence is what a gate is for. The only honest answer to "I could not evaluate this" is to refuse.

And the second half: who is the authority for a fact determines whether a human may override it. Not how serious the fact is. If the authority is outside your system, there is nothing for an override to mean.

#What I would remember in six months

Look for the inversion. In any system with a gate and an override, check whether the things that are matters of external fact are the ones being enforced, and whether the things needing judgement are the ones with an escape hatch. It is very easy to end up with that backwards, because each piece arrives separately and each one is locally sensible.

And a narrower sibling, which I now check for by habit: any condition written as "if X is configured, check Y" is a condition that disappears silently. If it should not disappear, the absence of X has to be its own failure.