Fly What You Signed Off: Why Maintenance Training and Flight Simulation Belong in One Loop

Maintenance courseware and flight simulation are traditionally different products, bought on different contracts, often from different vendors. The mechanic clicks through procedures in one system; somewhere else, a pilot flies a pristine aircraft in another. What falls into the gap between them is the one thing maintenance training exists to teach: consequence. In a courseware-only world, signing off a task costs nothing. The "aircraft" it releases is a completion checkmark.

The loop

1. 01In the trainer, the student explores the airframe in 3D, runs guided removal and installation procedures, and passes knowledge checks.
2. 02Before flight, a pre-flight maintenance stage presents real tasks from that same catalogue and asks how each one was performed — the correct method against plausible errors: under-torqued, over-torqued, safety wire omitted, wrong consumable. The student chooses, so any error is earned, not randomly injected.
3. 03In flight, a bad sign-off becomes a real fault in the physics. Not a scripted failure animation — a degradation the flight model honours.
4. 04On landing (or after a crash), a debrief walks every task: what was chosen, what the correct method was, why it matters, and the in-flight symptom it produced.

Faults that behave like faults

The catalogue holds 29 maintenance-consequence tasks across the five airframes, feeding 17 fault models spanning rotor, drivetrain, powerplant, flight controls and airframe — and every fault is keyed to a real part id in the maintenance database. The dynamics are deliberately un-arcade-like: nothing presents before an onset delay of 20 to 200 seconds, then effects ramp in over roughly three minutes. The aircraft feels airworthy on the ramp and degrades in the air, so the trainee has to notice a developing symptom, which is the actual skill. Degradations combine the way physics does — multiplicatively for thrust, power and fuel; additively for control biases — except vibration, which takes the maximum of its sources: an airframe shakes as hard as its worst problem, not the arithmetic sum of all of them.

When a fault surfaces, the alert names the affected part and part number, what was done wrong, the observable symptom, and the parts, consumables and tooling needed to correct it — and "Inspect part" deep-links straight back into the trainer, opening that component’s maintenance data. The loop closes in both directions.

The bug that proves the argument

The strongest argument for one loop came from a defect. Fault bias magnitudes were raw newton-metres, tuned on the Apache. The 737 carries roughly 81 times the Apache’s roll inertia, so a bias that visibly drops a wing on the helicopter produced 0.32 degrees of bank on the airliner after a full minute — the consequence system was silently inert on the one non-helicopter airframe. Biases are now rescaled against a frozen reference inertia, and the fix changed no aerodynamics: both behavioural suites still pass, 21/21 rotary and 22/22 fixed-wing.

Honest attribution or none

One design rule keeps the debrief credible: crash attribution is conservative. The debrief only blames a maintenance error when the fault kind could plausibly cause the reported crash — a yaw bias is never charged with a high-speed straight-in impact that was plainly a flying error. A training system that blames the mechanic for the pilot’s mistakes teaches students to distrust the debrief, and a debrief nobody trusts teaches nothing at all.