Hi,
After saying "i have the controls" PF became (with the tacit concordance of PM and later the CPT, most of time) the "processor" and the "controller". He was put in the loop substituting in a difficult environment important elements, A/P and A/THR.
PF "output" (SS handling) was evidently based on uncertainties
(as per NeoFit graph). His "inputs" are unknown to us and he expressed "high speed" suspicion. His "outputs" were not random, and soon showed a definite "bias to climb" the plane. A bias so strong, to put the plane in a steep climb going above REC MAX.
Probably this is not just explained by "lack of training", surprise, etc. Something very important, together the lack of "reliable" inputs may be was feeding his "processor" during important moments, leading (or misleading
him to do that).
His "output" was not random. There was a pattern. This pattern was about the same during most of critical moments before stalling the plane.
After stalling, the reason could be partly explained by what was put in
post #66
RetiredF4::
It is not enough to look at the ability of the aircraft to be flown out of the stall, but to judge the success of recovery atempts in view of the knowledge of the crew (and not only of this AF crew) and the ability of the aircraft.
IMO, in this case is very important is to understand why the plane was put in the stall. Looking to all reasons that lead to this: Crew error(s), System anomalies (it's outputs, processing of UAS data), man-machine interface issues, etc. In order to learn from this crash this is absolutely necessary.
PS
The wreckage orientation in seabed proved later to be the coherent with A/C heading when hitting surface. When you have a "pattern" this normally "carries" important information.