When the System Cannot Know Intent, Make the Decision Explicit

An apparent duplicate arrives, and the data supports four legitimate next actions. It could be a replacement, an additional relationship, a correction, or an item that should stay separate. Which one is right depends on intent, context, policy, or consent that nobody has captured.

That is a decision boundary, and the system should not guess.

Spot the ambiguous write

An ambiguous write is a single request that could reasonably mean different things. A conflicting schedule may need to be replaced, preserved, escalated, or cancelled. A matching record may be the same person, a different person with similar attributes, or too little information to decide.

An error message is the mild outcome. A silent default can overwrite information, create an unintended duplicate, reveal information to the wrong person, bypass a policy, or leave a later correction hard to explain. So the system has to find the ambiguity before it performs a consequential mutation.

Preserve state and return a safe conflict

A conflict response should not expose more data than the person is authorized to see. It should give enough context for an informed decision, say what is unknown, and make clear that no change has happened yet.

The server generates and validates that response. It accounts for the current state of the relevant records, the user’s authorization, tenant or organizational boundaries, and policy constraints. It also has to allow for the state changing between the first detection and the final submission.

The client can then present the choices in plain, accessible language. It should work with a keyboard and assistive technology, mark destructive or irreversible actions, offer a safe cancel path, avoid dark patterns, and explain what each option will do.

Offer only choices the system can honor

A choice belongs in the interface only when the backend can perform it safely for the current context and the current person is authorized to request it.

That means server-side checks at the point of action as well as when the modal is displayed. Before the mutation, validate the selected option, the input schema, authorization, current record state, applicable policy, and any required approvals. Use concurrency handling so an earlier conflict decision is never applied to data that has changed underneath it.

Where a process can be retried, design for idempotency. Where an action has material impact, require a confirmation proportionate to that impact, record the decision and its rationale, and give a clear result and a recovery route if the action cannot be completed.

A repeated conflict points at the data model

If the same ambiguity keeps appearing, the model may be missing a concept. Do not add a new label or field casually, but recurring, decision-relevant uncertainty deserves investigation.

Ask:

• What fact would distinguish the legitimate outcomes?
• Who is allowed to provide or verify that fact?
• Is the fact sensitive, regulated, or subject to retention limits?
• Does it belong as a persistent field, an event, a policy-controlled workflow step, or a one-time confirmation?
• How will historical records, migrations, corrections, and deletions be handled?
• What evidence, approvals, and audit trail are required?

The goal is to stop hiding material decisions inside a default that users cannot see or challenge. You do not have to encode every possibility.

Verify the outcome

A successful request is not always a successful business outcome. After a consequential decision, check the visible state, the relevant permissions, the downstream effects, and any notifications or follow-up obligations. Keep audit evidence that supports accountability, while minimizing sensitive data and respecting retention rules.

Ask your team or vendor which write actions can mean more than one thing. Confirm the system stops before it changes anything and hands the accountable person a clear, safe way to decide. Check that every offered choice is validated on the server at the moment of action and that the decision is recorded. When the system cannot know intent, asking is a sign the product is honest about its limits.

dxdev LESSON · paste into your AI coding agent
LESSON: Make ambiguous intent an explicit, governed decision
SOURCE: dxdev.com/blog/trade-or-multi-team-turn-silent-overwrite-into-a-decision-modal
WHAT HAPPENED: A write action could lead to multiple legitimate outcomes, but the deciding fact was not represented in the system. The old path guessed or failed silently. The safer design performed a server-side conflict check before mutation, preserved current state, returned a privacy-safe and accessible explanation of the ambiguity, showed only actions the authorized user could perform, required a deliberate selection, revalidated authorization and current state on the server, recorded an audit event, and verified the result.
THE RULE: When an action depends on intent or context the system does not possess, do not infer it. Create a clear decision boundary with authorized choices, accessible explanations, server-side validation, concurrency and idempotency handling, audit evidence, safe failure, recovery, and post-action verification.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Any consequential write path that silently defaults between materially different valid outcomes, leaks unnecessary information while describing a conflict, or relies only on client-side checks.
  2. Any decision UI that offers unsupported, unauthorized, inaccessible, or unexplained actions; fails to allow cancellation; lacks appropriate confirmation for impact; or does not communicate the state and consequences clearly.
  3. Any conflict-resolution path without server-side authorization, input/schema validation, current-state and concurrency checks, idempotency where applicable, auditability, data-minimizing error handling, rollback or remediation planning, and post-action verification.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.