Judgment & classification
Deduplication is math, and everyone has it. What keeps a backlog clean is judgment: deciding whether a report is a real bug at all, and if not, what it actually is. Qalibr classifies every inbound report before it can become a ticket.
The labels
Each report gets one primary label:
| Label | What it means | Typical outcome |
|---|---|---|
| Bug | A genuine defect worth a ticket. | Enriched and routed on approval. |
| Incident | A live, high-impact production failure. | Surfaced with urgency; floored severity. |
| Regression (signal) | Worked before, broke now. Carried as a reason code and severity signal on a bug, not a separate class. | Escalated. |
| User error | Expected behavior, misunderstood. Not a defect. | Filtered; no ticket unless you override. |
| Question | Someone asking how something works. | Not a bug; routed away from the backlog. |
| Feature request | A request for new capability. | Not a bug; can be triaged separately. |
| Operational support | Access, config, deployment, or task requests. | Not a defect; handled as ops. |
| Ambiguous | Not enough signal, or contradictory signals, to call it. | Held for a human or more context. |
Why it decides
Every label comes with reason codes (the evidence behind the call, for example explicit bug report, error message present, regression signal, production impact, or insufficient context) and a confidence signal. The detail panel shows the label, its reasoning, and confidence, so you can trust the call or override it in one click.
You tune it
Judgment isn’t fixed. With Rules you encode your team’s bar, so Qalibr triages the way your best QA engineer would. Every approve or reject you make also feeds Calibration.
Only reports judged actionable bugs (or incidents) are drafted as tickets. Questions, feature requests, user error, and ops requests are recognized and kept out of your bug backlog, so the noise never costs an engineer a context-switch.
