The six-week gap
A component fails on a fleet aircraft in week seven. The failure mode was described in a service bulletin published in week one. Six weeks of flying happened in between, on every aircraft carrying that part, and nobody connected the bulletin to the fleet until the failure made the connection for them. This is not a rare embarrassment. It is the default outcome of a process that depends on a person noticing a publication, remembering that the fleet is exposed, and acting before the exposure becomes an event. The bulletin was read. The instruction was clear. What failed was the noticing, at the moment it mattered, against the noise of everything else a reliability engineer does in a week.
Call this what it is: a prospective memory failure, industrialised. The engineer's retrospective memory is fine — ask her what the bulletin said and she will tell you accurately. The task that failed is the one cognitive science calls time-based prospective memory: remembering to act with no external cue forcing the moment, only a clock and a competing inbox. Aviation maintenance runs on hundreds of these tasks simultaneously — recurring inspections, life-limited part tracking, airworthiness directive compliance windows — and treats each as a scheduling problem. The bulletin case shows the scheduling framing is wrong. Nobody scheduled a check for week one, because in week one there was nothing to check against. The evidence arrived; the task did not exist until it did.
What arrives
Four streams run into a reliability desk and none of them stop. Sensor telemetry comes off the fleet continuously — vibration spectra from engine monitoring units, exceedance reports from flight data recorders, oil debris counts from magnetic chip detectors, dozens of parameters per flight leg, most of it unremarkable. Service bulletins and airworthiness directives arrive from manufacturers and regulators on their own irregular schedule, sometimes three a week, sometimes none for a month, each one a claim about a failure mode discovered somewhere else in the world's fleet. Incident and occurrence reports arrive from the operator's own line stations and from shared industry databases, often weeks after the event they describe, frequently revised as investigation continues. Parts provenance arrives more slowly still — serial numbers, repair histories, time-since-overhaul, the chain of custody for every rotable that has moved between the shop, the wing, and another operator's fleet entirely.
None of these four streams announces its own relevance to any other. The telemetry does not know a bulletin exists. The bulletin does not know which serial numbers on this operator's ramp are exposed. Provenance data does not know a spike in vibration on tail number 6 last Tuesday might matter to it. The four streams are separately maintained, separately timestamped, and in most operations separately owned. That separation is the condition the bulletin case exploited.
What is held
The alternative to scheduling is holding — keeping every relevant belief live, dated, and traceable to the evidence that produced it, rather than closing the file once a check has been logged. For each fleet component this means a standing record: current understanding of its failure modes, each one attributed to a specific bulletin, incident report or telemetry pattern; current exposure, meaning which serial numbers on which aircraft carry it, sourced from provenance data that is itself dated; and current confidence, because a failure mode reported once from a single operator is not the same belief as one confirmed across an industry database.
This is the part that a filing cabinet full of bulletins cannot do. A cabinet holds the document. It does not hold the cross-reference between the document and this fleet's serial numbers, updated as aircraft are swapped, parts are exchanged, and new telemetry arrives. Holding a belief with provenance means the belief can be revised the moment any one of its supports changes — a new bulletin narrows the failure mode, a telemetry pattern strengthens suspicion of a specific tail number, a provenance record shows a part thought remote is in fact on the ramp today.
What triggers revision
Revision is not a calendar entry. It is a match between an incoming item on one stream and a standing belief built from another. The bulletin published in week one describes a failure mode tied to a manufacturing batch. The instant it arrives, it is checked against the provenance stream: which serial numbers on this fleet belong to that batch. If the match exists, exposure is no longer zero, and the belief about this fleet's risk profile updates immediately, not at the next scheduled review. If telemetry from an exposed aircraft later shows a vibration signature consistent with the bulletin's description, that is a second, independent trigger, arriving from a different stream, striking the same belief.
This is the mechanical difference between a time-based task and an event-based one. Under the old arrangement, someone had to remember, unprompted, to go looking for a match between a new bulletin and the fleet roster — a self-generated cue with no environmental support, exactly the kind of prospective memory task the psychological literature finds least reliable. Under continuous intake, the bulletin's arrival is itself the cue, because the fleet roster it needs to be checked against is already there, already current, already watching for exactly this kind of match. The task has not become easier to remember. It has stopped needing to be remembered at all.
What the operator sees
The reliability engineer does not see four raw streams. She sees flags, and the value of the whole arrangement collapses if the flags are undisciplined. A flag worth acting on carries the bulletin or incident that raised it, the specific serial numbers it now implicates, the confidence behind that implication — one corroborating report, or five — and the date each supporting fact entered the record. A flag that lacks provenance is indistinguishable from noise, and noise is exactly what breaks trust in this kind of system.
That answerability is the entire discipline. It is also where most attempts at this kind of monitoring fail in practice, which brings the two strongest objections into view.
Two objections worth taking seriously
Automated checking of this sort is not new. Cron jobs, tickler files and SCADA alarms have automated scheduled reviews for decades. Continuous multi-stream intake is administrative tidying, not a new category of system.
This is correct about what such tools do, and wrong about what they cannot do. A scheduling system discharges an intention someone has already fully specified: check this parameter, on this interval, against this threshold. It cannot notice that a threshold nobody wrote down has just become relevant, because a manufacturer published something new about a failure mode last night. Every scheduled review encodes a guess, made in advance, about which check will matter. The bulletin in week one is precisely the case a schedule cannot anticipate, because the schedule was written before the evidence existed. What continuous intake with provenance changes is not the executing of checks but the sourcing of them: the trigger becomes a change in the evidence itself, not a date chosen in ignorance of what that evidence would later say.
Automating detection degrades the operator's own judgement. Intensive-care alarm studies find the overwhelming majority of alarms non-actionable, and staff learn to silence them. A reliability desk fed four continuous streams risks the same fatigue: remembering which of a thousand daily flags deserves attention becomes its own unmanageable prospective memory task.
This is the stronger objection and it should be conceded almost entirely. A system that streams everything and flags liberally manufactures exhaustion faster than it removes it. The only honest answer is that the claim being made here is not about alerting volume but about the structure behind each alert: a flag with attached provenance, confidence and revision history can be triaged; a bare alarm cannot. That structural requirement is not a refinement added on top of continuous intake — it is what continuous intake with provenance means, and a system that only sounds alarms without carrying their evidential weight has not reached the position this page describes.
What it does not do
Continuous intake does not decide which failure modes are worth watching, does not set the liability for a missed check, and does not choose between grounding a fleet and monitoring it more closely. Those decisions stay with people, and widening intake makes the consequences of getting them wrong larger, not smaller. The claim here is narrower: after every relevant stream is held continuously, with provenance, there is no further category of evidence left to add — only more volume, trusted better, over a longer span. That is a ceiling on what can be observed. It says nothing about who decides what the observation is for.