Give support and engineering the same incident vocabulary

Support and engineering can discuss the same turn while counting different incidents. “Trade failed” might describe an invalid request, a policy rejection, an order awaiting a fill or a missing status message. We propose a small shared taxonomy whose meanings are tested against saved events before it becomes a reporting convention.

DXAP already documents the necessary distinctions. Review activity separates completed turns, proposed actions, rejections, submitted orders and fills. Policy and execution places configured checks between a requested action and venue submission. These public states can anchor a common vocabulary without inventing a new execution sequence.

A proposed incident row would contain an observed stage and a separate suspected cause. “Rejected opening request” is a stage observation. “Configured position cap” is a cause only when the rejection record supports it. Keeping the fields separate lets support record a reliable observation before engineering resolves the cause.

Calibrate the vocabulary on awkward cases

Use a fictional packet of twenty saved or synthetic events. Include ordinary cases and boundaries: a completed waiting turn, an approved-looking conversation with unchanged settings, a submitted order still resting, and a rejection followed by a successful retry. Ask one support reviewer and one engineering reviewer to classify them independently using the same taxonomy version.

Suppose reviewers agree on sixteen of twenty stage labels. Agreement is 80%, but the four disagreements matter more than the pooled score. If all four concern resting orders labeled as failures, revise that definition and add a contrasting fill example. A high total score can coexist with confusion about the stage that users most need explained.

Adjudication should identify whether the reviewers missed evidence, the category definition overlapped, or the event record was incomplete. Preserve the original labels alongside the adjudicated label. Quietly replacing them would erase the evidence needed to judge the taxonomy.

Count episodes consistently

A failed request followed by two retries can produce three action records and one user-reported episode. Declare which unit each dashboard uses. Engineering may need request-level failure rates; support may need the number of owners experiencing unresolved episodes. Both can be valid if the relationship remains visible.

We would bind each episode to its first relevant event and close it only when the declared issue has its required evidence. A second failure with a different cause can open a linked episode. This prevents a long conversation from becoming one permanent incident while also preventing every message from inflating incident volume.

When a category changes, retain its version and map old labels explicitly. A newly split “submission problem” category should not create an apparent improvement merely because historical cases remain under the old name. Compare a fixed sample under both versions before interpreting trends.

The initial deliverable is modest: definitions, boundary examples and the disagreement packet. Support can then ask for the evidence engineering actually needs, and engineering can return a diagnosis users can recognize. Taxonomy quality is measured by reproducible classification and fewer ambiguous handoffs, with trading outcomes evaluated separately.