Triager+ began as a challenge: combine machine learning with a usable, focused web interface for classifying help-desk tickets. It became an exercise in product minimalism, memory-aware architecture, and end-to-end delivery from backend to UI.
What came before
Before Triager+, there were experiments with CSVs, local Jupyter notebooks, and isolated model training sessions. Ticket classification lived as a script, not a product. No UI, no backend, just direct calls to predict functions for hardcoded strings. The challenge was never only the modeling. It was integrating those models into something a person could actually use.
What Triager+ is
Triager+ is a web-based tool that classifies help-desk ticket descriptions into categories and priorities. At its core it is a text classifier powered by a lightweight Naive Bayes model, with an optional DistilBERT path. The goal was something useful, lightweight, and easily hostable: a proof of concept for real-world classification, built cleanly and without fluff.
Why build it
This emerged from a desire to make something practical and fast. Unlike sprawling web apps, Triager+ was an exercise in clarity: take in a sentence or two, return a high-confidence classification. It was also strategic, a demonstration that I could integrate modern AI with a deployable backend and frontend. In a world of toy demos, Triager+ aimed to deliver a product with edges: lightweight, yet real.
Why these models
Naive Bayes was chosen for its speed, simplicity, and low memory footprint. Paired with TF-IDF vectorization, it is well suited to baseline classification. DistilBERT was added as an advanced option, a distilled transformer capable of deeper semantic understanding. It is more powerful, but its memory usage was too high for a free-tier deployment, so it degrades gracefully to Naive Bayes rather than failing.
Architecture
- Backend. A FastAPI app that routes prediction requests, handles preprocessing, and returns model outputs.
- Model layer. A Naive Bayes classifier trained on labeled help-desk data with TF-IDF vectorization. DistilBERT is implemented but conditionally disabled under memory limits.
- Frontend. A pure HTML/CSS/JavaScript interface served as a static site, with instant interaction and no external libraries.
Handling constraints
Developing Triager+ meant navigating real limitations:
- CORS. Custom middleware to allow calls from the frontend's domain.
- Memory. Naive Bayes as the default, DistilBERT conditionally disabled.
- Static hosting. A purely static frontend, so prediction requests interface cleanly through CORS-aware JavaScript and JSON payloads.
Lessons
- Minimalist AI tools can deliver high impact if thoughtfully scoped.
- Deployment friction is part of product design. Testing CORS locally is not enough.
- A project's boundaries are often where its identity is clearest. Triager+ knows what it is, and that is its strength.
What it pointed toward
Triager+ proved I could take a model the whole way to a usable product. The next projects pushed further, into language design with ShapeSound and, eventually, into the foundation itself with Manifest. Triager+ was the prototype of purpose: fast, focused, and finished.