On This Page
A support system recommends refunding an order. The screen says “high confidence,” but the agent cannot see which order, which policy version or whether a replacement shipment already went out. The recommendation may be right. The agent has no way to know. This is an illustrative support scenario, not a reported incident.
A decision-support demonstration shows a more inspectable pattern: a reviewer can see component measurements and open the underlying examination rather than receiving only a final suggestion. The demonstration is in a medical setting, where independent validation matters especially much. It does not establish clinical accuracy. The design lesson can be carried into less sensitive work without borrowing the vendor’s outcome claims.
A verdict compresses the evidence
Compression is useful. A person asking whether to refund an order does not want to read every event in a ledger. A recommendation can turn a long record into a next action. But compression discards details, including the ones that might overturn the result.
Consider an illustrative order history. A customer reports a missing parcel. The model sees “not delivered” on the carrier feed and suggests a refund. Another record says a replacement was shipped this morning. If the recommendation hides that record, the agent may issue two remedies for one problem. If it shows both facts and their times, the agent can make an informed choice.
The interface should answer four questions before inviting action: What was observed? Where did it come from? How current is it? What could make this recommendation wrong? A prose rationale is only part of that answer.
Source observations and a reviewer are connected by a recommendation that includes provenance and uncertainty, allowing the reviewer to inspect the original record.
“Refund because delivery failed” may be fluent while the carrier status is stale.
| Visible element | What it lets the reviewer test |
|---|---|
| Recommendation and proposed action | Whether the action matches the task |
| Source observations with timestamps | Whether the facts are current and complete |
| Missing or conflicting evidence | Whether to pause or investigate |
| Link to original record | Whether the summary omitted a decisive detail |
| Outcome and correction trail | Whether similar suggestions fail repeatedly |
This is a conceptual interface checklist, not a claim that any one dashboard achieves better decisions.
Put uncertainty in the work, not the fine print
A system can be uncertain for several reasons. A source did not respond. Two identifiers might refer to the same order. A policy changed since the last index. The model itself may be unsure how to interpret a free-text complaint. These are different failure modes and deserve different displays.
“Low confidence” is not enough when the operator could resolve a concrete missing fact. Show “carrier feed last updated yesterday” or “replacement record could not be fetched.” If the system has no basis for a score, do not paint a precise percentage on the screen. The goal is to let a reviewer decide what to verify next.
The same structure matters in a data sync. If a destination receives a new customer status, preserve the source event ID, time and rule that produced the change. When someone asks why a campaign included a customer, the team can follow the decision backward. An unexplained copied value is a verdict without evidence.
This proposed Tajo view separates what an activity log reports from what remains unproved. The write is shown as applied, while the destination check is still pending. Tajo’s existing activity feed exposes outcomes and raw events; the added verification panel is an illustration of how that boundary could be made more visible.
A finished write still needs evidence
Did the customer sync finish?
Write applied. Verification pending.
The destination state has not been checked yet.
Sync activity
- Request accepted
- Update applied
- Destination check pending
Example run · 14:32 UTC
What we know
- Provider response
- Accepted
- Write result
- Applied
- Destination readback
- Pending
A successful call does not prove the final state.
Proposed layout informed by Tajo's activity feed. This illustration adds a verification state; it does not claim that destination readback is already implemented.
Keep review useful without exposing everything
Most routine actions should not require opening a case file. The best interface can keep the recommendation concise while making the evidence one step away. It can also surface only the discrepancies that could change the choice. That is different from hiding the basis entirely.
There is a real privacy cost to showing more data. A reviewer should see only fields needed for this decision, under the same access rules that govern the underlying record. Evidence visibility is not blanket permission to expose a customer history. Retention and audit logs also need an owner.
A second concern is automation bias: a visible recommendation may still steer the person reviewing it. Test whether reviewers catch planted contradictions and whether they can choose “insufficient evidence” without fighting the interface. Measure correction and reversal patterns after deployment. A pleasing explanation is not the outcome measure.
A review interface also needs a place to record disagreement. If the agent rejects the refund suggestion, ask for a reason narrow enough to improve the system: wrong order match, stale carrier status, missing replacement record, or policy exception. Do not turn every disagreement into a demand for long prose. Aggregate the reasons and inspect whether one source repeatedly causes trouble. That creates a path from individual review to system repair. The workflow discovery guide helps find the real exception path before a suggestion is built. Evidence beside a verdict helps the reviewer today; correction data can improve tomorrow’s decision path.
For consequential actions, the review path should be part of the product contract. The system proposes, cites what it used, names what it could not check and records the result. When the evidence does not support a choice, the most useful verdict may be “wait.”
Frequently Asked Questions
Does an explanation make a recommendation reliable?
No. A plausible explanation can accompany a wrong result. Reviewers need access to source observations, provenance, uncertainty and outcomes, not just a confident sentence.
What evidence belongs beside an automated suggestion?
Show the specific observations used, their source and time, any missing inputs, the rule or model version where relevant, and a way to inspect the original record.
When should a person review the result?
When the consequence exceeds the system’s authorized scope or the evidence is incomplete, stale or contested. A reviewer must have a meaningful way to disagree and stop the action.