The defect owns the finding

#The question

A pilot walks an aircraft before a flight, working through a checklist on a phone. They find something wrong.

There was no way to record that. A checklist item could be checked, or left alone. It could not be failed.

So the two available moves were: abandon the inspection, which loses everything already recorded and blocks the departure with no explanation of why, or tick the box and carry on. The audit rated this its worst finding, and it is hard to disagree. The system had made the honest action the expensive one.

#What I thought was happening

I read this as a missing state, and the fix as adding it. Give an item a failed state, and make a failed item block the transition. Half a day of work.

The moment I tried to write down what "a failed required item blocks the transition" means mechanically, it stopped being half a day.

#The two questions hiding in it

What does "required" mean? There was no notion of a required item. The instinct was to add a flag to the checklist template, so an author could mark which items are mandatory. That is one more thing to configure, one more thing to get wrong on a template nobody revisits, and one more axis of meaning that has to be explained to whoever builds a template next.

Items already carried a severity. critical already meant "this one matters". Defining required = severity critical added no new concept and no new field, and it made templates that already existed correct without editing them.

What blocks the flight, mechanically? This is where I nearly did the wrong thing.

The obvious answer is a new gate condition: checklist has failures. It is easy to write, easy to test, and it reads exactly like the requirement.

It is also a second source of truth about the same fact, and it can disagree with the first one.

Consider the sequence. A pilot fails an item. An engineer looks at the fault, fixes it, and closes the resulting defect. Now the defect is resolved and the checklist still has a failure on it, so the new blocker still blocks. Or run it the other way: someone un-fails the item because it was a mis-tap, and now the checklist is clean while the defect it raised is still open and still grounding the aircraft.

Two records describing one real-world fact, updated by different actions, diverging the first time anyone does something slightly unusual. That is the same disease as the seven predicates in the previous part of this series, arriving in a different costume.

#The decision

Failing an item requires a note, and raises a defect in the same transaction. If the item is critical, that defect grounds the aircraft.

The takeoff block then rides the gate blocker that already exists for an open grounding defect. No new gate condition. Nothing new to keep in sync, because there is nothing new.

And a failed item is immutable. Once it has raised a defect, the defect owns the lifecycle of that finding. You cannot un-fail the item.

That last rule looks harsh, and it is the one I would push back on if someone showed it to me without the reasoning. But un-failing an item while its defect stays open is exactly the divergence the whole change exists to prevent. A mis-tap is handled where the truth now lives: close the defect, with a note. The record then says what actually happened, which is that someone raised a concern and it was dismissed, and that is a more useful history than an item that silently un-failed itself.

#The model that made it click

The defect is the operational object; the checklist item is just where it was noticed.

A defect outlives the flight. It is assignable to an engineer. It can be deferred under a minimum equipment list with a reference and an expiry. It already blocks the gate. It is, in every sense that matters operationally, the thing the organisation acts on.

A checklist item is an observation at a moment. Giving it a parallel lifecycle, with its own blocking power and its own resolution path, would have created a second object that means almost the same thing as the first and gets out of step with it.

So: one finding, one object that owns it, and every other surface points at that object.

#What I would remember in six months

When a new state needs to block something, the first question is not "what should the new blocker be". It is "is there already an object that blocks this, for the right reason?" If there is, route into it. Adding a second blocker for the same real-world fact is how you get two answers to one question, and you will not find out which one is wrong until a user does something reasonable that you did not picture.

The other thing I keep: look for the state that is missing because it was inconvenient. The reason a checklist item could not be failed was not that anyone decided it should not be. It was that "failed" opens all the questions above, and "checked or not" opens none of them. A data model that only represents the happy path is not simpler. It has pushed its complexity onto the person holding the phone, and they will resolve it by lying to you, because you left them nothing else.