Conjugate updating and sufficient statistics in aviation maintenance

A bleed valve, six weeks late

On the morning of the fifth cabin-pressure excursion, the reliability engineer pulled the log for tail number N-plate 4471 and found the answer sitting in a service bulletin dated six weeks earlier. The bulletin described a batch of outflow valve actuators with a moulding defect that let the diaphragm crack under thermal cycling — precisely the fault now showing up as intermittent pressurisation faults across a dozen airframes. The bulletin had been issued, distributed, filed. It sat in a document management system alongside eleven thousand other advisories. Nobody had connected it to the maintenance records showing which aircraft actually carried that batch's part numbers, because that connection required cross-referencing parts provenance against a document corpus that nobody re-reads once it has been filed.

The fleet flew for six weeks on a known failure mode. Four of the five excursions happened at altitude, over water, on aircraft whose maintenance crews had no reason to suspect the actuator because the bulletin had never been matched to their tail number's parts history. This is not a story about a missed inspection. It is a story about an organisation that ingests everything and integrates almost nothing. The telemetry streamed in. The bulletin arrived on schedule. The incident reports, once the faults started, were filed within hours. Every stream was live. None of them were talking to each other, and nobody had a mechanism for turning six weeks of accumulating evidence into a single number that moved when a new fact landed.

What actually failed

The proximate cause was traceability: a batch code buried in a parts database, a bulletin filed by document number rather than by affected serial numbers, telemetry evaluated stream-by-stream rather than against a belief about actuator reliability that both streams should have updated. But the deeper failure is architectural. The maintenance organisation had no running estimate of "probability this actuator fails in the next 500 cycles, given batch, given service bulletin, given telemetry." It had documents and it had sensor feeds, and between them a person was expected to notice a pattern across eleven thousand advisories and a fleet's worth of readings. That is not a staffing problem. It is a problem of what kind of object a belief is allowed to be.

The object it should have been is a posterior distribution over failure probability, held per component batch, updated the moment each new piece of evidence lands, and cheap enough to hold for every batch in the fleet simultaneously. This is where conjugate updating and sufficient statistics stop being a textbook curiosity and become the design principle that was missing.

The two-number fix

Model actuator survival with a Beta prior over the failure probability of a given batch, updated by a Bernoulli or Binomial likelihood each time a unit fails or is retired healthy. The posterior after any amount of evidence is still a Beta distribution — same family, only the two parameters move. Call them successes and failures, or in maintenance terms, cycles survived and failures observed. A batch with no history starts at some weak prior, say two survivals and zero failures inferred from a similar part family. The service bulletin, when it finally gets parsed, is itself evidence: it converts to a strong prior shift, equivalent to informing the model that this batch's moulding defect behaves like dozens of the failures already seen in other fleets. The telemetry stream, instead of being read for anomalies in isolation, becomes a trickle of Bernoulli trials feeding the same two counters. A thousand more flight-hours across the fleet still needs two numbers per batch. Ten thousand hours needs the same two numbers.

This is why the delay was avoidable in principle without asking anyone to read faster. The bulletin's information and the telemetry's information belong to the same sufficient statistic. Had the reliability engineer's system treated "successes and failures for this actuator batch" as the object of record, the bulletin's arrival would have moved that number immediately, and the very next telemetry sample showing early diaphragm strain would have pushed the posterior mean past a maintenance threshold within days rather than weeks. The recursion is: observe, update the pair of numbers, discard the observation. Nothing about the six-week delay was a data volume problem. It was a failure to run the update at all.

Why this generalises past one valve

The Large Language Model reads its corpus once; its belief is the weights, frozen at training's end, with no mechanism to fold in tomorrow's bulletin. The Large World Model filters a scene — a cockpit's current sensor state, a single approach, a bounded window — which is recursion in the small, closing over one flight rather than over the fleet's history. A Large Universe Model is the claim that the same recursive machine that updates the Beta parameters on one actuator batch can be run, in parallel, over every stream an airline actually has running: sensor telemetry from every tail number, every bulletin as it is issued, every incident report, every parts shipment with its batch code attached. Sufficiency is what makes this affordable. The belief for each batch, each failure mode, each maintenance-relevant quantity, stays fixed-dimensional no matter how many more cycles the fleet flies.

The provenance problem, honestly stated

Two counters cannot tell you how much of an actuator's failure rate came from the batch defect versus normal wear once the batch mixes with others in the fleet-wide pool. If the bulletin is later retracted — the defect was actually a testing artefact, not a real fault — you cannot subtract it back out.

This objection lands squarely on aviation maintenance, where retraction happens: bulletins get superseded, root-cause investigations reverse initial findings, a batch thought defective turns out to have a sensor calibration issue instead. A single pooled Beta posterior across an entire fleet cannot be unwound cleanly if one input source is later discredited. The fix is not to abandon sufficiency but to partition it: keep separate sufficient statistics per batch, per bulletin source, per airframe cohort, and recombine them at query time rather than pooling permanently. Retracting a bulletin then means subtracting its counters from the relevant batch's pair rather than re-deriving a fleet-wide estimate from raw records. This works cleanly because Beta-Binomial counts are additive. It stops working cleanly the moment the quantity of interest is something non-additive — a nonlinear degradation curve, say — at which point exact retraction becomes expensive again. The honest position is that provenance-aware auditing is affordable in proportion to how many buckets you were willing to keep separate, and that is a design decision made before the data arrives, not something sufficiency grants for free.

The drift problem, also honest

The second objection cuts deeper for a reliability engineer specifically. A Beta posterior's variance shrinks as evidence accumulates — confidence grows monotonically the longer a batch flies without failure. But actuator failure modes are not stationary. A diaphragm degrades with thermal cycling in ways that depend on ambient conditions, flight profile, maintenance intervals actually performed rather than scheduled. A model that has quietly grown confident over six months of clean telemetry can be exactly wrong at month seven, when a route change starts exposing the actuator to different thermal stress. Constant-memory updating buys efficiency by discarding the raw history that might have shown the drift starting.

The mitigations are known in this domain and each costs something back: forgetting factors that discount older evidence so the posterior stays responsive, covariance inflation scheduled around known maintenance events, explicit change-point priors that flag when a batch's behaviour looks statistically different from its own history, and — the least elegant but most reliable — holding out a sample of raw telemetry for goodness-of-fit checks rather than folding everything into the running counters. None of these are free. Each reintroduces some memory or some tuning that plain conjugate updating was supposed to avoid. The consequence for the reliability engineer is not that the two-number belief is wrong to use, but that part of the fleet's monitoring budget has to go to asking whether the model is still the right model, not just what its parameters currently say.

What the terminal rung actually buys

The lineage claim is not that a Large Universe Model would have caught the valve fault by magic. It is that the architecture needed to catch it — every stream treated as evidence against a running belief, updated in fixed memory, partitioned for provenance, periodically audited for drift — is already the complete list of things intake can demand. There is no fourth kind of stream beyond sensor telemetry, published advisories, incident reports and parts history that a maintenance organisation could add to close the gap further. What is left is not a new category of observation. It is doing the arithmetic on the streams already running, before the bulletin sits in a folder for six weeks doing nothing.