An architect is asked to design something where the requirements are genuinely unclear and the stakeholders disagree about the goal. What is the productive approach?

The productive approach

Do not resolve the ambiguity by picking an interpretation and building. That produces a system that satisfies one stakeholder and is rejected by the others, discovered late.

Instead:

• Separate the ambiguities that matter from the ones that do not. Most disagreements are about details that any reasonable design accommodates; a small number are about things that change the structure. Only the second kind needs resolving before starting.
• Identify what the disagreement is actually about. Frequently the stakeholders are describing different problems and each is right about theirs, which is resolvable once named. When they are describing the same problem with different values — speed versus robustness, flexibility versus simplicity — no amount of analysis converges and a decision-maker is needed.
• Make progress on what is unambiguous, which is usually most of it, while the structural question is resolved.
• Build something small and concrete to argue about. A prototype, a mock, a worked example — people are far better at reacting to something specific than at specifying in the abstract, and a week of building frequently resolves what months of discussion did not.
• Record the interpretation you are proceeding under, with the trigger that would invalidate it.

The question that most often unsticks it

"What would we do differently depending on the answer?" If nothing, the ambiguity does not need resolving now. If something, the answer is worth the effort of getting — and the question directs that effort at the decision rather than at the topic.

The design property that reduces the cost

Defer the decisions that depend on the ambiguity, and make them cheaply reversible. An interface where the uncertain behaviour lives, a flag, or a configuration point costs little now and converts a wrong interpretation into a change rather than a rewrite.

But not everything can be deferred: the data model, the identity scheme and the tenancy key must be decided and are expensive to reverse. Those deserve the resolution effort; the rest deserve a seam.

What not to do

Escalate the ambiguity upward without a recommendation, which asks someone with less context to decide. Bring the options, the trade-off and a recommendation — the decision-maker's job is to choose, not to analyse.