Hi,
RetiredF4,
When you are monitoring (PF before SS use) your entry in the loop should be done (ideally) with an understanding of why you are being called for. In order to allow you to have better chances to act precisely and fast enough to apply the right corrections (normally required). This was necessary (roll).
When i think on the man-machine interface i consider it's characteristics not just during abnormal situations or emergencies. IMO it should be designed to keep PF very close to the loop. In an effective "hot stand by" condition. And automatism must take into account HF related to how "hot" (aware) and prepared the crew is "put" (kept)
In summary, a professional must always be prepared to any scenario. (*) Even outside the (not acting) loop we should be "in the loop". In "parallel"
An analogy could be on the "synchronized processors" in certain fault tolerant Systems. They are working together in a "hot stand by condition" and can perform immediately if required.
In high speed vehicles (land) or near limits (e.g.aquaplaning threat) i learned it is better to "fully enter the loop" before any chance of LOC. This analogy is to agree with your rationale on the need to be "in the loop": I had an incident (with no consequences) in which i put myself in the loop, before. When the problem started (absolutely predicted and anticipated) i was yet in the loop (i started the maneuver applying a familiar large amplitude stimulus). After a surprise (vehicle reaction much different than normal) i performed perfectly the correction. But had no "maneuver room" to complete the task and eventually capsized (at very low speed) due a water drain hole at road side. When i left the vehicle (by the rear window i detected TWO flat tires (at rear) that explained the different behavior of the car (was not my one at this rainy night trip). This car had CG well ahead and used tubeless dangerous to detect when flat (difficult or even impossible to detect "on the fly" or even visually when parked) with low car weight in the back. This was my only "incident" (just testing the car after a previous LOC) since 1963, when started to drive cars at higher speeds.
In this case i remember i made an analogy of me as having two processors and their specific software (algorithms). When the 1st one didn't find the "car behavior" in the data base it dropped and put the 2nd to act. The second was used in a "emergency inside an emergency" and was capable (allowed me) to "calibrate" the correction stimuli. The adrenaline was enough to give me enough time to think (in "parallel" during the maneuver: How i would say to my friends i had two incidents in the same night? (because after not detecting the reason of the LOC (1st maneuver some 30 minutes before) i decided to understand why it happened. And later realized the first LOC was due just ONE flat tire. At cruise speed. And the 2nd with TWO under "test speed" some 50% lower.
In next day i concluded (in the local of the incident) it was fine to test because if i used the car (at cruise speed) with TWO (undetected) flat tires, the chances to suffer a serious accident would be enormous. It's possible to see all tire marks in the road (asphalt) very weak in next day (sunny) despite incident occurred at wet surface. (light rain)
(*) 5 Gorillas joke i learned in Silicon Valley in early 80's.
on the Professionals.
One detail (available) was the reason of A/P and A/THR drop. IMHO this should be informed clearly to the crew ideally before. When AS began to show inconsistencies. If the System provide this info. (a "benign" event) the crew (PF) could enter the loop better prepared. But this is just a detail in a set of facts we don't know. And could not had helped too much.