Building a reliable maintenance schedule for a 25-aircraft fleet requires pulling from at least five separate data sources, and most scheduling tools read from one, maybe two. The gap between what a plan assumes and what is actually true of the fleet usually lives in the four sources the tool does not read. This post walks through each source, what it contributes to the plan, and where the common data quality problems tend to sit.
1. Task cards and maintenance intervals
Task cards and interval data anchor the schedule. For each aircraft type, the maintenance program specifies required work: A-checks, C-checks, structural inspections, system operational checks, and lubrication tasks. Each task uses an interval based on flight hours, flight cycles, calendar time, or a combination. The task card ties that interval to an aircraft registration and captures the last completion date and counter value.
This information generally resides in the MRO system as the master schedule. Stale close-out records are the most common data issue. After a work order is completed, documentation can trail the actual work by a day or two, so the system may show a task overdue even though it finished last week. Tools ingesting records without currentness indicators can flag false conflicts and miss real ones in the same run.
Interval modification tracking creates another problem. Operators receive engineering orders or authority approvals that extend or change standard intervals. If those changes do not reliably reach the task card system, the planning tool uses the original interval and produces conservative due dates, leading to unnecessary early maintenance visits.
2. Aircraft utilization data
Utilization data turns interval due dates into calendar estimates. An aircraft due in 200 flight hours reaches that threshold on very different dates if it flies 18 hours per week instead of 45 hours per week. Without utilization data, the tool can only estimate.
The flight operations system supplies this information through individual records containing departure, destination, block time, and cycle count. Planning needs historical accumulated values to establish today's counter position and the forward flight schedule to estimate the next threshold. That estimate requires connecting the planned rotation to the maintenance planning system, a step most small operators skip.
Regional operators with irregular charter or ACMI flying face a tougher case. If the rotation changes weekly, a utilization estimate based on last month's pattern may be wrong by 20-30 percent. The resulting maintenance window can land too early or too late.
3. ADs and service bulletin records
ADs impose mandatory compliance requirements and specified deadlines. The applicable AD set depends on an aircraft's type, series, and modification status. The FAA and EASA publish new ADs continuously, so the publications requiring review increase for a mixed-type fleet.
Most MRO systems have AD tracking, but keeping it current requires someone to monitor publications, assess applicability for each registration, and enter compliance deadlines. Small operators may do this manually, creating a delay between publication and planning-system entry. Any tool reading this data must know whether it is current. If the AD module is a week behind, the resulting schedule has a week's blind spot for new compliance deadlines.
Service bulletins differ because compliance is usually voluntary unless an AD incorporates one. Operators may still choose compliance for reliability or cost reasons. The planning system must track SB status with ADs, allowing elected SBs to enter the same planning run as required work.
4. Parts stock and vendor lead times
Parts availability is a constraint planners often overlook until an AOG event exposes it. A visit requiring a component with a six-week vendor lead time cannot be scheduled in the next six weeks unless the part is stocked or available locally at a premium. A tool that schedules without parts data creates a theoretical plan that will often fail during execution.
This information usually sits in a separate inventory or ERP system. Integration must work both ways: the planning tool reads current stock to assess upcoming visits and sends parts demand signals to procurement. Without those signals, procurement responds to the schedule instead of preparing for it, making lead-time misses recurring.
Older aircraft types add a parts constraint newer fleets may avoid. Components for a type out of production for a decade often come from the secondary market, where lead times are unpredictable and condition records vary. The planning tool must allow for that uncertainty by using longer parts windows for known constrained components, rather than assuming catalog lead times.
5. Hangar and base capacity
Even an optimized schedule fails when two aircraft needing hangar time reach the same base on the same day and only one slot exists. Base capacity is a scheduling input, not an output, yet most tools leave the planner to resolve it manually after generating the plan.
Relevant data includes which aircraft can receive which maintenance types at each base, simultaneous aircraft capacity at each location, and crew certification coverage by base and shift. For operators using multiple bases, it also determines whether a check goes to the home base or a contract MRO provider, with different effects on cost, lead time, and parts logistics.
Reconciliation problem
These five data categories usually sit in separate systems, each maintained on a different cadence by a different team. Task cards may change weekly. Flight records may update daily or near-real-time. Parts inventory changes with every purchase order and consumption event. AD tracking may change manually when someone reviews the latest publications.
Even with all five inputs, a planning tool must reconcile them into a consistent, sufficiently current view. A maintenance schedule has a limited shelf life. A Monday schedule assuming N4823K has 140 hours left before its next C-check is wrong on Thursday if a route change adds three cycles. The practical test is not whether the system reads all five sources, but how quickly it can rebuild the schedule when any input changes.
We built Tailsight's ingestion layer for this reconciliation problem. We are not saying it replaces the systems of record for these five sources. We are saying it should read them often enough for the generated schedule to match the fleet's actual condition when the planner makes a decision.