Turn a support correction into an expected response

A resolved support exchange contains a possible teaching example, but its useful label is the response the agent should have given under the original conditions. We propose curating that response explicitly. Training on the entire conversation would also teach workarounds, speculation and facts learned only after the problem was resolved.

DXAP’s activity guide distinguishes a completed turn, proposed action, submitted order and recorded fill. That vocabulary can anchor supervised support examples. A correction about one of those states has a clear factual target rather than a vague instruction to sound more helpful.

Take a fictional ticket: “The turn completed. Why is there no trade?” The available record shows a waiting decision because an entry condition was absent. A poor answer claims that the order is still processing. The reviewed target explains that completion means the evaluation finished, identifies the missing condition from the record and directs the owner to the relevant activity details. It preserves the distinction between a decision and execution.

The curated row should freeze what the agent could see when answering. If support later discovers an unrelated account problem, that discovery belongs in a later-state example. Rewriting the original answer as though it already knew the discovery would reward hindsight. A curator also needs to remove account identifiers and incidental private details while retaining the state fields that determine the answer.

Specify what earns credit

An illustrative rubric for this ticket has three required elements: describe the waiting decision accurately, identify the supported missing condition, and avoid claiming a submitted order. The target can express those elements in several ways. Exact wording would overfit a support agent’s prose; factual and action boundaries are the lesson.

Include an adjacent case in which an order really was submitted but remains unfilled. Its target should ask the owner to inspect order status, consistent with the same guide. A model that answers every quiet-agent ticket with “conditions were missing” would pass the first example and fail this contrast. Contrast cases turn a support correction into a discriminating objective.

The chat guide also says chat itself does not place a trade or approve settings changes. A reviewed support answer should therefore explain a proposed repair without pretending that explaining it performed it. An interruption case can require inspecting saved proposal state before repeating an approval.

Measure the repair on new problems

We would split examples by underlying incident and paraphrase family. Several messages about the same outage should stay together, so a near-copy cannot appear in both training and evaluation. Hold out genuinely new cases with the same state distinction, then compare the candidate and baseline using identical saved context.

For an illustrative result contract, score correct state interpretation, unsupported execution claims and whether the suggested next step can resolve the stated question. Keep unresolved tickets visible. Their missing facts may support a target asking a specific question, rather than an invented diagnosis.

This proposed loop turns user support into curated supervised examples only after permission, factual reconstruction and target review. Its first measurable benefit would be better answers to recurring state misunderstandings. A reduction in repeated contacts could be examined later, with incident severity and support availability controlled. Neither measure supplies evidence of improved trading returns.