When we talk to MRO planners about connecting their existing systems to a demand forecasting layer, the first question is almost always about the integration: does this require an IT project? How long does it take to get data out of AMOS or CESIUM in a usable form? What happens to data that is inconsistent or missing?
These are the right questions. The data layer is where most forecasting projects stall, not because the algorithms are difficult but because the source data contains structural issues that take time to understand and clean. This article covers what we have seen in practice when pulling removal history from the two most common MRO management systems used by small-to-mid-sized carriers and MRO shops.
What AMOS and CESIUM Were Designed to Do
AMOS (Aircraft Maintenance and Operations Software) and CESIUM are both mature platforms designed primarily for airworthiness record-keeping, work order management, and regulatory compliance documentation. They are very good at those jobs. They maintain structured records of every component removal, the reason code, the work order it was attached to, the component's part number and serial number, and the aircraft registration it came from.
What they were not designed to do is produce the kind of structured time-series output that a demand model needs as input. When you export removal history from AMOS via a standard report or a database query, you get a table of events: removal date, part number, serial number, work order reference, reason code, aircraft. That is not the same as a time series of demand rates with associated utilization denominators (flight hours and cycles), which is what makes the demand signal interpretable across tails with different utilization patterns.
Getting from the raw removal table to a forecasting-ready dataset requires joining it to the utilization records, which live in a different part of the database schema, and normalizing removal rates per flight hour or cycle rather than treating raw event counts as comparable across tails.
The Specific Data Issues We See Most Often
After working through data from several early-access operators, we have seen a fairly consistent set of data quality issues that need to be resolved before any forecasting can happen.
The most common is part-number inconsistency. An LRU may have been logged under different part numbers at different times, either because an approved equivalent was substituted and the substitute's part number was used, or because the part number itself was superseded by the OEM and older records use the old number. A demand model treating these as different parts produces incorrect demand histories for both. Mapping part-number variants to a canonical identifier is a manual step, but it has a major impact on model accuracy for high-criticality parts.
The second common issue is incomplete reason codes. AMOS and CESIUM both support structured reason code fields on removal records, distinguishing between scheduled removals at hard-time limits, on-condition removals triggered by inspection findings, and unscheduled removals triggered by in-service failures. A demand model needs to distinguish these categories because they have different demand distributions. A hard-time removal is scheduled and predictable; an on-condition removal has a different uncertainty profile; an unscheduled failure is the event planners are trying to anticipate. When reason codes are missing or inconsistently applied, the model cannot make this distinction cleanly.
Third, tail-number to utilization linkage is sometimes broken for archived records. Operators who have changed fleet registration, bought aircraft from another carrier, or migrated data from an older system often have removal records that cannot be joined to utilization data because the registration field changed at some point in the history. This is manageable for recent history but can significantly reduce the usable depth of historical data for parts with long removal intervals.
What the Data Export Process Actually Looks Like
For operators using AMOS, the most reliable path to clean removal history for forecasting is a direct database export using SQL queries against the backend schema, rather than relying on the built-in report modules. AMOS's report layer is well designed for compliance documents but produces outputs that are difficult to programmatically process for time-series analysis. The underlying schema is accessible and well-documented for operators who have a DBA or a maintenance systems team member with database access.
For CESIUM, the situation is similar but the export path differs slightly. CESIUM has stronger CSV export functionality in recent versions, and the data structure is somewhat flatter, which makes it easier to extract a workable removal event table without a custom database query. The challenge with CESIUM data is typically the reason-code completeness issue mentioned above, because the platform's UI makes it easy to close a work order without populating the reason code field, and many operators have years of records where that field is blank.
For Aerotrax's pilot process, we ask operators to provide a CSV export covering the last three to five years of removal events with the following fields: removal date, part number, work order type (scheduled or unscheduled), aircraft registration, and flight hours and cycles at removal. That is enough to build an initial demand model and identify where the data quality issues are most likely to affect forecast accuracy.
How Long Does It Take Before Forecasts Are Usable
The honest answer depends on how complete and consistent the source data is. For an operator with clean, well-coded removal records in AMOS or CESIUM, covering at least 24 months of history across the fleet, the first usable demand bands are typically available within one to two weeks of receiving the export. That accounts for data normalization, part-number mapping, and initial model fitting.
For operators with significant data quality issues, the timeline extends. The part-number mapping step in particular is not something a script can do reliably without domain input. It requires someone who knows the part catalog to review the list of variant numbers and confirm which ones are approved equivalents and which are genuinely different parts. A planner who does this job daily can move through the list relatively quickly, but it is not zero effort.
We want to be clear that the integration work described here is not a technology failure or a gap in either AMOS or CESIUM as platforms. Those systems do exactly what they were designed to do. The data preparation work is an inherent consequence of connecting a system built for compliance record-keeping to a system built for predictive analytics. The two have different data structure requirements, and that gap has to be bridged somewhere. Our goal is to make that bridging as lightweight as possible for the operator.
What You Get at the End of the Process
After the data preparation work is done, the demand model has a removal-rate distribution for each part-variant-fleet combination that appears in the history. For most operators, this covers somewhere between 150 and 400 part numbers with enough removal history to produce statistically meaningful probability bands.
For parts with very few historical removals, typically anything with fewer than four to six removal events in the dataset, the model supplements the operator's own history with cross-fleet priors derived from similar fleets running the same aircraft type. This cross-fleet weighting is one of the core reasons the model produces actionable output even for small fleets that would not have enough data on their own.
The output format is a demand forecast table: part number, 30-day removal probability, 60-day removal probability, 90-day removal probability, and a recommended stock position given a target service level (typically set at 95% or 98% depending on the part's criticality classification). The planner can compare this against their current on-hand position and open purchase orders to identify gaps and surpluses without having to run any analysis themselves.
See Aerotrax on your own fleet data
30-day pilot on your removal history. CSV upload, no integration project required.
Request a pilot