Split out of PRACTICE-001, which had carried it since this record was written. Delivering the whole scope and resolving ambiguity without escalating are both true, and a project could want one without the other — so they were always two practices, and while they shared a code neither could be overridden without the other coming along. See DP-012.
Do the part that does not depend on the answer first. Most ambiguity is local: it blocks one decision, not the task. Everything upstream of it can be finished while the question is still open, and often the work resolves it.
Then state the assumption, at the point it starts mattering. Naming a call is what makes it reviewable — a reader who disagrees can say so, and the work is already done rather than waiting. An unnamed call is indistinguishable from not having noticed the ambiguity.
Block only when either reading would be unsafe or wasteful. Stopping with nothing delivered is expensive and is sometimes right: an irreversible action whose target is unclear, or an approach that would have to be thrown away if the guess were wrong. Outside that, asking is a way of returning the work.
The limit is that this licenses proceeding on what is inferable, and some things are not to be inferred however easy the inference. Those are recorded as boundaries, and they override this.