Ambiguity Tolerance
The capacity to make progress on a problem before it is fully specified, which is the normal condition of architectural work.
Architecture work arrives underspecified. Requirements are incomplete, constraints are undiscovered, and the people who could clarify are unavailable or do not know. Waiting for clarity is the most common failure, and it is indistinguishable from being blocked.
The productive responses, in order:
Do everything that does not depend on the unknown. Most designs have substantial work that is unaffected by the open question, and doing it frequently reveals the answer.
State an assumption explicitly and proceed. A written assumption is visible, correctable and better than an unstated one — and it converts ambiguity into something a stakeholder can react to. People who cannot answer an abstract question will readily correct a specific assumption.
Design for optionality where the unknown is genuinely consequential: an abstraction boundary, a feature flag, an interface admitting a second implementation. This converts a decision that must be right into one that can be changed.
Time-box a spike where the ambiguity is factual and resolvable by evidence.
Ask, but ask well — a specific question with options attached gets answered; "what do you want?" does not.
The judgement that separates this from recklessness: decide which ambiguities must be resolved before proceeding — typically the irreversible and the safety-critical — and resolve only those, proceeding on stated assumptions everywhere else.