A PANEL STATE IS A STARTING POINT THAT MUST FINISH APPLYING
Fenix's documented panel-state workflow distinguishes choosing a state, setting it as default and activating it. Let the selected transition finish before treating cockpit indications as the starting condition. The support page describes a delay during initial aircraft loading; the meaningful check is that the actual aircraft has settled into the intended state. Beginning a preparation flow while the saved state is still applying can make a later switch movement difficult to interpret. Verify engine, electrical, control and ground-service conditions before proceeding. [61, Default panel-state selection, activation and loading transition] [23, PDF pp. 988–999]
A panel-state name does not independently establish the complete operational situation. Confirm mass, fuel, route, brakes/chocks, ground services, relevant failures and the settings needed by the exercise. An aircraft can load in a familiar cockpit arrangement while an external provider or hardware switch has another state. Keep those dependencies in the scenario record. After a reload, verify the actual result rather than assuming that every flight-management entry, integration state and previous control input has been serialised in the same way. [61, Scope of panel-state application] [133, External service/loading synchronisation] [75, Hardware input calibration]
Distinguish persistence of a preference from persistence of an aircraft failure. The documented random-failure configuration can be stored as default, and the failure interface separately shows armed and failed items. Check those settings when an exercise needs a clean starting point. A reset panel is not used as evidence that every failure or service state has been cleared. Conversely, observing a familiar alert during startup does not automatically establish a persistent defect: the support guide discusses startup self-tests. Judge the settled state and relevant procedure before classifying the indication. [127, Stored random-failure preferences, Armed/Failed states and startup notes]
Use a known panel state for comparative work, then verify the variables that matter to the question. For a mode-transition test, retain the same route, mass, level, configuration and targets. For a start test, retain the actual engine installation, supply arrangement and selected start option. This reduces the risk of explaining an expected difference as a regression. If the state was created on another build or configuration, record that fact and validate it before using it as a reference. A saved state is convenient evidence of intent, while the loaded indications establish what was actually achieved. [61, State activation] [70, Equipment and engine/start configuration options] [53, FADEC presentation and selected engine behaviour]
When ending a failure lesson, restore a known aircraft state through the appropriate exercise or maintenance controls and confirm the result before another normal sector. Preserve the original failure evidence before using a broad reload to recover the session. State loading, manual failure removal and ground maintenance remain separate operations in the record. The final check is an aircraft ready for the next intended task, with no unexplained configuration or external-service mismatch left behind. This provides a repeatable foundation for the next lesson without rewriting the normal checklists. [127, Failure removal and maintenance] [133, Loading/deboarding state and recovery]