Stage S1 — Classification
Purpose
A request arrives from a channel — a Jira ServiceDesk ticket, a mail to the shared box, a Bulstrad HelpDesk article, a request started in place on the client surface. Before anyone investigates anything, four questions have to be answered, and answered the same way every time: what kind of request is this, how urgent is it under the contract, has it been seen before, and is it already open somewhere else?
Getting this wrong is expensive in both directions: an incident classified as a question sits while its SLA burns; a question investigated as an incident costs hours that memory would have answered in minutes.
Inputs → Outputs
In: the raw arrival, plus whatever the connector agent extracted — reporter, subject, body, attachments, referenced policy and object ids. Out: a classified case — request type, contract classification and severity, running SLA clock, dedup verdict, and the precedent set the solution take starts from. The case goes to S3, never straight to S2: the take's first question is whether a ready solution exists, and only a case with none reaches investigation (D83).
What runs this stage
| Agents | support.triage |
| Isolated sub-agents | — |
| Memory domain it owns | none. It reads support/experience — the past-case index — and files proposals into it; the domain is the curator's, and only the curator confirms (D56) (Agents Memory) |
| Skills it runs | the precedent lookup; no write skill runs here (Agents Memory and Skills) |
| Its branch of the graph | Support Module § 0 — the root module's tree: intake, classification, the route, closure · the component list is Components — Support |
Every stage also uses support.root — the only profile that reaches the human — and the platform's write_executor and write_auditor (Gating).
1. Channel normalization
P Channel mechanics belong to the connector agent, never to the investigation: ADF quirks, provenance stamps, mail filters, OTRS article types, ignore-lists. What reaches the case is the same shape whatever the channel — reporter, subject, body, referenced ids, attachments, arrival time.
F All three channels are live in v1 and each grew its own ad-hoc handling: 509 Jira analyses, 256 archived mail threads, 52 HDesk tickets — frozen baseline 31.08.2026 (Baseline § 2). The one that shows the cost of not unifying is the HDesk→Jira path, whose approved write backlog sat at 39 of 51 issues for twelve weeks across seven refresh-only runs F: [backlog].
2. Request type
P The platform always classifies — there is no confidence threshold below which it declines (decision 01.09.2026). It shows the classification with the evidence behind it, the operator corrects it in one action, and the correction rate is the metric. A threshold that suppressed classification would move the work back to a human without telling anyone it had.
P Type decides the route, before severity does — but the route is not decided here. S1 names the type and assembles the evidence for it; the route is gate H2 on the packet S3 prepares (D147), and the one routing table is Support Module § 2 — eleven rows including the three waiting kinds. What belongs to S1 is the type vocabulary and what each type obliges S1 to establish:
| Type | What S1 must establish |
|---|---|
| Incident — "X is broken" | the symptom in system terms, the systems and environment it touches, and the symptom's domain family — which becomes the provisional investigator lead if the case ever reaches S2 (Stage Investigation § 2) |
| Question / how-to | the question restated in system terms, and whether memory or the experience index already answers it |
| Data correction | the object, and the wrong → right values as the customer states them |
| Access / accounts | the person, the account layer named, and the offices or roles asked for |
| Master data — vehicle, BSO, agent | the nomenclature values asked for F: v1 skills as seeds, e.g. [add-car] |
| Configuration change request | the evidence for config-toggle versus CR F: [rule] |
| Defect needing code | the service and the observed behaviour — not a proposed fix |
| Out of contract / CR candidate | the contract clause that places it outside standard support (Non-Goals N-7) |
| A step only the customer or an external owner can perform, or a wish deferred to a later release | the trigger the waiting route will name, and the release where there is one (D147) |
P Every type above leaves S1 for S3, whose first question is whether a ready solution exists; a case reaches S2 only by the no ready solution edge (D83). An incident is not routed to investigation by its type.
3. Contract classification and the clock
P Every case carries its contract position as case fields, surfaced in the UI and counted from the ledger — not watched by a person:
- § 1 Standard, severity 1–4, with the contractual response and resolution times; § 2 Personalizations, P1–P3, with offer deadlines — the sections, clocks and calendar are the customer plug-in's configuration (
contract.*, Whitelabel Catalogue); Bulstrad's are the defaults the wiki states. - § 1.5.3: an established workaround downgrades to severity 3 — automatically, and recorded as a downgrade with its workaround.
- Breach warnings fire ahead of the violation, not after it.
Bulstrad default SLA values (contract § 1.5.2, § 1.6.2, § 2.3.2.1; D51):
| Class | Response / offer | Resolution |
|---|---|---|
| Sev 1 | ≤ 12 h | 24 h |
| Sev 2 | 48 h | 5 business days |
| Sev 3 | 3 days | 30 days |
| Sev 4 | 1 week | 60 days |
| P1 | 3 business days | offer deadline |
| P2 | 7 business days | offer deadline |
| P3 | 15 business days | offer deadline |
Business hours: Mon–Fri 09:00–18:00, excluding public holidays — except Severity 1 and 2, whose clocks run around the clock (contract § 1.6.2). The calendar and the exception are contract.business_hours in the Whitelabel Catalogue.
P Gate H1 confirms that the scope is correct and complete enough to build on; the Operator answers it by accepting or correcting the classification.
P Classification targets (D111): correction rate ≤ 10 % after three months and ≤ 5 % steady; re-routing ≤ 5 %; SLA warning at 50 % of the window, escalation at 75 %, and 0 breaches without a prior warning.
Authoritative text: support contract (cite the BG clauses) and procedures.
P Support level follows, and the classification has two levels only: L1 for severity 3–4 and known shapes; L2 for severity 1–2 or high complexity, sub-classified IPAL-side or INSIS-side by where the write lands F: [levels]. A module handover (Hd) or the CR path is a route, not a third level.
P Two clocks, and what pauses them (Case Studies G-4). A case carries a channel clock (Jira SLA as configured on the project) and a contract clock (the support contract's response and resolution times, business-hours calendar § 1.6.2); breach warnings fire on the tighter. Both pause on Pending — the customer's turn — and resume on the customer's reply; a reclassification closes the running contract clock with a CORRECTION record and opens the clock of the new class from the reclassification moment, with the elapsed time recorded, never silently re-based.
4. Dedup
P Before a case opens, the platform checks whether this is already open: the same reporter and subject within a window, the same referenced policy or object id, the same symptom signature. A duplicate attaches to the existing case as further material rather than starting a parallel investigation — the v1 failure being two channels carrying one incident.
P Dedup checks the origin key first — the connector stamps every arrival with channel + external identifier (the OTRS TicketID, the Jira key, the mail Message-ID), so a HelpDesk ticket and its Jira mirror are one case even though reporter and subject differ (D93, D98; Case Studies G-5).
P One channel is authoritative per case — the one the customer speaks on; a mirror's status is a projection, and a disagreement between channels is an operator task, never a reason to close (Case Studies G-15).
5. Precedent retrieval — the point of the stage
P Triage queries the experience index with the symptom signature and returns, in seconds: prior cases with their mechanisms and fix shapes, related known issues, and any living checklist that covers this shape.
Three outcomes, all useful — and all three go to S3 the solution take, which is where the case is routed from (D83):
- Known shape, known fix → the take answers it from a skill or from memory, and the case never enters S2.
- Related precedent → it travels to the take as a hypothesis to verify, never as a conclusion; where the take finds no ready solution, S2 starts from the precedent set. This is the exact point where v1 produced its three retraction cycles (Baseline § 5).
- Nothing found → the take has nothing to work from, so where it finds no ready solution S2 starts cold, and the case is flagged as a precipitation candidate (precipitation).
F The economics justify the stage on its own: cached knowledge is 10–60× cheaper and 30–300× faster than rediscovery (measurement).
Challenges
- P Symptom-signature extraction — the customer's phrasing is in Bulgarian, often paraphrased, and the system error may be absent. How much normalization before lookup is an R&D question, measured by the triage hit-rate (Agents Memory § 7.2).
- P Personal data enters here. Intake carries ЕГН and names; personal data is substituted by case-local handles at the connector boundary before the content reaches any model (Trust and Data § 4).