V3 PROGRAMMING RECOVERY: TARGETED REPAIR OR A DELIBERATE CLEAN REBUILD
The V3 recovery question begins with the scope of the error. A scratchpad typo, an uninserted proposal, an incorrect active leg and a software prediction problem are different cases. Start with the smallest current supported action that addresses the established cause. A full rebuild is a deliberate preparation decision; a navigation-database swap is maintenance with additional effects, not a general programming undo. [66, PDF pp. 102-105,312-315] [107, Activate STANDBY database] [109, Account setup and Generate OFP] [83]
1. Identify what actually changed. Read the receiving field and ACTIVE/TMPY/SEC title. If the wrong data is still only in the scratchpad, correct the text. If the error belongs to a pending proposal, inspect the proposal and use its actual ERASE/CANCEL function when appropriate. Do not insert an unknown temporary route solely to reach a different menu. [66, PDF pp. 102-105,312-315] [107, Activate STANDBY database] [109, Account setup and Generate OFP] [83]
2. Repair the accepted local error. Establish the intended fix, constraint or route segment from the current OFP/clearance, make the appropriate supported revision, and review the complete affected path before commitment. Afterwards verify active leg, restrictions, predictions and FMA as relevant. A local error does not justify discarding correct loading, destination and performance preparation without understanding what the replacement will preserve. [66, PDF pp. 102-105,312-315] [107, Activate STANDBY database] [109, Account setup and Generate OFP] [83]
3. Make a parked rebuild explicit. When a clean flight preparation is genuinely chosen, regenerate/check the intended current OFP and use the supported initialization/import workflow for the actual state. Read where the new information was received and then repeat identity, route, mass/fuel and performance checks. A newly populated page is not proof that every earlier input was replaced or that its actual loading assumptions remain valid. [66, PDF pp. 102-105,312-315] [107, Activate STANDBY database] [109, Account setup and Generate OFP] [83]
4. Keep database activation in its own workflow. Current S4 activation swaps ACTIVE and STANDBY and resets the FMS, with ground/phase/date/job-state conditions. Use it when establishing the required navigation database, then prepare the flight again. Do not switch cycles to clear a typing mistake, reproduce a pre-V3 reset suggestion or bypass an existing route-review problem. [66, PDF pp. 102-105,312-315] [107, Activate STANDBY database] [109, Account setup and Generate OFP] [83]
5. Separate a remaining software issue. If the input/route state is correct but a reproducible prediction or sequencing problem remains, record build, platform, active data and exact actions. Consult current V3 support status rather than adopting an old workaround. The useful completion point is either a fully reviewed recovered flight or a precise unresolved case, with no falsely claimed reset cure and no hidden change to the navigation cycle. [66, PDF pp. 102-105,312-315] [107, Activate STANDBY database] [109, Account setup and Generate OFP] [83]