Skip to content

Tracking forecast integrity

Maintenance-tracking source reconciliation

Maintenance-tracking source reconciliation confirms that a tracking system's computed forecast still rests on the source records after a migration or provider change. It is run when a fleet's tracking moves systems and the due-list has to be re-trusted. It covers the task definitions, interval rules, and last-done dates the system computes against, checked back to the work that justifies them. You receive a reconciliation register, a list of tasks whose forecast is not supported by the records, and a corrected basis for the affected items.

When this review is needed

  • A fleet's maintenance tracking has moved to a new system or provider and the due-list must be trusted.
  • Task setup was carried over in bulk and the interval rules were never verified against the records.
  • The new system's forecast disagrees with the planning team's expectations.
  • An audit will check whether the tracking forecast is grounded in the underlying work.

The problem

A tracking system is only as good as its setup. When tasks, intervals, and last-done dates are migrated in bulk, an error in a single rule quietly shifts the whole forecast for that task. The system produces a confident due-list, but nobody has checked that the intervals and the last-done dates match the work the records actually show.

What gets reviewed

  • Task definitions and interval rules checked against the maintenance program
  • Last-done dates and counters reconciled to the source work packages
  • AD and SB tasks set up with the correct trigger and interval
  • Component time and cycle status feeding the forecast
  • Tasks whose computed due position the records do not support

Scope this review

Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.

Send a representative, redacted record set and we will scope the review.

What gets validated

  • Interval rules in the system match the program the fleet operates to
  • Last-done dates reconcile to the source work package that accomplished the task
  • AD and SB tasks compute from the correct trigger, threshold, and repeat interval
  • Component counters feeding the forecast agree with the recorded time and cycles
  • A spot-check of computed due dates against source confirms the rule, not just the value

Evidence normally required

  • The tracking system's task list, intervals, and computed due-list
  • The maintenance program defining the intervals
  • Source work packages establishing last-done dates
  • Component time and cycle status records

Common discrepancies

  • An interval rule migrated incorrectly that shifts every due date for the task
  • A last-done date that does not match the work package that accomplished it
  • An AD task set to the wrong threshold or repeat interval
  • A component counter that disagrees with the recorded status

What is at stake

A forecast built on a mis-migrated interval can call work early, wasting slots, or late, creating an overrun the records will not support. Across a fleet a single bad rule repeats on every affected tail, and the error is usually found at a check rather than in the system.

How the work runs

01

Pull the computed due-list

Export the task list, intervals, and forecast from the new system.

02

Check the rules

Confirm interval and trigger setup against the maintenance program.

03

Reconcile last-done

Tie each last-done date to the source work package that accomplished it.

04

Correct the basis

Flag tasks the records do not support and re-establish the correct setup.

What the buyer receives

  • A reconciliation register comparing computed forecast to source
  • A list of tasks whose forecast the records do not support
  • A corrected basis for the affected task setups

Who uses the output

  • Maintenance planners relying on the due-list to schedule slots and checks
  • Continuing-airworthiness teams accountable for the forecast at audit
  • Records and systems staff correcting the task setups that drove bad dates

How the work fits into the transaction or program

Reconciliation runs after a tracking migration or provider change, before the planning team commits the new due-list to a schedule. The corrected task basis it produces is what the forecast and the slot plan are then built on.

Start with a single asset

Prove the review on a single tail, then scale across the fleet.

Regulatory limits

Reconciliation confirms the computed forecast rests on the source records and the program intervals. It does not approve the maintenance program, set intervals on an authority's behalf, or warrant the tracking software.

What this review does not cover

  • Configuring or operating the tracking system itself
  • Setting or approving maintenance program intervals
  • Scheduling or accomplishing the maintenance the forecast calls

Specific to this review

  • A single mis-migrated interval rule repeats across every tail it applies to, so one setup error becomes a fleet-wide forecast error.
  • The system reports a confident due date even when the last-done date behind it is wrong, which is why the forecast is checked against the work package.
  • Errors in tracking setup usually surface at a check rather than in the system, when a task is found called early or run late.

Sources

Frequently asked questions

How is this different from reconciling status to source records?

Status reconciliation checks reported position. This focuses on the forecast: the task definitions, intervals, and last-done dates the tracking system computes the due-list from, since an error there shifts future planning rather than current status.

Relevant glossary terms

Related pages

Where this fits

Talk to an engineer who has done this work

We will walk through your current state, the records or evidence involved, and a scoped first engagement.

Walk through your situation with an engineer who has done this work.