Anomaly Detection Learning Platform: start with the use case

In 2023, a client needed a short anomaly-detection demo for a class.

The requested deliverable had four parts: define the use case, generate fake data, run and visualize two or three algorithms in Google Colab, and hand over code that another person could understand.

This was a teaching project, not a production fraud-detection system. That distinction shaped the whole solution.

A model needs a story

Anomaly detection becomes abstract very quickly when the input is only a matrix of random numbers. I used a fictional bookstore and generated transaction-like records with four understandable attributes:

• time of day;
• book genre;
• price;
• number of pages.

The data followed simple patterns. Different genres had different price ranges, and activity was distributed around expected hours. Once a learner understands the normal pattern, an anomalous record has a meaning rather than only a score.

For the published demo, 210 records were generated. The exact number was not important; having controlled data with explainable assumptions was.

Compare assumptions, not only outputs

The platform demonstrated three approaches:

1. Isolation Forest, which isolates unusual observations through random partitioning.
2. Gaussian Mixture, which models the data as a combination of probability distributions.
3. One-Class SVM, which learns a boundary around observations considered normal.

Each method can return anomalies, but they do not define “unusual” in the same way. In the demo, their flagged sets overlapped without being identical.

That difference is a feature of the lesson. It creates the right follow-up question:

Why did this algorithm flag this record, and does that reason match the real-world definition of a problem?

Clear code is part of the deliverable

For a learning notebook, code quality is not separate from the result.

The notebook had to be readable from top to bottom: generate data, encode the features, fit each method, inspect scores, visualize results and compare the sets of flagged records. A learner should be able to change a parameter and understand what changed.

The client later requested a modification. That is normal, especially when the first working version makes a teaching need more concrete.

What the client verified

The public Upwork review gives a useful description of the outcome:

“Mehmed did a great job. The code he wrote worked well and was clear to understand. When we needed modification, Mehmed was very attentive, quickly understood what was needed and executed on that fast. I really enjoyed working with him.”

The review confirms the parts that mattered for this engagement: working code, understandable implementation, responsiveness and a clean handoff.

What this does not prove

The demo does not prove that one of these algorithms is universally best. It does not use production data, and it does not validate a business threshold for real anomalies.

In a production project, I would add domain experts, labeled review samples, false-positive analysis, monitoring and a process for acting on alerts.

Source

The code is available on GitHub, and the original walkthrough is on Medium.

The project is a good reminder that data science becomes useful when someone can understand the assumptions, inspect the output and decide what to do next.