A support resolution should point to the event that proves it
By DX Research Group · · User support and feedback
Define closure evidence by the reported failure rather than by the last reassuring reply.
A support conversation can end before its underlying problem is resolved. The owner may accept an explanation while an order remains unresolved, or a settings change may be described without a saved-state check. We propose a closure rule that names the event needed to establish resolution for each kind of report.
The DXAP activity guide already supplies the relevant distinctions. A completed turn establishes that evaluation finished. A submitted order requires a status check. A fill in Trades establishes recorded execution. Support can use those public semantics to avoid calling an earlier stage proof of a later one.
Match the receipt to the complaint
Suppose an illustrative report says, “The agent submitted an order, but I cannot find the position.” A support answer that quotes the submission message has repeated the original observation. The next useful evidence is the order's outcome, checked against Trades and Positions for the selected account.
If the order was rejected, explain that terminal outcome and its reason. If it filled, reconcile the recorded quantity and any subsequent closure. If the available evidence cannot establish the outcome, preserve the report as unresolved. A new successful order would demonstrate a different event and would leave the original question open.
For a settings complaint, closure has another shape. The chat guide asks the owner to check updated Agent settings after approval. A saved value resolves whether a change took effect; it does not establish whether that setting improved subsequent strategy behavior. That second question needs turns under the updated configuration.
We would record the original question, the relevant turn or proposal, the resolution claim, and the event supporting that claim. The public support summary can remain brief. Detailed account evidence belongs in the authorized support context, with identifying information removed before any research reuse.
Distinguish explanation, repair and verification
An explanation can resolve a misunderstanding without changing software. A repair can change software without demonstrating that the affected path now works. Verification connects the intended repair to a reproduced case and its observed outcome. These are useful separate fields in a proposed support record because they answer different questions.
Our controls paper companion describes historical invocation-level traces spanning mandate, rendered inputs, typed action, validation and reconciliation. Its method supports using stage-specific evidence to diagnose a failure. Current public product documentation establishes which trading views owners can inspect; the historical paper does not promise that every internal trace field is exposed in the current interface.
A practical audit would sample closed reports and ask an independent reviewer whether the recorded evidence supports the exact resolution sentence. Include reports closed by explanation and by repair, and record missing evidence rather than silently excluding them. Report agreement and the proportion of closures supported by the required event.
This proposed audit measures the quality of support conclusions. It also produces useful release fixtures when a verified defect was repaired. Its contribution is modest and concrete: every closure claim should carry the evidence appropriate to the stage it describes.