<VCAC_Provisioning_Analogy>When you go to the the bar you might ask the bartender for a beer and the bartender will acknowledge your request for a beer, but was that truly a successful order? If you get a beer in a reasonable time, then I'd say Yes. But if you never receive your beer, I'd argue that was not successful.</VCAC_Provisioning_Analogy>
Using a long running asynchronous post-provisioning automation triggered during the MachineProvisioned state change workflow will lead to this same dilemma in some cases. We used vCO to call a REST service to initiate other orchestration and the REST service (on SCORCH) happily reported "success", but in reality was still processing the orchestration on its end. VCAC reported a Successful status, but in reality the deployed server was not fully baked. In our case, we have improved the success factor of the orchestration by adding some retry logic, but I'm still left with the dilemma that VCAC will report success before true success is achieved.
So do you think it is okay for VCAC to report success pre-maturely? Or should this design pattern be avoided at all costs?
IMHO, it should be avoided, but I'm okay with some pre-mature success reporting, provided it is mostly successful, most of the time, and I keep my job after the failure. 
Cheers and thanks in advance for your opinion, abuse, or free beer.
-Sean Clark, @vSeanClark