Before Coding My Thesis, I Had to Cut the Scope
My master’s thesis is “Method of applied different algorithms on multidimension data.” The first assignment from ChatGPT was not to implement a model. It was to make the project small and explicit enough to finish and defend.
The result was a decision register, not a model. It separates choices already made from questions that still require evidence:
| Decision | Current status | Consequence |
|---|---|---|
| Primary data structure | Multivariate tabular data | Time-series modeling stays outside MVP1 |
| Initial detectors | Isolation Forest, LOF, and Autoencoder | No fourth model enters the first comparison |
| RCA definition | Unresolved | Literature review must precede implementation |
| First milestone | One end-to-end run | Tuning and ensembles wait until the pipeline works |
Choose one primary data structure
The initial choice was between:
- Multivariate tabular data.
- Multivariate time-series data.
The recommendation was to start with tabular data and extend to time series only if time allowed. My decision for MVP1 was therefore multivariate tabular data.
Limit the number of anomaly detectors
The suggested scope was:
- Isolation Forest.
- Autoencoder.
- LOF or One-Class SVM only if time permitted.
Two well-evaluated models would provide a defensible comparison. A third can add a genuinely different mechanism; more than three would increase implementation and evaluation work without automatically strengthening the research question.
I initially selected three:
- Isolation Forest.
- Local Outlier Factor.
- Autoencoder.
This is already wider than the safest recommendation, so additional models should not enter MVP1.
The three models were not selected as interchangeable names. Isolation Forest uses random partitioning, LOF compares local density, and an Autoencoder can use reconstruction error. Their different anomaly evidence makes the comparison more informative than adding several small variations of the same mechanism.
Do not use “general RCA” as a definition
Root-cause analysis must have an explicit basis, for example feature-contribution analysis or reconstruction error from an autoencoder. I could not answer this question at the time of the assignment and recorded it as unresolved rather than choosing a vague definition.
That unresolved decision affects both model selection and evaluation, so it needs literature review before the RCA stage is implemented.
A useful RCA output must identify its unit and evidence. For example, a trace-level anomaly might be explained by feature deviations aggregated across its spans, while an Autoencoder may expose features with large reconstruction error. Neither output is automatically a causal root cause; the thesis must define the narrower claim it can evaluate.
Define the whole pipeline before optimizing a model
The planned project pipeline is:
- Data input.
- Data preprocessing.
- Anomaly-detection algorithms.
- Root-cause analysis.
- Evaluation.
- Visualization.
The first coding milestone contains one of everything
The minimum end-to-end version contains:
- One dataset loader.
- One preprocessing step: scaling only.
- One anomaly detector.
- One script that runs the pipeline once.
No ensemble, advanced RCA, or tuning belongs in this milestone. Its purpose is to prove that data can travel through the entire pipeline before additional models increase the scope.
The evaluation contract must be defined before tuning
The synthetic dataset contains five spans per trace with one shared anomaly label. This means the train/test boundary must be created by trace_id, not by individual rows. Otherwise, sibling spans from one generated request can appear in both sets.
The first comparison should keep the data split, preprocessing, and alert budget fixed across models. Useful outputs include precision and recall for the minority anomaly class, a precision–recall curve, performance at a fixed number of alerts, and fit/scoring time. A model should not win merely because it was evaluated at a more favorable threshold.
MVP1 has a clear stopping condition
MVP1 is complete when one command can load the data, create a trace-safe split, fit preprocessing on the reference portion, train one detector, score the evaluation portion, and save reproducible metrics. It is not complete when a notebook happens to display an anomaly score once.
After that contract works for one detector, the next model can enter without changing the evaluation underneath it. Scope control here is not about making the thesis smaller for its own sake; it keeps each comparison attributable to the algorithm rather than to a moving pipeline.