Aircraft Reliability Signals Need Exposure, Not Just Counts

Executive summary

Maintenance organizations already possess abundant event data: pilot reports, defects, task findings, component removals, delays, cancellations, aircraft health messages, and increasingly rich telemetry. The hard problem is not collecting another event. It is constructing a denominator and comparison population that make the event interpretable.

FAA AC 120-17B describes reliability performance standards as numerical measures such as numbers, rates, ratios, or percentages over operating periods including flight cycles, flight-hours, operating hours, or calendar time. It also says control limits or alert values should use accepted statistical methods and be adjustable for operational experience and factors such as fleet age, seasonal, operational, and environmental conditions. That is a useful design constraint for digital reliability systems: counts are evidence, but counts without exposure and effectivity are weak signals.

1. Why the denominator is an architecture concern

A dashboard can calculate removals per 1,000 flight hours only if its event and exposure populations refer to the same aircraft, time window, configuration, component position, and operating definition. If maintenance events arrive from an MRO platform while cycles and hours come from operations or aircraft data, identity becomes part of the reliability calculation rather than a data-cleaning detail.

The platform therefore needs durable business keys for tail, part number, serial number, position, and maintenance event; configuration history with effective dates; event-time rather than ingestion-time semantics; and explicit rules for which exposure qualifies for each metric. When any of those are unresolved, the system should surface the uncertainty rather than quietly produce a precise-looking rate.

2. Reference architecture: evidence to reliability signal

The following flow deliberately separates operational evidence, identity/effectivity, analytical signal generation, and human authority. It is not a prescription for an operator's approved reliability program.

Design reading: defects and removals supply numerators; flights, cycles, hours, or another justified operating measure supply denominators. Identity and effectivity decide whether those populations are comparable. Statistical logic identifies deviation. Reliability and engineering functions decide what the evidence means and what action, if any, belongs in the approved program.

3. Build a reliability signal as an evidence object

A useful signal should carry more than a red or green status. Store the metric definition, numerator events, exposure denominator, population filters, configuration/effectivity, observation period, baseline period, statistical method, control or alert value, data-quality exceptions, source lineage, and the version of the logic that produced the result. That makes the signal reproducible and reviewable.

This also prevents a common modernization failure: treating the visualization as the product. A chart is only a projection. The durable product is the evidence object behind it, which can support a dashboard, investigation case, audit trail, model feature, or later reprocessing when a data-quality defect is corrected.

4. AWS pattern: keep the event history replayable

A practical AWS implementation can ingest high-volume aircraft or operational events through Amazon Kinesis Data Streams and route lower-volume domain events through Amazon EventBridge. Amazon S3 can retain immutable raw envelopes and curated history. AWS Glue can normalize bulk and file-oriented sources, while compute services derive exposure windows and reliability projections. AWS's aircraft predictive-maintenance guidance similarly combines aircraft flight logs or ACARS/QAR data, MRO records, operations events, Kinesis, S3, Glue, Lambda, and analytical/modeling services.

For reliability engineering, replayability matters. If a serial-number mapping is corrected or a metric definition changes, historical signals may need to be reconstructed. AWS Prescriptive Guidance describes event sourcing as retaining state-changing events so state can be reconstructed and audited. Where messaging can duplicate delivery, consumers should be idempotent; dead-letter handling and replay paths should be designed rather than improvised after the first production incident.

5. Statistical alerting without dashboard theater

FAA AC 120-17B discusses control limits and alert values based on accepted statistical methods, including standard deviation or Poisson approaches, while allowing other acceptable methods. That does not mean hard-coding one universal formula. Event processes differ in distribution, exposure volume, seasonality, fleet maturity, and sample size.

Keep the metric contract separate from the detection method. A mature fleet and component population may support a stable baseline and control limit. A new fleet may need observation before limits are meaningful. Sparse events may require aggregation or a different model. Put the observation count and exposure beside the alert; reviewers need to see when an apparent deviation rests on a small sample.

6. Where AI helps, and where it should stop

AI can cluster free-text defects, retrieve similar cases, summarize evidence, suggest failure themes, or move a case higher in the review queue. It can help an engineer work through a large evidence package. It cannot invent the denominator, quietly merge incompatible configurations, or turn a statistical deviation into an approved maintenance-program action.

Keep deterministic calculations, source facts, model classifications, and generated narrative visibly distinct. Retrieved evidence needs provenance. When identity, effectivity, exposure, or source quality is weak, the system should say why it is stopping. A clear refusal is more useful than a confident answer built on the wrong population.

7. A disciplined implementation sequence

1. Select one reliability metric whose numerator and denominator are already understood by reliability engineering.
2. Define identities, effectivity, event time, qualifying exposure, and exclusions before building the dashboard.
3. Create an immutable evidence object and reproduce several historical cases from source records.
4. Run the signal in shadow mode against the existing reliability process.
5. Measure false alerts, missed deviations, data-quality failures, and reviewer overrides.
6. Add AI only after the deterministic evidence path is trustworthy.
7. Integrate review outcomes back as new evidence without allowing analytics to bypass approved authority.

Editorial note

This article is independent engineering analysis and a reference architecture. It is not approved maintenance data, an operator reliability-program procedure, regulatory interpretation, or a claim about any airline's implementation. AWS services are illustrative architectural choices. Statistical methods, alert values, program actions, and maintenance decisions must be established by the applicable operator under its approved processes and qualified authority.

Sources

• FAA AC 120-17B, Reliability Program Methods—Standards for Determining Time Limitations (active; FAA editorial update July 9, 2026)
• FAA AC 120-17B, Chapter 4: Performance Standards System
• AWS Guidance for Aircraft Predictive Maintenance
• AWS Prescriptive Guidance, Event sourcing pattern
• AWS Prescriptive Guidance, Publish-subscribe pattern