Measured, not asserted
Published
A deferral is a membership question before it is an arithmetic one. Is this item on the list at all? Only then: which category, and how many days does that allow? This test renamed the single key that answers the first question and watched an inoperative engine fire-detection loop -- equipment that is not on the list, and may not be deferred -- dispatch with the line 'dispatch permitted by policy'. The operator's own deferral check never ran, because it sits after the branch that decided.
Membership comes before arithmetic
The fixture carries a three-item list -- a lavatory fan at category D, a seat at category C, a weather radar at category B -- with repair intervals of 120, 10 and 3 days, a placard requirement, and a policy that an item not on the list may not be deferred at all.
Four defects are presented on one departure. The lavatory fan was deferred 46 days ago and placarded: legal. The weather radar was deferred nine days ago on a three-day interval: six days expired, no dispatch. The seat is well inside its interval but was never placarded: no dispatch on the second, independent control. The fire-detection loop is not on the list: no dispatch, because it is not deferrable at all.
As always in this series, protection on its own changed none of it. Twenty-five base comparisons across five presets, all identical.
One policy key, and an undeferrable item dispatched
The policy that an unlisted item may not be deferred is a configuration key, and configuration keys do not go missing -- the library substitutes its own default. This library's default is permissive, and it is right to be: a generic dispatch-rules engine cannot know which equipment your certificate requires.
With that key renamed, the fire-detection loop dispatched, printing unlisted(ATA-26-FIRE-LOOP is not on the list, dispatch permitted by policy => DISPATCH). The other three decisions were unchanged and correct.
The detail worth taking away is what did not happen. The operator supplied a deferral rule, and the engine reports it as installed. It never ran on that defect, because the unlisted branch returns before the check is reached. A guard placed after a fallback cannot see the fallback -- and 'is the deferral rule installed?' returns a true answer to the wrong question.
Losing the list as well made every defect dispatchable
Renaming the list and the policy key together produced four lines of unlisted(... dispatch permitted by policy => DISPATCH), including the weather radar whose repair interval expired six days ago. The list evaporated, the fallback permitted, and the engine reported a successful dispatch four times.
Renaming the list on its own did the opposite: with the operator's strict policy still in force, all four defects were refused as not on the list. The fleet stops, somebody investigates within the hour, and the fault is found. That is the cheap failure again.
An unreadable elapsed count is not zero, it is uncomparable
The date a defect was deferred is a record field, and record fields can genuinely become unreadable. With it renamed, the elapsed days became NaN, and the comparison that refuses an expired deferral -- elapsed greater than the interval -- is false against NaN.
The expired weather radar dispatched. And the operator's rule passed, printing checked by deferral-check(category B, NaNd of 3d used).
Look at that string. The guard printed the exact value it consumed, which is the improvement this series recommended two passes ago, and it approved anyway -- because it was written to check that the interval is finite, and the interval was. Printing the consumed value is worth doing; it is not a substitute for requiring the value to be finite before comparing it.
Categories, placards and the per-record masking
Renaming the category on the list rows made every category unreadable, and the operator's rule refused: no category, no dispatch. Renaming the category interval table did the same. But renaming only the category B entry inside the interval table touched exactly one aeroplane's worth of decisions -- the weather radar was refused, the other three defects were judged correctly, and the configuration dump still showed the entry present under its new name.
That is the same per-record masking measured in the mortgage and transfer-credit areas of earlier passes. Spot-checking one departure proves nothing about the others, because a rename that reaches one row of a table leaves every other row exactly right.
The placard control behaved as the second independent layer it is: renaming the placard field refused every defect, and renaming the requirement itself let the unplacarded seat dispatch quietly.
What failed loudly
The defect identifier produced unidentified-defect(refused before evaluation). The guard's ok field turned every deferral into deferral-rejected. The pinned control -- the category label, set equal to the library default on purpose -- measured identical on both targets, as predicted.
The now familiar split held again: values fail closed, meanings fail open. Every quantity in the file refused; every key that says what a quantity means, which list governs it, or whether the list is binding at all, opened the door.
If you protect a dispatch or technical-log application
Put the strict policy where a fallback cannot reach it. If your operation refuses to dispatch unlisted equipment, that refusal belongs at the point the item fails to resolve, not in a rule that runs afterwards on items that did resolve.
Require the elapsed interval to be finite before comparing it, and refuse when it is not. That one line is the same fix this series has recommended since the risk-scoring pass, and it is the fix the NaN result in this area walked straight past.
And treat a lookup miss as an error rather than a policy. In a dispatch engine, 'I could not find this item' and 'this item is permitted' should never be the same outcome, whatever the library's default happens to be.
Frequently asked questions
Did obfuscation change any dispatch decision on its own?
No. Five areas across five presets produced twenty-five identical comparisons. Every result here required member renaming aimed at a name the installed dispatch engine also reads.
What did renaming the unlisted-item policy do?
It reverted to the library's permissive default and an inoperative engine fire-detection loop -- equipment that is not on the minimum equipment list and may not be deferred -- dispatched with the line 'dispatch permitted by policy'.
Why did the operator's deferral check not catch that?
Because it sits after the branch that decided. The unlisted case returns before the check is reached, so the rule was installed, reported as installed, and never consulted. A guard placed after a fallback cannot see the fallback.
What happened to the expired deferral?
Renaming the date the defect was deferred made the elapsed count NaN. The comparison that refuses an expired deferral is false against NaN, so a weather radar six days past its three-day repair interval dispatched, and the guard printed 'category B, NaNd of 3d used' while approving it.
Was any arm safe?
Renaming the list alone refused all four defects, because the operator's strict unlisted policy was still in force. The loud failures are the ones you find; it is the combination of the list and the policy that dispatched everything.
Does renaming one table entry matter?
Yes, and it is the hardest cell to find. Renaming a single category entry moved exactly one defect's decision and left the other three correct, with the value still visible in the configuration dump under its new name. Spot-checking one departure proves nothing about the rest.
What is the cheapest fix?
Refuse at the point of the lookup miss rather than in a rule that runs afterwards, and require the elapsed interval to be finite before comparing it. Both are worth having regardless of obfuscation.
Related reading