Recoverable settings proposals make approval understandable

Trust in a settings proposal depends on a simple question: can the owner tell what is active after the conversation changes or the connection breaks? We propose measuring that understanding directly, including the uncomfortable moment when an approval appeared to succeed and its response disappeared.

The shipped DXAP chat flow gives the owner a proposal to review and approve, followed by a check of the updated Agent settings. When a conversation is interrupted, the guide asks users to inspect saved messages and proposal state before repeating an approval, then confirm whether the change already appears in saved settings. This is a practical recovery instruction with an observable end state.

An interrupted approval has several possible histories

Consider an illustrative proposal to change an evaluation schedule. The owner approves it, then loses the browser connection. On returning, the owner sees the original proposal but cannot tell whether the schedule changed.

One history is that the approval never reached the service. Another is that the settings were saved while the response was lost. A third is that a newer edit superseded the proposal. All three can produce an apparently unfinished conversation. Recovery needs to identify the saved state, not infer it from the last visible message.

A candidate interface improvement would show the proposal's intended change beside the current saved value and its application status. If a newer value exists, the interface should ask the owner to review the current difference. The historical approval applies to the historical proposal; a changed proposal deserves a fresh decision.

This is a design proposal, rather than a description of additional shipped status controls. The documented flow already supplies the decisive check: reopen Agent settings and inspect the value that is actually saved.

Test comprehension before asking for confidence

We would run a bounded recovery study using draft agents or synthetic settings. Give participants the same intended change, then vary where interruption occurs. Ask each participant to identify the active value and their next action before they continue. Record whether the chosen action repeats an already applied change, applies a stale proposal, or leaves an unapplied proposal pending.

A confidence score is useful only beside correctness. A participant who confidently assumes success after a lost response presents a different risk from one who correctly checks the saved value but finds the interface frustrating. Measure time to verified understanding and unintended setting changes separately.

The builder adds another boundary. Create an agent distinguishes saving card changes from starting the agent. A recovery explanation must preserve that distinction so an approved draft edit cannot be mistaken for a launch receipt.

Finally, retain the recovery fixture for release testing. A clearer status message can regress when retries, navigation, or proposal rendering change. Success means the owner can reconstruct the approved change and current state across those cases. It supports a claim about understandable approval and recovery, while trading performance remains a separate question.