Measured, not asserted
Published
Every failure shape this series has measured over seventy passes ends in an answer that is wrong: a value missing, unreadable, in the wrong unit, over the wrong set, split the wrong way, off the wrong row, stopped short, or spent on the wrong obligation. An alert offers none of those. The limitation is computed correctly, the text is correct, the audit record is correct, and the only thing that moved is whether a human was told.
The answer can be perfect and still not arrive
The fixture is an operations system with two operational limitations for one departure: an inoperative weather radar and an aft hold placarded empty. Both are computed correctly upstream. Three recipients -- captain, first officer, dispatch desk -- on two crew-visible channels. Twelve delivered copies, six required acknowledgements, and a flight that dispatches only when all six arrive inside a fifteen-minute window.
Two caller-supplied rules guard it. The first is the one almost everybody writes: every limitation must have raised an alert. The second is the one this series has been recommending for three passes: reconcile against acknowledgements written by the recipients' own systems, not against your own dispatch record. The test models that honestly -- the crew application is a separate unprotected module that acknowledges what it actually received and reports as text, so an arm that stops the delivery really does produce an empty acknowledgement feed.
Renaming the distribution list dispatched the flight to nobody
One name. The list of recipients is a configuration key, so it cannot become unreadable; the library substitutes its own default, which is an empty list, because a generic alerting engine has no opinion about who should be told.
The run reported limitations=2 alerts-raised=2, both alert bodies correct and complete, recipients=0, deliveries=0, and then: ack=checked by ack-check(0 of 0 required acknowledgement(s) inside 15min) set=checked by alert-check(every limitation raised an alert: 2 of 2) => DISPATCH.
Both guards passed. Both sentences are true. The alerts really were raised, and zero of zero required acknowledgements really were received. The aeroplane departed with a crew that had never been told the weather radar was inoperative, and every record the system holds about that departure is accurate.
The reason the good check failed is worth stating exactly: it is defined over the recipient list, and the recipient list is the thing that went missing. An empty list of obligations is indistinguishable from a set of obligations that have all been met -- the same shape as an empty list of unmet prerequisites, or a recall traversal that found no consumers to visit.
The same empty delivery, caught cold
Two other arms produced exactly the same outcome on the wire -- nothing reached the crew -- and both were caught, loudly, by the same reconciliation.
Renaming the channel list reverted it to the library's default of its own log. The log is reachable and is read by nobody, so no copy reached a human. The roster survived, the reconciliation still required six acknowledgements, none arrived, and the dispatch was WITHHELD with ack-check(0 of 6 required acknowledgement(s); missing OL-7781/capt.oyelaran ...).
Renaming the delivery sink was sharper still. The engine substituted its own log sink, counted twelve deliveries, and reported sink=engine-log deliveries=12 log-only=12. The sender's own dispatch record says twelve copies went out. The far side received nothing, the reconciliation refused, and the flight was held.
So the mitigation is real. It caught a downgraded delivery channel and a downgraded sink cold, in a case where the sender's own record was entirely convincing. It could not catch the recipient list, because it counts against that list. The mitigation and its blind spot are the same design decision, seen from two sides.
Two alerts with no identity, and one acknowledgement covering both
The join key between an alert and its acknowledgement is a record field, and it produced the sharpest result in the area. With it renamed, both alerts carried an unreadable identifier, and two unreadable identifiers compare equal.
That deserved a purpose-built experiment rather than a claim, so it got one, with its own negative control. The crew application was changed to model the ordinary way an alert goes unread -- not a delivery failure but an attention failure: the first limitation was read and acknowledged by all three recipients, the second was never opened. The rule is positional, so the identity collapse under measurement cannot decide the far side's behaviour too.
The unprotected control refused, correctly: 3 of 6 required acknowledgement(s); missing OL-7782/capt.oyelaran and the rest. The renamed build, given the very same six acknowledgements, reported 6 of 6 required acknowledgement(s) inside 15min and DISPATCHED. The crew's acknowledgement of the radar limitation was accepted as an acknowledgement of the loading limitation they never opened.
An identity collapse turns a per-alert reconciliation into 'somebody acknowledged something'.
Delivered, acknowledged, and empty
One more arm belongs to this shape. Renaming the field carrying the alert text left the delivery machinery perfect: twelve copies, three recipients, six of six acknowledgements inside the window, dispatch approved. The bodies line printed bodies=[OL-7781:"undefined" OL-7782:"undefined"].
Everybody signed for an empty envelope. An acknowledgement proves receipt; it does not prove that anything was in the message. If your alerting matters, the reconciliation should carry something derived from the content -- a hash, a version, a limitation code the recipient echoes back -- so that acknowledging an empty alert is not the same event as acknowledging the real one.
What failed loudly, and the honest negatives
The acknowledgement keys the far side writes -- who acknowledged, and how many minutes later -- can only move on the reading side, because the text arrived over a boundary. Both refused: 0 of 6 acknowledgements matched, dispatch withheld. That is the direction you want, and it is the direction you get whenever the value you are reconciling against was written somewhere your build cannot reach.
Renaming the guard's ok field rejected the whole alert set. Renaming the enabling flag in front of the reconciliation dispatched the flight with the sender-side completeness check still printing 'every limitation raised an alert: 2 of 2' -- the quiet half switching off the loud one, for the twelfth area running.
The pinned control, a severity label set equal to the library default, measured identical on both targets as predicted.
If you ship alerting, escalation or on-call code
Confirm the effect at the recipient, never at the sender. This test is the cleanest demonstration yet in this series: the sender's record showed twelve deliveries in an arm where the far side received nothing, and it showed a clean, complete, honest zero in the arm where nobody was told at all.
Then count against an expectation that does not come from the same object as the thing you are counting. A reconciliation defined over the recipient list cannot notice that the recipient list is empty. Take the roster from the crew manifest, the on-call schedule, the duty roster -- some source that would not move if your configuration did -- and require that number of acknowledgements.
Make an empty distribution list an error. Nothing in this test threw, and nothing had to: dispatching an alert to nobody is a legitimate thing to ask a library to do, and it did it correctly. The only party that knows an empty list is nonsense is you.
And bind the acknowledgement to the alert. An identifier that can collapse, or a receipt that carries nothing about the content, turns a per-alert guarantee into an aggregate one without changing a line of your reconciliation code.
Frequently asked questions
Did obfuscation change any alerting behaviour on its own?
No. Five areas were run through five presets and every protected output matched the unprotected run -- twenty-five comparisons, no differences. Every failure here required member renaming aimed at a name the installed alerting engine also reads.
What is different about this failure compared with the rest of the series?
Every other measured shape ends in a wrong answer. This one ends in a right answer that nobody received. The limitation, the alert text and the audit record were all correct; only the delivery moved, and every check that reasons about the alert passed.
How did both guards pass while the alert reached nobody?
The completeness rule asks whether every limitation raised an alert, which was true. The acknowledgement rule counts acknowledgements against the recipient list, and the recipient list was the name that went missing, so it required zero and received zero. An empty list of obligations looks exactly like a set of met obligations.
Did reconciling against the recipients help at all?
Yes, twice. It caught a channel list that reverted to the library's own log, and it caught a delivery sink that reverted to the library's log while the sender's record still claimed twelve deliveries. It fails only when the roster it counts against is itself lost.
What did the identity collapse do?
Both alerts carried an unreadable identifier and two unreadable identifiers compare equal, so any acknowledgement matched any alert. In a purpose-built experiment with its own control, six acknowledgements for a limitation the crew did read were accepted as full acknowledgement of a second limitation they never opened -- the control refused the same feed at 3 of 6.
Can an acknowledgement be meaningless even when it arrives?
Yes. Renaming the field carrying the alert text delivered twelve copies with an empty body and collected all six acknowledgements. Acknowledgement proves receipt, not content, unless the receipt carries something derived from the message.
What is the cheapest fix?
Count acknowledgements against a roster that comes from a different source than your alerting configuration, make an empty distribution list an error, and bind the receipt to the alert. All three are worth having regardless of obfuscation, because a bad configuration file produces the same silence.
Related reading