logging-l1-classification

name

logging-l1-classification

description

First-hop classification and localization of incoming Qubership logging-stack support tickets. Use when triaging what a ticket author is asking for (a problem on an installation, a consultation, a feature request, or a security/vulnerability remediation) and where it sits (which component, on VM or Kubernetes, at runtime or during deploy, and the specific symptom or topic). Decides from ticket content; uses the author's Ticket Type only as a tie-breaker and ignores Resolution/Root Cause. Research-phase skill; classifies only, takes no system action and answers nothing.

logging-l1-classification

What this does

For one logging-stack support ticket, decide from its content: (1) the author's intent, then (2) a uniform localization drilldown. First hop of an L1 pipeline; later hops (answering, remediation) are out of scope.

Hard rules

• No system access, no answers, no mutation. Only label.
• unknown is the only "not sure". No confidence fields. Prefer unknown over a guess (precision over recall). unknown on an axis stops the drilldown.
• Ignore Resolution / Root Cause — not available at intake.

Procedure — follow these four steps in order

Step 1 — attach signals (mechanical). Write Summary + Description + Steps to Reproduce to a temp file and run the bundled extractor (use this skill's base directory, shown when it loads):

python3 <skill-dir>/scripts/extract_signals.py /tmp/ticket.txt

It prints hits per namespace: problem / consultation / feature_request / security (intent) and component / platform / phase / symptom / topic (localization). In the research batch these are pre-attached to each record.

Step 2 — read first, signals later. Read Summary + Description + Steps and form your own one-line read of what the author wants. Do NOT look at the signal hits yet.

Step 3 — reconcile with the signals. Now compare your read to the hits and adjust. Signals are strong evidence, but you weigh them differently per decision (see Decision 1 and Decision 2 below).

Step 4 — tie-break with ticket_type (last resort only). If content plus signals still leave it genuinely two-way, use the author's ticket_type (Defect → problem, Inquiry → consultation, Action Item → neutral). Never over a clear content signal.

Decision 1 — intent

problem | consultation | feature_request | security | unknown. Pick by the dominant ask:

• something is broken / failing / degraded now → problem
• a question — "how to", "is it possible", "where is" → consultation
• asking to add or change a product capability → feature_request
• asking to remediate a CVE / vulnerability / scan finding → security

Signal rule (asymmetric — this matters):

• A consultation / feature_request / security signal is strong: if one fired, take that intent seriously even if your first read said problem. These are the classes a quick read under-detects.
• A bare problem signal is weak: failure words ("error", "fail") appear inside questions too, so they do not by themselves make a problem. The form of the ask wins — a question is consultation even if it cites an error.
• Still two-way after content + signals → ticket_type (Step 4). Otherwise unknown.

Decision 2 — localization (only when intent != unknown)

Walk component → platform → phase → leaf. Here signals are a strong prior: if an axis signal fired and the text does not contradict it, use that value — do NOT fall back to unknown. Use unknown only when no signal fired and the text gives no clear cue.

• component — where in the stack: graylog | fluentd | fluentbit | opensearch | operator | mongodb | events-reader | all | unknown. The surface the author points at, not a root cause. A Ruby error/stacktrace ⇒ fluentd (Fluentd is Ruby; FluentBit is C). all = cross-cutting (common for security).
• platform — where it runs: vm | kubernetes | unknown. OpenShift / EKS = kubernetes. Forwarders and operator are effectively always kubernetes; the backend (graylog / mongodb / opensearch) may be either.
• phase — lifecycle: runtime | deploy | unknown. deploy = install / upgrade / restore (ansible TASK [...], install/upgrade jobs, external-logging-installer). operator vs deploy: operator is a component (the running controller); deploy is a phase. They are orthogonal — "operator failed to reconcile during an upgrade" = component=operator + phase=deploy.
• leaf:
  • problem → symptom (the chief complaint, a surface not a root cause). Base: not_running | no_data | performance | disk_space | oom_memory | data_correctness | auth_cert | config_error. A component-specific symptom (e.g. graylog.stream_index, opensearch.cluster_red_yellow, fluentd.buffer_overflow) only when it matches the chosen component. A deploy-specific symptom (e.g. deploy.prereq_check, deploy.image_unavailable, deploy.artifact_fetch, deploy.task_error, deploy.config_validation) only when phase == deploy. Two apply → take the one the author leads with. Else unknown.
  • consultation / feature_request / security → topic: output_target | retention | backup_restore | sizing_resources | integration | rbac_auth, else unknown. security is usually component=all, topic=unknown.

Output

Emit exactly one JSON object per ticket, matching the worklist uid, with rationale first:

{"uid": "PSUPCLOBS#12",
 "rationale": "Problem: author states 'graylog doesn't show logs'; no question or consultation/feature/security cue to override; ticket_type not needed.",
 "intent": "problem", "component": "graylog", "platform": "kubernetes",
 "phase": "runtime", "symptom": "no_data", "topic": ""}

• rationale (1–2 lines) comes first and traces the path: your content read → the signal that adjusted it (if any) → whether ticket_type broke a tie. Quote the decisive cue verbatim — the exact phrase that fixed the intent (and the cue for a localization axis when not obvious) — so the basis is visible, not paraphrased. It is the model's reasoning, formed before the labels.
• Localization fields are filled only when intent != unknown.
• A leaf is empty ("") when it does not apply to the intent — symptom for non-problem intents, topic for problem. unknown means the axis applies but the text did not determine it. There are no confidence fields.