Designing for uncertainty

A mismatch is information

When an AI-assisted interface finds a possible match between a document and a transaction, a person may be asked to act before all fields agree. The temptation is to smooth that uncertainty into a single badge: likely, verified or a confidence percentage. But the person still needs to know what differs and what the action will do.

A mismatch is not just a system inconvenience. It may be the most useful information on the screen. A design should make the disagreement specific enough to inspect, while leaving the person free to postpone the decision or take a manual path.

Two synthetic sources

The invoice shows €84.90 and 4 October. The transaction shows €89.40 and 5 October. These are authored values, not extracted customer data. No model has produced the comparison, and no financial service is connected. The interface concept starts with the disagreement rather than inventing an explanation for it.

The date difference might be harmless in some real contexts, while the amount difference might need separate investigation. That possibility is not enough to call this a match. Domain rules and actual source evidence would determine the next step in a real product.

Why a confidence badge is not enough

This pattern gives the person a decision without the evidence needed to make it. “Likely” does not say which field is uncertain. A numerical score would not fix that unless its meaning and calibration were established, and even then it might not answer the person’s practical question.

The button also hides consequence. Does Confirm attach the document, edit a record or authorize a payment? A control should name the real action. The concept here avoids any payment behavior and keeps the review local; a production product would need its own domain-specific requirements.

Put evidence beside the field

A stronger starting point is a field-level comparison. Label the sources, show the amount and date from each, and mark the disagreement with words rather than color alone. Keep the original information separate from the value the person is editing.

The person can then reason about one difference at a time. If a source excerpt is available in a real system, it should be reachable without losing the current edit. If it is unavailable, the interface should state that limit rather than draw an invented highlight over a fabricated document.

Explanation should support the current task. A short note such as “Amount and date differ” can be more useful than a long account of the model architecture. Detailed provenance still matters where it helps someone inspect or challenge the result.

Correction is part of the main flow

Editing should not require abandoning the task. Show persistent labels, retain entered values after errors and explain the invalid field next to the control. A summary can point to several errors, but it should not replace the local explanation.

Distinguish a reviewed value from an automatically resolved match. A person can record a value after checking it while still deciding not to connect the two sources. In this prototype, “Record local review” only reports the entered teaching values; it performs no external operation.

Leave room to stop or continue manually

“I can’t tell” is useful only if it comes with a path forward. Keep the sources separate, allow the person to inspect them and offer manual entry. Returning from that route should restore the context and entered information. An undo or reset must name what it restores.

The system should not quietly learn from a correction unless that behavior has been defined and communicated. Correcting a field, training a model and approving a consequential action are separate events. Collapsing them into one click removes informed control.

Review the recovery loop

• Can the person identify which fields disagree and see both sources?
• Are proposed values separate from original evidence?
• Does the action label name its consequence?
• Can editing, postponing and manual work happen without losing context?
• Can errors be understood with a keyboard or screen reader?

A realistic evaluation would include missing sources, contradictory values, unsuccessful edits and decisions to leave a result unresolved. A happy-path demonstration alone cannot establish reliability.

Sources and limits

Google PAIR’s trust and error guidance and Microsoft HAX inform this emphasis on evidence, correction and recovery. The interface choices above are my editorial interpretation of that guidance, not a validated financial workflow. No extraction accuracy, confidence calibration or user-study finding is claimed.