USE A RELEASE NOTE AS A DATED DIAGNOSTIC RECORD
Record the exact installed Fenix and simulator builds before interpreting a report. The release announcement identifies what was published; a known-issue entry records an investigation at a particular time; a successful user flight records one outcome. These have different evidential roles. The 21 October 2026 V3 release and 22 October hotfix are part of this edition's baseline, while the developer issue snapshot is dated 24 October and edited 25 October. Preserve those dates when discussing route retention, prediction behaviour, loading transfer or FAP/intercom interaction. An older observed defect is not automatically a current operating characteristic. [82, V3 release identity] [122, 22 October 2026 hotfix announcement] [83, 24–25 October 2026 issue snapshot]
A useful technical report describes the state immediately before the discrepancy and the first difference observed. Include airframe/engine/wingtip, livery options, route or provider context, weather, mass, configuration, relevant modes, hardware input path and repeatable action. Distinguish the expected result and its supporting source from the actual result. Preserve photographs or a short recording where they show readable indications and timing. This author-proposed reporting structure helps the official support route assess a concrete case without asking a general impression to carry the weight of a reproducible test. [135, Official fault-reporting route] [21, PDF pp. 51–74]
Before a broad reinstall or state reload, preserve the evidence when practical and identify what that recovery action will change. A successful restart can remove a symptom without identifying the cause. A change in graphics, hardware bindings and livery configuration at the same time makes the result particularly difficult to interpret. Repeat a narrow comparison on a supported baseline, then add relevant external integrations deliberately. The objective is to locate the condition that changes the result, not to accumulate a list of adjustments that happened to precede a good flight. [137, Installer/runtime separation] [61, Panel-state loading] [136, V3-era setup: Fenix application and display options]
Separate an aircraft procedure from a software workaround in the record. An ECAM-authorised action belongs to aircraft operation; removing a conflicting assignment, changing a renderer or reloading a package belongs to the simulator environment. A forum can help discover a condition worth investigating, but its suggestion still needs scope, corroboration and a suitable current reference. Do not place an unverified workaround into a normal checklist merely because it made one session continue. Where implementation remains unknown, say what was not verified instead of turning silence into evidence for or against a feature. [134, Authorised aircraft-reset framework] [135, Support route] [141, Community forum as discovery source]
Keep the final conclusion proportional to the test. A reproduced result on one build and configuration establishes that case; it does not validate the entire family or prove a cause shared by unrelated reports. Record the remaining question and the evidence that would settle it. After a fix or update, repeat the original narrow case before generalising from a normal sector. This makes the PRO companion useful beyond a particular release: enduring aircraft principles remain identifiable, and implementation observations can be revised without rewriting them as if they were Airbus limitations. [83, Dated implementation observations] [135, Reporting and follow-up context]