What I built, how I approached it, and what I learned.

AI Helpdesk Copilot — building an explainable AI-assisted service desk

IT service desks receive large numbers of unstructured support requests. Before a technician can solve an issue, they often need to determine what kind of problem it is, how urgent it may be, what troubleshooting information is relevant, and whether similar incidents have already been resolved. I built AI Helpdesk Copilot as a portfolio project to explore how machine learning, transparent business rules, information retrieval and a practical ticketing workflow can work together in one system.

Automated tests

25

Synthetic training examples

490

Troubleshooting articles

70

Support categories

7

The problem

A support request often starts as a short piece of free-form text such as “My laptop keeps disconnecting from Wi-Fi” or “I clicked a suspicious link and entered my password.” The system needs to turn that description into useful operational information without hiding important decisions behind a black box.

The solution

AI Helpdesk Copilot provides an end-to-end support workflow. A customer enters their name, email, device information, issue title and description. The application analyses the request, predicts an IT support category, determines a priority using explainable rules, retrieves relevant troubleshooting articles and allows the customer to create a support ticket. The technician dashboard then provides ticket management, assignment, notes, resolution tracking, similar-incident search and operational analytics.

The end-to-end workflow

1. Customer reports an issue
2. Machine-learning category prediction
3. Explainable priority detection
4. Knowledge-base retrieval
5. Troubleshooting suggestions
6. Support ticket creation
7. Technician dashboard
8. Assignment and internal notes
9. Similar resolved incident search
10. Resolution
11. Analytics update

How the AI works

The project deliberately combines machine learning with deterministic rules. Ticket category prediction uses TF-IDF text features with Logistic Regression to predict one of seven support categories.

Training data

The repository contains 490 synthetic, portfolio-safe IT support examples. The dataset demonstrates the complete model-training and serving workflow without exposing real customer support data.

Explainable priority rules

Priority is deliberately rule-based. Support urgency depends on operational impact, so the system keeps this decision transparent and controllable. It considers security incidents, account compromise, major outages, business-impacting connectivity problems and less urgent routine requests.

This separation allows machine learning to handle text categorisation while operational priority remains explainable and auditable.

Troubleshooting retrieval

After analysing an issue, the application searches 70 troubleshooting knowledge articles and returns the three most relevant matches. Retrieval uses TF-IDF cosine similarity so the relationship between the reported issue and the suggested guidance remains understandable. The interface exposes retrieval similarity and identifiable source articles.

Technician workflow

The technician dashboard turns AI analysis into a usable service-management workflow. Technicians can search and filter tickets, assign incidents, change status, add internal notes, inspect requester information, find similar resolved incidents and record final resolutions. Newly submitted customer tickets appear automatically without requiring a manual page refresh.

Learning from resolved incidents

For active tickets, the system compares the issue with previously resolved incidents using TF-IDF similarity. This gives technicians another source of evidence by showing how related problems were handled previously. These matches are retrieved from operational ticket history, not generated by an LLM.

Data model

The full backend implementation uses SQLAlchemy with PostgreSQL support and a SQLite fallback for lightweight local development. The public GitHub Pages demo runs entirely in the browser and uses localStorage for demonstration data rather than a hosted database.

Ticket statuses: Open · In Progress · Waiting · Resolved · Closed.

Backend and API design

The full engineering implementation is built around a FastAPI backend with validated API endpoints for AI analysis, ticket management, technician notes, similar-incident retrieval, resolution and analytics.

Explore the implementation and documentation ↗

Testing and reliability

The project includes 25 automated tests using pytest and FastAPI TestClient. Tests cover ticket CRUD operations, automatic triage, classifier output, priority rules, knowledge retrieval, technician notes, similar-incident search, analytics and frontend routes. GitHub Actions runs the automated test suite when changes are pushed to the repository.

Portfolio deployment strategy

The recruiter-facing demo is hosted on GitHub Pages and runs client-side so it opens instantly without credentials, container startup or backend wake-up time. The repository contains the complete FastAPI application, SQLAlchemy models, PostgreSQL configuration, trained scikit-learn classifier, retrieval logic, tests and Docker Compose setup. That full implementation can be run locally or with Docker; the public GitHub Pages demo does not claim to be a hosted FastAPI/PostgreSQL deployment.

Key design decisions

CRUD before AI

The basic ticket-management workflow remains useful independently of the machine-learning component.

Classical ML baseline

TF-IDF and Logistic Regression provide a reproducible, explainable baseline for ticket classification.

Transparent priority rules

Urgency is treated as an operational business decision rather than an opaque prediction.

Visible retrieval evidence

Troubleshooting recommendations are connected to identifiable knowledge-base matches.

Synthetic demo data

Training examples, knowledge articles and seeded support tickets are portfolio-safe.

No recruiter login

The public demo allows a reviewer to understand and test the main workflow quickly.

What I learned

This project taught me how different parts of a practical software system fit together. Building the classifier was only one part of the work. I also had to think about API contracts, persistence, user workflows, explainable decisions, retrieval, testing, dashboard reliability and deployment. One of the most useful lessons was that AI features are more valuable when they support a clear operational workflow rather than existing as isolated model predictions.

Real-Time Data Engineering Pipeline — from simulated telemetry to operational analytics

I built this project to demonstrate practical data-engineering capability beyond notebooks and static dashboards. It processes simulated smart-building sensor events through validation, transformation, persistence, anomaly detection, dead-letter handling and operational monitoring.

Simulated devices

10

Anomaly methods

3

Docker services

5

Backend API tests

9

The problem

A polished chart shows the final output, but it does not explain how raw events become trustworthy operational data. I wanted the project to make ingestion, schema enforcement, failure isolation, enrichment, persistence and detection visible while remaining quick for a recruiter to explore.

The solution

The project combines an instant public demonstration with a deeper engineering implementation. The GitHub Pages experience simulates 10 smart-building rooms in the browser and lets a visitor start or pause the stream, inject an anomaly, inject malformed data and reset the system. The repository contains the complete server-side pipeline.

Backend architecture

1. Python sensor simulator
2. MQTT / Mosquitto broker
3. Python consumer worker
4. Pydantic validation
5. Transformation and enrichment
6. Three-stage anomaly detection
7. PostgreSQL persistence
8. FastAPI analytics API
9. Operational monitoring

Docker Compose connects five services: PostgreSQL, Mosquitto, FastAPI, the MQTT consumer worker and the sensor simulator. Accepted events pass through the worker and processing services before they are stored and exposed through analytics endpoints.

Transformation and enrichment

The backend normalises timestamps to UTC, converts energy usage from kilowatts to watts, and derives temperature, humidity and energy bands plus a comfort status. These fields make the transformation stage a real processing step and provide useful attributes for downstream analytics.

Data quality and dead-letter handling

Pydantic validates device identifiers, numeric sensor readings, humidity ranges, non-negative energy values and timestamps. Invalid HTTP and MQTT payloads are stored in dead_letter_events with their source and failure reason, while a pipeline audit event makes the rejection visible. Bad data is isolated instead of crashing the pipeline or disappearing silently.

Three anomaly-detection approaches

Database and API

SQLAlchemy models persist devices, sensor_readings, alerts, pipeline_events and dead_letter_events. FastAPI provides ingestion, health, recent readings, alerts, dead letters, pipeline events, device analytics, energy aggregation, anomaly summaries and simulation controls.

Observability

The system records explicit pipeline-stage audit events for validation, transformation, storage and detection. The dashboard and API expose device state, event throughput, freshness, anomaly alerts, rejected events and operational summaries so the processing path can be inspected instead of inferred.

Testing and CI

The pytest suite covers database health, valid ingestion, transformation output, invalid and unknown-device handling, dead-letter persistence, threshold and statistical anomalies, pipeline-stage logging, analytics and reset behaviour. GitHub Actions runs the tests and then starts the complete Docker stack to verify that MQTT simulator events pass through Mosquitto and the worker into PostgreSQL and become visible through FastAPI.

Result

The final project demonstrates event-driven data engineering, backend API design, messaging, validation, transformation, database modelling, statistical and machine-learning anomaly detection, observability, containerisation and automated testing. Its public browser layer makes those ideas immediately explorable while the repository preserves the complete implementation and infrastructure evidence.