Where should the boundary be between Procedural Control and Basic Control?

The intent of the standard is to at least in part to alleviate human error by automating the manual procedures that are common today, and of course to do so with a recognised framework so that there is not a proliferation of individualist solutions, and all systems and end users are able to communicate consistently.
A current question is "Where should the boundary be between Procedural Control and Basic Control?"
I think we should start from an operational viewpoint and consider where the Operator interacts with Procedures.
Clearly, when a procedure is being run by an operator it would be unfriendly to say the least if the system had no tolerance of delays in the operators response
Now, that to me implies that the Process should be in a stable state whenever an operator input is requested.
And I think it should apply even if the Procedure is running automatically, in effect replacing the operator.

So I propose that the following apply
Procedures steps that interface with Equipment should do so by via Persistent Process States - Where a Persistent Process State:
    Is a State that is set entirely by Basic Control and that can be maintained without operator intervention
    Can persist for a time, for example longer than the slowest operator response or until some resource runs out

When procedure steps request equipment to do something they can do so by sending a State Request
A State Request is much like a control loop's Set Point. The PID controller (a type of Basic Control) then adjusts control valves etc to keep a Measurement at the Set Point, or within some limits.
With higher levels such as Equipment Modules or Units, Basic Control Loops and Logic can run to move  the process in the desired state and then keep it there, indicating so via an interface back to the procedure.

Procedures could set State Request in peer or lower level physical model entities
So, a Unit level Procedure may set the state of the Unit
Or it may set the state of Equipment in the Unit or of Control Modules in the Unit
They should never set the state of higher level entities
So a Unit level procedure should never set a Plant Area State or set the State of another Unit or an EM or CM that is outside the unit.

And for designing the Procedures it would provide a simple view without the complexity of showing the Module Logic

This shows how a procedure might look as a PFC