A quarter of support tickets clustered into defects

The decision tree

5 typed decisions, each with an action for every answer

At fixed moments in a run, the engine puts one narrow question to a decision model. The decision model never writes text: it answers yes or no with a probability, picks from listed options, or gives a score, about a small slice of the material. The engine then does exactly what this tree says, which is what makes the run auditable. The thresholds are the template's design values, not measured results.

1. 1

   Planner, while planning

   Scope checkA choice among options

   Before work starts on a unit

   What is this ticket mainly about?

   Sees only: The first customer messages of one ticket

   Why: Defect clustering should not pay to read how-to questions, but doubtful tickets stay in.

   • A product problem or unexpected behaviour→thenAccept
   • A how-to, billing or account question→thenSkip this unit
   • Spam, auto-reply or empty→thenSkip this unit
   • Cannot tell from the conversation→thenAccept
2. 2

   Before workers, before a task runs

   Small worker or strong modelYes or no, with a probability

   Before a task runs

   Is the conversation in one language, with the customer describing the symptom in the first few messages?

   Sees only: The ticket's first messages and its length

   Why: Long, mixed-language threads are where small workers lose the symptom.

   00.30 and 0.601

   • Yes: 0.60 or higher→thenAccept
   • Unsure: 0.30 up to 0.60→thenEscalate to a strong model
   • No: below 0.30→thenEscalate to a strong model
3. 3

   After workers, the judge checks

   Evidence checkYes or no, with a probability

   After a worker answers

   Do the customer's quoted words describe the symptom and trigger the worker recorded, without the worker adding a cause the customer never mentioned?

   Sees only: The worker's filled form and the quoted customer sentences

   Why: Engineering only trusts clusters built from what customers actually said.

   00.50 and 0.851

   • Yes: 0.85 or higher→thenAccept
   • Unsure: 0.50 up to 0.85→thenEscalate to a strong model
   • No: below 0.50→thenReject and retry
4. 4

   Reconciler, while merging

   Conflict checkYes or no, with a probability

   While reconciling

   Do these two ticket claims describe the same symptom under the same trigger in the same product area, only worded differently?

   Sees only: Two filled forms with their quotes

   Why: Merging too eagerly invents big defects; doubtful merges stay split.

   00.50 and 0.851

   • Yes: 0.85 or higher→thenAccept
   • Unsure: 0.50 up to 0.85→thenMark unresolved
   • No: below 0.50→thenContinue
5. 5

   Accountable person, before anything is settled

   Person decidesYes or no, with a probability

   Before anything is reported as settled

   Does this cluster claim a defect that is not on the known-issue list, or do its quotes still contain unmasked personal data?

   Sees only: One cluster summary with its quotes and the known-issue list

   Why: Product decides what is a real defect, and customer data must not leak into a report.

   Accountable: Product and engineering decide what gets fixed and in what order. Ticket text is customer data and needs masking and access limits.

   00.10 and 0.301

   • Yes: 0.30 or higher→thenAsk a person
   • Unsure: 0.10 up to 0.30→thenAsk a person
   • No: below 0.10→thenAccept