Ambiguity must be exposed, not assumed away

Unresolved questions should remain visible until they are answered, tested or explicitly accepted as risks.

The problem

Ambiguity exists in almost every product and technical requirement. “A request should be handled quickly” might refer to network latency, time to first response, or time to final resolution. Different interpretations produce different systems.

AI may ask clarifying questions, but it cannot be relied upon to identify the important question. Worse, it can reject supplied information because its own prior belief conflicts with the design. It may then devote substantial effort to making an unnecessary alternative work.

A detailed prompt is not a guarantee of shared understanding.

A practical rule

Treat uncertainty and contradiction as engineering inputs. Record the contested statement, its evidence, the decision owner and the next action. If uncertainty affects a contract, core architecture, irreversible change or external commitment, stop implementation until it is resolved or a safe experiment has been agreed.

Agents should have explicit authority: what they may infer locally, what assumptions must be reported and which conflicts require escalation. Giving an agent a large context window is not the same as giving it permission to reinterpret that context.

Illustrative example

A design says duplicate incoming requests should be ignored. Does that mean duplicate network deliveries with identical content, or distinct reports from different users describing the same issue? The difference affects data loss and user trust.

Instead of inventing a fuzzy deduplication algorithm, the team specifies a narrow idempotency contract: the same external source and identifier with the same payload returns the existing request; a conflicting payload produces a visible error. Semantic deduplication becomes a separate product decision.

Useful evidence

• A decision log of unresolved questions and their impact.
• Source of truth for externally defined behaviour (e.g. protocol specification).
• Contract tests created for the resolved interpretation.
• A record of rejected assumptions and the reasons.

Limits

Not every ambiguity deserves a meeting. Low-risk, reversible decisions can be delegated within pre-agreed defaults. Excessive escalation destroys the advantage of automation. The aim is risk-aware judgement, not a prohibition on all inference.

See the worked example: open questions and decisions, the idempotency contract, and stop conditions.