DEFINE THE AIRCRAFT BEFORE ACCEPTING THE ANSWER
A performance result belongs to a particular aircraft and a particular departure or arrival. Record the Fenix airframe, engine, wingtip option, selected equipment and loading before interpreting the number. The same route and cockpit layout can conceal different assumptions about thrust, drag, fuel transfer or landing capability. On Frankfurt–Heathrow, retain one verified exercise configuration long enough to establish a reference. When changing to another family member, make the comparison explicit: identify which inputs changed, recalculate their consequences and retain the original result for comparison. This is the operational counterpart of understanding the system architecture. [52, Included aircraft, engines and configuration choices] [74, PDF pp. 8–9]
Separate four sources of information. The current flight's data establish weather, clearance, runway and loading. The applicable aircraft procedure establishes how that configuration is operated. The supplied FCOM and FCTM explain system and technique relationships for their stated editions and effectivities. Fenix support and release material establish documented simulator implementation. A forum account describes an observation on a reported installation. None can quietly replace the others. In particular, an old manufacturer's numeric example is not an automatically valid limit for every current Fenix variant, and a software preference is not an ATC clearance. [21, PDF pp. 65–74] [83]
Accept a calculation only after its inputs and intended use have been checked. A takeoff result needs the actual starting point, runway condition, weather, mass and configuration. A landing result needs an arrival assessment with the current aircraft state. The FMS additionally needs accepted entries that agree with those calculations. These are related tasks with different outputs. A successful transfer confirms that information arrived; a crosscheck establishes that the right information arrived in the right fields. Retain units and reference conventions during that comparison, especially for pressure, mass, runway distance and wind direction. [59, PDF pp. 6–8] [66, PDF pp. 123–128]
Airbus documents how runway changes, intersection departures and changed surface conditions can invalidate previously correct takeoff speeds. Its lesson is operationally specific: revise the affected data and complete the crosscheck despite the competing workload of taxi or a late clearance. The practical consequence in the simulator is to stop the progression towards takeoff when the assumptions have changed. Retyping only the runway name leaves mass, speeds or thrust assumptions potentially attached to the earlier departure. [123]
Keep a compact evidence record with the sector: configuration, data source and time, accepted result, significant revision and final crosscheck. This is an author-proposed learning method, rather than another aircraft checklist. It makes a disagreement traceable. If the aircraft later appears unable to meet a constraint, you can distinguish an input error, an unrealistic clearance, a mode choice and a documented software issue. The completed exercise should leave an explanation of why the accepted plan remained workable, including the point at which you would have changed it. [21, PDF pp. 141–158] [24, Worked-flight dataset and deliberate simulator practice]