Summary
The post begins with an uncomfortable observation: a workflow can contain valid tasks and permitted connections and yet have lost every route to an acceptable finished design. Local correctness does not add up to global viability. Whether an addition is safe depends on the obligations the workflow already carries and the options it has left, so the question cannot be answered by looking at the addition alone.
What that observation needs is a name, and the post gives it one: completion viability, the property that a partially built workflow can still reach an acceptable finished state through some finite sequence of further additions. Naming it turns a vague worry about painting yourself into a corner into a property the system can be asked about at the moment a change is proposed.
The mechanism proposed for holding on to it is a certificate carried alongside the workflow and updated whenever a change is accepted. Maintaining a certificate that is sound and non-empty preserves the possibility of acceptable completion; the price is that the system has to remember the distinctions that affect future choices rather than only the design as it currently stands.
The limits are stated rather than left to be discovered, which is the part worth reading twice. What this buys is a more precise basis for accepting a change. It does not guarantee that the workflow will eventually be completed, that it will execute successfully once it is, or that any of the checking will be faster.